Reference Project

One setup for the whole software lifecycle, run by a very small team

The Reference Project shows a live SaaS product for web and mobile, and the way of working that builds and runs it. The way of working covers the whole software lifecycle, from a business need through to operation, and AI agents do most of the work in every stage of it. That is what lets a very small team build, change and run the product.

Every change the agents make is checked automatically against rules written for this system.

Click a box for what each part does and why it is set up that way.

How the work is done and checked

1One way of working for all six codebasesAI agents defined as roles · written procedures · standing rules · automatic stops2Written guidance and checks in each codebaseinstructions for the agents · documentation written for them · checks before anything is recorded3Delivery to productionautomatic testing and building · security scan · demo release · production release started by a person4Tickets and the written recordthe backlog · requirements · runbooks · the release record

↓works on

The six codebases

the core business services

5Accounts and consentwho is on the platform, and what they agreed to6Business rules and paymentswhat is sold, to whom, and at what price · payments and invoicing7Uploaded filesupload · checking · storage

sign-in

8Sign-inone login for web, apps and services · a look for each brand

what customers use

9Web and mobile appsevery brand from one codebase · mobile apps · an embeddable version · documentation for the people who run the platform

operations and records

10Operations and the audit recordevery service, environment and secret · runbooks · security and audit records

↓runs as

What runs for customers

11Cloud hostingMicrosoft Azure · a demo environment beside production · managed database · monitoring and alerts12AI inside the producttext · moderation · images · research13App stores and app updatesApp Store · Google Play · same-day fixes · required updates14Outside servicespayments · email · address entry · bot protection · analytics

1. 1One way of working for all six codebases AI agents defined as roles · written procedures · standing rules · automatic stops. One shared setup defines every AI agent as a role with a named job, and applies the same written procedures and standing rules in all six codebases. That gives the business one standard instead of six, and knowledge that does not leave with a person: each codebase has a specialist role that answers questions with the exact place in the code as evidence, so a change never rests on someone’s memory of how a neighbouring part works.
2. 2Written guidance and checks in each codebase instructions for the agents · documentation written for them · checks before anything is recorded. Each codebase carries its own instructions for the agents, the larger ones a documentation layer written for them, and the checks every change there must pass before it is recorded. A change starts from a written map of the codebase rather than from one person’s knowledge of it, and a failed check stops the change at the earliest point there is — seconds after it was made, long before a customer could meet it. Read on: CI and boundary enforcement
3. 3Delivery to production automatic testing and building · security scan · demo release · production release started by a person. Every change is tested, built and scanned for known security weaknesses automatically, and the demo environment updates on its own. The production release is a separate step that a person starts. The dividing line is deliberate: whatever can be undone runs without waiting for anyone, so work keeps moving; whatever reaches customers waits for a decision someone stands behind. Read on: A Jira ticket resolved by an agent, with a human in the loop where it matters
4. 4Tickets and the written record the backlog · requirements · runbooks · the release record. The backlog and the team’s written record — processes, requirements, runbooks, the release record — are within the agents’ reach. A ticket is carried from analysis to review in one procedure, and a production release is entered in the record by the procedure that detected it. What went live is on record when an auditor or a customer asks, not reconstructed afterwards. Read on: A Jira ticket resolved by an agent, with a human in the loop where it matters
5. 5Accounts and consent who is on the platform, and what they agreed to. Holds who is on the platform and what each of them agreed to: accounts, consent, verification, and every channel the platform sends messages through. Consent is one record the business can point to rather than something spread across apps. Its interfaces are agreed in writing before any code exists, and the one another service depends on is checked on every build, so a mismatch stops the build instead of reaching customers. Read on: CI and boundary enforcement
6. 6Business rules and payments what is sold, to whom, and at what price · payments and invoicing. Carries the product’s business rules, payments and invoicing included. Every rule that decides what a customer gets and what they pay is enforced here, in one service; the web and mobile apps only show the result. A pricing or payment rule therefore has one place where it is checked, changed and answered for, and no app can apply it differently from another.
7. 7Uploaded files upload · checking · storage. One job: accept a file, prove it is what it claims to be, and store it with the record it belongs to. A file built to carry hidden code, or to make the server act on an attacker’s behalf, is turned away here, in one place, instead of every app defending itself. Files sit in the main database rather than a separate storage service — a simplicity the current scale allows.
8. 8Sign-in one login for web, apps and services · a look for each brand. One sign-in serves the web, the mobile apps and the services behind them, and each brand’s login shows that brand’s terms and privacy links. Thirteen brand looks are layers over one shared design, so a new brand does not mean a new login system. The console that can change someone’s identity sits at a separate address open only to approved networks: the part the public reaches cannot change who anyone is.
9. 9Web and mobile apps every brand from one codebase · mobile apps · an embeddable version · documentation for the people who run the platform. One codebase serves the website of every brand, the platform’s own mobile app and a brand’s own app. A new brand or client therefore starts from what already exists: its own mobile app is a theme and a configuration entry, not a new project, because the screens are shared. The documentation for the people who run the platform is written from the code, so it follows the product rather than someone’s memory of it. Read on: CI and boundary enforcement
10. 10Operations and the audit record every service, environment and secret · runbooks · security and audit records. One register of every service, environment and secret. Secrets are recorded by name only and their values held in a vault, so an environment can be set up without anyone reading one. The security record is kept, not remembered: known weaknesses per codebase, refreshed from scans; who holds production admin access; and the responsibility matrix a card-payment security audit (PCI DSS) asks for, itself checked automatically. A request to erase one person’s data becomes the exact deletion through code from explicit inputs, never written freehand by an AI model.
11. 11Cloud hosting Microsoft Azure · a demo environment beside production · managed database · monitoring and alerts. The services run on Microsoft’s managed cloud, with a demo environment beside production, so the services run there before a person releases them to production. The data is held in a managed database. Monitoring records what the system does and raises alerts on the conditions set for them, so a problem on a watched condition is reported instead of waiting to be noticed.
12. 12AI inside the product text · moderation · images · research. The AI the product itself uses — separate from the AI that builds it. It writes text, moderates content, generates images and does research, through Microsoft’s and Google’s AI services. Only one backend service calls a model; the apps never do. Everything the product sends to an AI service passes through that one place, which is where it can be reviewed and controlled.
13. 13App stores and app updates App Store · Google Play · same-day fixes · required updates. The mobile apps reach customers through the App Store and Google Play. A fix that needs no new store version goes straight to installed apps once a person approves it — the same day, rather than after a store review. A remote setting can also tell an installed app that it must update, so customers are not left on a version the business no longer wants running.
14. 14Outside services payments · email · address entry · bot protection · analytics. What the platform uses rather than builds: two dedicated payment providers, transactional email, address entry, bot protection on forms, and analytics. Analytics start only after the visitor consents, so no visitor is tracked before they agree.