One platform, several learning products

Training providers and course creators often reach the same fork in the road. The first product works, and now there’s a second audience: a new certification, a different subject, a partner who wants their own branded version. One option is to add it to the existing app. The other is to launch a second, focused product.

We’ve faced this choice with our own apps. Braineos is a flashcard platform. Finance Brain is a free financial literacy course site. CertBrain is exam prep for one AWS certification. All three run on one codebase. Here’s how we think about when that’s the right call, and what it takes.

When a second site beats a bigger first one

A second product is usually worth it when the new audience would want a different home screen. Braineos is built around decks of flashcards that people make or discover. Finance Brain is built around courses, so its web and mobile apps lead with courses and progress through them. Putting both on one site would mean every learner wading through the other product’s features.

Other signs point the same way:

• A different question to answer. Braineos learners want to know where they stand across everything they’ve studied. CertBrain learners want to know whether they’re ready to book the exam. Those are different pages.
• A different promise. An exam prep product needs a sourcing standard and a non-affiliation notice. A general learning app doesn’t.
• Features that would be noise. Finance Brain turns off user-created decks, challenges and some AI tools. CertBrain turns off making and browsing decks, voting and following.

If the new audience wants the same home screen and the same features with a few additions, adding to the first product is usually simpler.

Don’t fork the code

The obvious way to launch a second product is to copy the code and start changing it. We didn’t, because a fork is two apps to maintain forever: every bug fixed twice, every dependency upgrade done twice, and the two drifting further apart. Instead, each product is a deployment of the same code.

What the shared platform needs

Site profiles. Each deployment sets one site ID, which selects a profile: the product’s name, logo, colours, copy, legal text and features. The strict rule is that no component hard-codes anything product-specific. That’s cheap from day one and painful to retrofit, because product names hide in page titles, emails, error messages and alt text.

Feature flags enforced on the server. Hiding a button doesn’t turn a feature off, because the API is still there. On our platform, a switched-off feature’s endpoints answer “not found”, as if they didn’t exist. Site admins can still use some switched-off tools, which is how Finance Brain’s course content is authored with deck tools its learners never see.

Not every flag means “invisible”. CertBrain’s premium lessons stay visible but locked, because people need to see what they’d be getting. The gate is a single check, and content is unlocked unless marked, so sites without premium content aren’t affected.

Separate databases. Each product has its own database and sign-in project, so users of one never appear in another. All of them run the same migration history, so the schemas don’t drift.

A pipeline per site. Each product deploys through the same pipeline shape, with its own build secrets and image names, so one site can’t be built with another’s settings.

The same split on mobile. Our mobile app separates build settings (name, package ID, icons, upload key) from the in-app site profile. If the app is told it’s a site it has no profile for, it refuses to start, rather than shipping one product’s listing with another product’s name on every screen.

What a new product costs

With that in place, CertBrain’s launch was mostly configuration: a new profile, the features it needs switched on, its own database and sign-in. The new code was small and specific to exam prep, a way to lock content and a diagnostic anyone can take without an account, and both now work on every site on the platform. Its Android app was the third built from the same mobile codebase, again mostly configuration.

The launch also showed where our own checklist was vague. Two web server settings had to be corrected against a site that already worked, because the checklist described them in words. The fourth site starts from tested templates instead.

The trade-offs

• Every feature needs a moment’s thought. Does every site want this? Badges, for example, have a per-site list and a flag that’s on for Braineos only so far.
• Separate databases cost more to run than one database with a “site” column. We think separation by construction is easier to trust than every query remembering a filter.
• Some infrastructure is still shared. When we backfilled badges, the script hit the database pooler’s connection limit, which is shared with the live sites. It now caps its own connections and works through users a few at a time.
• Shared logic has to stay shared. Readiness and Progress use the same card scoring, extracted into one function, so the sites can’t quietly drift apart.

In return, every improvement to the platform reaches every product at once.

If you’re weighing a second learning product, or a branded version for a partner, tell us about it and we’ll help you decide whether it should be a new site or a new feature.