This was much larger than a template editor
The easy version of an app builder swaps a logo, changes a colour palette and produces another copy of the same product. This platform was aimed at a harder problem: reuse the product at several architectural layers, then let a mixed audience assemble, preview and release a new variant without working directly in the codebase.
The scope map covered a Node.js CLI toolchain, five generator layers, a React authoring portal, a shared backend on AWS, live and build-preview hosting, organisational controls, white-label data, and release paths for PWA, Android and iOS. That is not one application. It is a product studio, a build system and an operating model joined together.
My role ran from June 2019 to August 2020. Within that window I conceived the platform direction, recruited and shaped the team, owned the system design and delivery direction, and stayed hands-on in the product engineering. I was also one of three architects reviewing critical changes across the wider estate. The short tenure matters here: the hard part was not only drawing the large end-state; it was deciding what deserved to become a dependable platform first.
Constraints that shaped the architecture
Reuse had to go below presentation. The architecture separated platform-specific templates, reusable business-logic libraries, modules, screens and components. If only the first layer is configurable, every meaningful customer request still becomes a source-code fork.
The control surface was for more than engineers. The portal exposed theme, skin, design and configuration editing, plus live preview and build actions. The CLI and build mechanics could not leak through every interaction or the platform would remain an internal engineering tool with a graphical wrapper.
Preview and release are different truths. A fast live preview answers “does this edit look right?” A generated build preview answers “is this the artifact we are actually about to ship?” Treating those as one thing produces a pleasant editor and unpleasant releases.
Governance was part of the product model. Organisations, companies, users and roles, rules, app configuration, skins and white labels were all first-class concepts. An agency or multi-brand operator does not only need another app; it needs a safe boundary around who can change which product.
Three targets meant three failure surfaces. PWA, Android and iOS shared a project definition, but they did not share packaging, review cycles, runtime constraints or every component implementation. “One project” could reduce authoring duplication; it could not make the targets identical.
Decisions and trade-offs
A composable generator, not a pile of branded forks
The Node.js toolchain composed an app from several reusable sources: a platform template supplied navigation and global design; business-logic libraries supplied API access, validation, models and shared methods; modules supplied screens, routes and store behaviour; screen and component layers supplied the platform-specific UI.
That decomposition is what made a white label more than a theme. A change could belong at the narrowest reusable layer instead of being copied into every generated product.
The cost is compatibility. Once templates, logic packages, modules and components evolve independently, the generator has to know which combinations are valid. The architecture included a rules manager and consolidated assets/store/routes because generation has to resolve a coherent product, not merely concatenate files. This is developer-platform work: the happy path looks simple because the constraints are being handled somewhere else.
A React portal over the toolchain
The portal turned the generator into a product. Projects and skins anchored the authoring model. Users could edit theme, skin, design and app configuration, manage editable assets through a small CMS, open a live preview and request a build.
The trade-off is that the CLI and portal become two faces of the same orchestration. Any capability available only through one face creates a support trap; any validation implemented twice eventually disagrees. The durable boundary is a shared project model and shared backend contract, with the CLI and portal acting as clients of it.
Live preview and build preview as separate infrastructure
The scope allocated distinct hosting for live preview and build preview. That is an important line. Live preview optimises feedback time while someone edits. Build preview exercises the generated artifact and the path closer to release.
Keeping both costs infrastructure and forces a clear answer to “which preview failed?” It buys a much more useful failure location. An editor problem, a generation problem and a target-build problem stop collapsing into the same vague report that “preview is broken.”
White-labeling as data, rules and assets — not CSS
The project model held companies, rules, data and app configuration alongside skins, editable assets and splash screens. This made white-labeling a governed product definition. The same brand could carry its own content, behaviour and target settings without owning a private branch.
That power raises the blast radius of bad configuration. The more behaviour moves into project data, the more validation and preview become part of correctness rather than convenience. A flexible control plane without strong guardrails simply moves bugs from code review into an admin screen.
Shared services behind generated products
Node/Express API services, MongoDB, Nginx and AWS infrastructure — EC2, S3, EBS and load balancing — sat behind the portal and generated applications. Reusable service integrations belonged there rather than inside every output product.
This kept the app generator additive to the wider production estate. New Node and React/React Native work could advance without requiring an all-at-once rewrite of the existing PHP, Python and mixed-database systems. The difficult work was agreeing the seams: what stays a shared service, what becomes generated code, and what remains target-specific.
One project, three release paths
The delivery model supported PWA directly and native delivery through Android/iOS targets using React Native and wrapped-PWA approaches. Sharing the authoring model reduced duplicated product work, but the release paths stayed explicit.
That honesty matters. A PWA can publish on web infrastructure; a native application enters packaging, signing and store-review workflows. A platform that hides the distinction creates false expectations. A platform that models it can still provide one control surface while telling the author which kind of release they are asking for.
The boundary between platform and prototype
The architecture also recorded package management, automated testing, analytics switching, deep-linking and a provider-integration experiment under POC / prototype, not inside the committed platform lanes. I am keeping that label here rather than retroactively turning a roadmap into a delivery claim.
Those tracks were directionally right. A generator needs package discipline and automated verification; a multi-app portal benefits from analytics controls and deep-link management. But their presence on a scope diagram proves intent and exploration, not production maturity. The distinction is part of the engineering record.
My contribution was both architectural and operational
I was not acting as an architect who handed over a diagram. I owned the product direction, system boundaries and technical sequencing; recruited and formed the team; wrote or drove the solution work behind critical decisions; and contributed hands-on to the platform engineering.
At the same time, the wider estate still needed architectural governance. As one of three architects, I reviewed critical changes for code quality, feasibility, time and cost, and helped push an incremental Node/React/microservices direction alongside production systems that could not simply stop for a rewrite.
The main leadership decision was scope control. The platform map is broad enough to consume several teams. In a roughly fourteen-month role, success depended on establishing the reusable generator, portal, preview/build path and shared backend as the spine — while leaving exploratory work visibly exploratory.
What I would change now
Define a typed intermediate representation first. Today I would make the project definition a versioned, typed intermediate form shared by the portal, CLI, validator and generators. The five layers would compile through that contract rather than relying on coordination between tools.
Make reproducibility and automated tests foundation work. Package management and automated testing appeared in the POC lane. I would pull both forward. A generated product should carry exact input versions, produce the same artifact from the same inputs, and run contract and target smoke tests before a preview URL is considered valid.
Generate more of the portal from the same schemas. Theme, design, configuration and component controls drift when the editor and generator describe capabilities separately. Schema-driven authoring would make the portal a projection of what the generator actually supports.
Lead with PWA, earn native complexity deliberately. For many white-label products, a PWA now provides the fastest credible path to validation. I would make native targets opt-in when device capability, distribution or store presence genuinely justify their additional build and support surface.
Keep the prototype boundary visible. The original map did this well. A platform roadmap should show what is operational, what is being hardened and what is still a bet. That is more useful to a team than an architecture diagram in which every box pretends to have equal reality.