Skip to main content

The platform

You get a whole product, not a starting point.

Accounts, organisations and roles; the capabilities your product needs; a public site on your own domain; AI where it helps; and infrastructure somebody watches. It is the same factory we run our own products on, which is why we can afford to operate yours too.

How it works, for engineers

This page is written to be checked. Where something is designed and not built it carries a badge, where it is a research direction it says so, and every capability sentence on this site has a row in the repository’s claims ledger naming the code, the document or the test that backs it.

Each section below carries one of these blocks. Nothing in them is a summary of the section above — it is the mechanism, in the words the page used to lead with.

The system

Two doors into one system.

Makers come in through Console, and GENESIS compiles what they describe into a platform app and a public site. The people who use those platforms come in through the Hub, and one click takes them inside the one they choose, already signed in. Both doors rest on the same shared services, upgraded for everybody at once — you never integrate two of our products with each other.

Console sits at the top left and feeds the GENESIS compiler below it. The compiler produces two products side by side: public sites at a site subdomain or a custom domain, and platform apps at a tenant subdomain or a custom domain. The Hub sits at the top right, at Console’s level: nothing compiles it, and one edge — the bridge — runs from it into the platform apps. Both doors and both products rest on the same band of seventeen shared services.Consolefor makers — create · configure · publishconsole.alodai.comHubLIVEfor the people who use them — one account, one click inapp.alodai.comGENESIS compilerbrief → intent → draft → validated, behind a human gategenesis.alodai.comSitesthe public face of a platform — pages, theme,storefront{site}.site.alodai.comor your own domainPlatform appspacks, modules and project blocks — one image,every tenant{tenant}.app.alodai.comor your own domainSHARED SERVICES — ONE SET, SERVING EVERY PLATFORMaianalyticsauthautomationsbuildercoredataenginegenesismailingmedianotificationspaymentsrealtimesearchsitesstorage
How it works, for engineers

The picture is drawn from the repository’s own generated topology rather than from a whiteboard, and a test fails if the two stop agreeing: the same seventeen services serve every tenant that comes out of the factory.

Every one of those seventeen services is routed over TLS at its own subdomain and answers a health check; the operator console probes all seventeen of them on one page.

The system documents itself at docs.alodai.com — routes, API key scopes and the shared contracts, generated from this repository. It is not drawn above because it is not part of anybody’s platform: it describes the machine rather than running on it.

17 shared services · 7 shipped apps · 32 packages

Making changes

Change your product without waiting for a release.

Adding a capability, changing who can do what, restyling the app and the site together, publishing to a domain you own — each of those is a setting rather than a project. We do it with you, in the same tool we use for every platform we run.

  1. See every platform you run in one list, with its address and whether it is live.
  2. Turn a capability on or off for your product, and configure it, without a deploy.
  3. Set your palette, type and shape once and have the app and the public site both follow.
  4. Publish to a domain you own, with the certificate handled for you.

Console is not open to self-serve sign-up. Access opens in waves, and the waitlist is on the home page.

console.alodai.com/org/…/platforms
The Console platform list: one row per platform with its host, experience pack and status.
How it works, for engineers

Makers create platforms, choose an experience pack and the modules on top of it, set roles and brand, and publish a site with its pages, theme and custom domain. Every change lands as rows the compiler can read back.

Capabilities

Switch on what your product needs — and skip the six months it takes to build it.

Members, courses, events, catalogue, chat, media, tasks, payments. Each one is a capability other platforms already run in production, configured for you rather than commissioned from scratch.

what you can switch on today

  • Members
  • Organisations
  • Contacts
  • Companies
  • Teams
  • Events
  • Bookings
  • Calendar
  • Courses
  • Forums
  • Posts
  • Articles
  • Chat
  • Tasks
  • Projects
  • Catalogue
  • Products
  • Quotes & invoices
  • Expenses
  • Workforce
  • Presence
  • Forms
  • Polls
  • Pages

ready-made starting points

  • Travel
  • Education
  • Professional services
  • E-commerce
  • Field operations
  • Engineering
  • Music
  • AI lab
  • Developer community
  • Arena
  • Thinkers’ library
  • Wellness studio
  • Reflective wellness
  • Hackathon
  • Generic
console.alodai.com/org/…/platforms/…/modules
The Console module grid for one platform: each module a card with its id, what it does, and a switch.
How it works, for engineers

A module is a reusable capability with surfaces of its own. An Experience Pack is a factory preset for a whole vertical: its naming, navigation, modules, seed content and AI behaviour, applied when a platform is created and editable afterwards.

The registry is honest about itself, and that is load-bearing. A module whose implementation is marked as not yet built cannot be enabled for a platform at all — the activation gate refuses it — so what you can switch on is exactly what is built.

A pack configures; it does not own data. That is a deliberate boundary: a vertical cannot quietly grow its own tables, so moving a platform between packs stays a configuration change.

@mp/module-registry · @mp/experience-packs

The part that is only yours

And the thing nobody else has.

A game, a configurator, a map experience, a lab instrument — whatever makes your product yours gets built for you, on top of the capabilities that were already there rather than beside them.

How it works, for engineers

A module is generic and shared between platforms. A project block is the opposite: functionality meaningful in one platform, which consumes the modules rather than reimplementing them. Blocks are disabled by default and enabled per platform.

