One Core. Many products.

Products sit on top and reach the Core only through the SDK. The portal and this site are part of the Core codebase. Vendor keys sit underneath, visible to the Core alone.

These decisions are fixed early because each is expensive to reverse once products exist. Together they keep money and identity in one system of record, limit what any single product can reach, and let FormaBase keep running a product without depending on any one person.

1. 01

   One Core, many satellites

   The Core is a single codebase and a single database. Products contain only their own features and their own data.

2. 02

   Separate code, separate access

   The Core lives in the platform repository. Every product has its own repository, so a Creator can only ever see the product they build.

3. 03

   Versioned shared code

   The brand kit and SDK are published as versioned packages. Products pin a version, so improvements apply going forward and never break a live product.

4. 04

   Two data tiers

   The Core database is the only system of record for people, customers, subscriptions, attribution, agreements and money. Each product has an isolated database for its own features, and cannot connect to the Core database.

5. 05

   One doorway

   Products reach the Core only through the Core API, with a key scoped to that one product.

6. 06

   One identity

   One sign-in service for every participant and every customer. A customer has one FormaBase account across all products.

7. 07

   One payment account

   Every product is a Stripe product tagged with its product ID, behind one webhook endpoint on the Core. Products never see a payment key.

8. 08

   Central attribution

   Every Affiliate link goes through one redirect service that records the click. No product implements its own tracking.

9. 09

   Secrets stay in the Core

   Payment, email, messaging and AI keys exist only in the Core. A product holds two secrets: its own Core key and its own database address.

10. 10

    One product ID everywhere

    A single slug names a product's repository, deployment, database, payment metadata, monitoring tag, analytics property and subdomain.

The Core is one deployable application divided into modules. Each module owns its own tables and exposes functions; other modules call those functions and never query another module's tables directly. That keeps the Core simple to run today, with clean seams if a module ever needs to stand on its own.

There are three environments: local development, a preview for every proposed change, and production. Every change is a pull request with its own preview deployment and automated checks; only reviewed changes reach production. Database changes are forward-only migrations, committed alongside the code that needs them.