Built a Figma template that accelerated white-label app production

Equeo is a mobile employee-learning platform, an EdTech product for enterprise clients. Its app ships under each client's brand: in the App Store and Google Play it looks like the client's product, not Equeo's. Clients can customize colors, button corner radii, logos, backgrounds, and the app icon.

The process was linear: a designer prepared the materials, the client approved them, engineering assembled the app, then store screenshots and publishing followed. Any delay at the first step moved the entire chain, and that first step always belonged to the designer.

Materials lived in separate projects: screens, iOS and Android assets, web, and certificates. The approval presentation was assembled manually in another tool, icon sets for different sizes through an external service, and colors were applied screen by screen. On some days, four or five new clients arrived at once.

The goal was to accelerate the complete production of a white-label app, not only mockup preparation. The template needed to:

• Bring screens, two-platform assets, web materials, certificates, presentations, and store screenshots together in one file.
• Make a build reusable: clients change images and adapt branding for events.
• Give engineering ready-to-use materials, without manual slicing and sorting on their side.
• Generate the approval presentation from those same screens instead of assembling it separately.

• Customization was limited to what the platform supported: colors, button corner radii, logos, backgrounds, and the app icon. The template could not expand that set.
• The application worked with styles only, not variables, so the template had to be built around styles.
• Client functionality varied by plan and enabled modules. Keeping every possible screen in the template made no sense.
• iOS and Android were separate development teams with different internal processes.

Branding is the substitution of values into a fixed set of parameters. So the template works as a source of values rather than a collection of mockups: the designer changes parameters in one place, and everything else follows from them.

A designer takes colors from the client's brand guide and applies them to the template styles. Style names came from alignment with engineering: together we defined the colors required and agreed on their names. The iOS and Android teams built a plugin that read those values directly from the Figma file through its API.

The implementation differed between the teams. On Android, the data went straight into the build, so a preview of the app with new colors was available quickly. On iOS, some steps remained manual. I only knew the technical setup on their side from the teams' descriptions.

Engineering no longer needed a separate color list: it received the values itself, under the same names the designer saw.

The file contains one main screen for each section, enough to show the branded product while client functionality still varies by plan and enabled modules.

The screens are designed once; everything else builds on them.

The app is cross-platform, so the web interface is recolored with the same values. The template also contains web materials: favicons, authorization and navigation backgrounds, logos for the navigation and authorization screens, and an invitation page with download links. The app name is also inserted into copy, with notes in the file indicating where it appears.

A 13-slide presentation is assembled from the same screens instead of being recreated in a separate tool.

The client reviews and approves the branding before anything goes to engineering.

Previously, icon sets for different screen sizes came from an external service: upload the source, receive an archive, then sort it manually. In the template, one icon source produces every size required by iOS and Android. Frames are named after their destination paths, such as res/drawable-xxhdpi/ic_notification, and export settings are predefined. Select the set and export it in one action into the finished folder structure.

Engineering only needs to apply the colors, logo, and backgrounds. The build then goes to the App Store and Google Play with screenshots in all required sizes and both languages. The template also includes branded landing-page preview materials for clients who distribute the app directly.

The splash screen crops differently depending on screen height. That went unnoticed with solid backgrounds. But with people in the image, heads or legs could be cropped on some devices. Sometimes the team caught it in QA; sometimes the client did.

Together with engineering, we introduced authorization_background and authorization_background_splash parameters with top, center, and bottom values. They define the edge from which an image is rendered and therefore what gets cropped. A separate optimize parameter disables compression for images with prominent gradients where compression created artifacts.

The config text sits in the file itself, next to where a designer inserts the background. The plugin reads it from Figma and passes it to image settings, so the system knows how to position an image and whether to optimize it. Engineering introduced the parameters; I documented the rules for choosing their values in the template.

iOS did not have this mechanism: the image reaches the top and bottom edges of the screen and crops at the sides, while the layout keeps important elements inside the safe area.

Automation covers the typical case: the client's brand guide follows the template, and a side-menu or splash-screen background is a raster image inserted once and reused wherever needed with size adjustments.

Some clients supplied brand guides in an open format, with vector graphics unrelated to the template or their own logo-use rules. A designer could not simply drop in a file: each use had to be checked and adjusted to the client's rules. Complex vector graphics, such as patterns, directly increased the time required.

Certificates used one template for different cases: three completion types - program, learning path, and test - in two languages, while the platform populated the fields. Otherwise, certificate branding would have become a separate task.

Preparation time was roughly cut in half. Before the template, one client build was completed per day; afterward, three or four - and up to five when needed.

• Preparing materials dropped from 3-4 hours to one hour for a typical client.
• The approval cycle went from one or two days to a single pass.
• Two external tools left the process: an icon-size generation service and presentation software.

Engineering time also decreased: its plugin reads assets from Figma and a script applies image-positioning parameters, allowing several builds to ship on the same day.

The template outlived my role: another designer still uses it.

Exporting presentations from Figma remained a limitation. A full-size PDF could reach 300 MB, which is impractical to send to a client. Third-party compression created artifacts. The workable workaround was to export slides as PNGs and reassemble the presentation from images - manually doing the very work the template was meant to remove. I estimate this added around 10% to the cycle, but I did not measure it.

The issue was not the mockups but Figma's export behavior, which could not be fixed inside the template.

Some manual color work could be eliminated entirely. The template uses styles because the app only supports styles. But Figma could define two or three client base colors, with all 29 styles taking their values from those through variables. Preparation would then become entering a few values rather than editing each style separately.

The next step would be to move the configurator out of Figma into a dedicated service. The template already works as a configurator: the parameter set is finite, and the substitution rules and export paths are known. A designer would upload a logo and backgrounds, set the colors, and receive ready-to-use folder assets, a presentation, and store screenshots. Today I could build this tool myself with vibe coding, without a separate development team.