The catalog itself is framework-agnostic — definitions, configuration schemas and availability rules — and the thing that draws a block lives in the platform app, looked up by key. One boundary is enforced rather than requested: the server half of a block cannot be imported by an app, and a guard fails the build if one tries. The first block has a scored challenge, and a quiz whose answer key ships inside the browser bundle cannot support a ranked result.

packages/project-blocks

AI

AI that helps your users, and never acts behind your back.

Assistants, chat, classification and recommendations inside your product — and a separate AI that builds the platform in the first place. The two never touch, and only the first is ever pointed at the people who use your product.

  • The AI that builds

    It turns your brief into a proposed platform and drafts the brand and the first content. It never ships to anyone unattended: a person reviews and approves before a single page is published.

  • The AI inside your product

    Assistants, agents, chat, classification, recommendations and search that understands meaning — with an approval step wherever something acts on a person’s behalf, and a spend ceiling in front of every call so a runaway loop cannot become an invoice.

console.alodai.com/org/…/platforms/genesis
The GENESIS screen in Console: a name, a slug, example chips and a brief, beside the compiler's live read of what it will extract.
How it works, for engineers

The compiler runs staged, resumable passes that can be re-run. The runtime layer sits behind four provider adapters — Anthropic, OpenAI, Google, DeepSeek — selected by one router with a spend guard in front of every call.

Deterministic first, wherever determinism is available. Which modules a pack enables comes from a registry and a manifest, not from a model; the model writes names, labels, copy and onboarding steps. When the model is unreachable, the compiler falls back to the deterministic path and records that it did.

You can bring your own provider key, at organisation or platform level, so both the model choice and the model spend can be yours.

services/genesis · services/ai · ai.alodai.com

Where this is going

Changing a running platform by describing the change.

One day you will be able to write “add a waiting list to bookings” and get a reviewed change against the platform your customers are already using.

Research direction

We are researching it. It is not in the product, there is no date, and it is here because leaving it out would be the more misleading choice — it is where the architecture is pointed.

When it arrives it will keep the human gate. The interesting problem was never generating the change; it is proving that a change is safe to apply to a system that already has your customers inside it.

Your data

Your customers’ data stays yours.

Every request is checked against your tenant before it touches a row. The people who use your platform, the people who use somebody else’s, and the people who build them are three separate sets of accounts — linked where one person is in more than one, never merged.

  • One customer never sees another

    The check happens on the way to the data, on every request, rather than at a gate somebody could route around. A change to any of those paths ships with a test proving the other customer is refused.

  • Signing in to one platform is not signing in to another

    Moving between platforms hands you a fresh session for the one you are entering. Nothing you hold on one is worth anything on another, because there is nowhere to spend it.

  • Money is counted, not estimated

    Amounts are held to the cent and never as a fraction, and the shapes your data travels in are agreed in one place — so a change that would break something breaks it at build time, in front of us, rather than at runtime in front of you.

How it works, for engineers

Tenancy is asserted, not assumed. No middleware compares a token’s platform to the platform in a URL. Every tenant-scoped request resolves the platform and the user in the service layer before it touches data, and every change to such a query ships a test that proves the other tenant is refused.

One token table per plane. Crossing from one identity plane into another mints a fresh session through a single-use, short-lived, hash-stored code that lives in its own table. A token issued on one plane cannot be redeemed on another, because there is nowhere to redeem it.

Contracts, not conventions. Request and response shapes are schemas in one shared package that the apps and the services both import. Money is integer cents. Status values are catalog rows, never a database enum, so a new status is data rather than a migration.

packages/auth-lib · platform_bridge_tokens · @mp/shared

Operations

Somebody runs it, watches it, and answers when it breaks.

Your platform is deployed, secured, monitored and backed up by the same people who built it. Backups go off site on a schedule, and a backup that quietly stops running raises an alert as loudly as one that fails.

  • It runs in Europe

    On our own servers, with your databases on a different machine from the one serving your traffic, and every address covered by a certificate that renews itself.

  • It can be rebuilt

    Every environment is described in code and every secret is encrypted where it lives, so rebuilding one is a re-run rather than an excavation. Nothing about your platform depends on somebody remembering.

  • It is watched

    Metrics, logs and alerts go to a channel a person reads. The alert that matters most is the one that fires when a backup did not happen.

  • ai
  • analytics
  • auth
  • automations
  • builder
  • core
  • data
  • engine
  • genesis
  • mailing
  • media
  • notifications
  • payments
  • realtime
  • search
  • sites
  • storage

checking service status…

How it works, for engineers

Docker Swarm across three tiers: an edge server for ingress and compute, a data server for PostgreSQL, MongoDB and Redis, and a build-and-monitoring server. Traefik terminates TLS, and one Cloudflare wildcard covers every tenant and site subdomain.

Ansible roles and Terraform, with every secret encrypted at rest inside the repository through sops and age. Prometheus, Grafana, Loki and Alertmanager run on their own host, and the backup rules alert on absence as well as failure.

  • Docker Swarm
  • Traefik
  • Cloudflare DNS
  • PostgreSQL
  • MongoDB
  • Redis
  • restic → B2
  • Prometheus · Grafana · Loki
  • Ansible + Terraform
  • sops + age

sops + age · restic → Backblaze B2

Platform · next step

Want the walk-through with an engineer?

Bring the brief. We will bring the architecture, and the parts of it your product would actually touch.

Request a platform