Cadence is one core platform — multi-tenant, modular, industry-neutral by design — built out into three markets: salon suites and wellness, hospitality, and small business. About 7,900+ commits across 20 repositories, 131 serverless services and 399 versioned schema migrations, running in production on web, native iOS and voice. Designed, built and operated by one person directing an autonomous AI engineering organization, under a governance framework a board could review.
What the platform is → Or how it gets builtA second industry is a config, not a rewrite — and the platform is the evidence.
The spine is deliberately industry-neutral: identity, tenancy, permissions, records, messaging, documents, money. What makes it a salon-suite product or a venue product is data and configuration sitting on top of it, never a fork. That choice is what lets one person carry three verticals, and it is the thing worth assessing about the engineering, because a platform that only works for the customer it was written for is not a platform.
What makes it enterprise-grade, in terms a reviewer can check:
Row-level security on every tenant table, and a hard wall between schemas: the service role that runs the web tier holds zero grants in the tenant schema, so no single reader can span both sides. Cross-tenant reads are impossible by construction rather than by discipline.
Corporate, operator and end-user each sign in to the same system and get a different one. Identity resolves the role; the role decides the data, the screens and the actions.
Access is granted door by door and validated on the server, never in the client. An unknown key grants nothing. Demotion revokes cleanly.
Each customer's API keys are sealed per tenant and injected at runtime — never in code, never shared, never a platform key standing in for a customer's. A customer can be onboarded, or cut off, without a deploy.
Usage is recorded where it is incurred, attributed to the account that incurred it, and reconciled against the plan.
The CRM and the messaging transport are configuration. The same tenant can run on a third-party CRM, a different one, or the platform's own, and no product code changes.
These are the markets the platform is built for and the audiences it is aimed at — described as capability, not as a customer list.
An operating system for a multi-tenant location business: find the next site and underwrite it, open it, market it, run the floor, handle the money, and give every resident professional their own portal. Owner web, professional web, native iOS and a voice agent over a shared backend — 2,878 commits across six repositories, 168 routes and 131 serverless services. Live and in daily use. What it proves: that the spine holds up under a real operator's whole business, with three classes of user, external systems of record, and money moving through it.
An agentic operating system for venues: event enquiry through booking, banquet orders, catering and the customer front door, with a set of specialist agents and a venue knowledge layer underneath them. 206 commits against a 22-document specification suite covering the data model, the agent architecture, the security invariants and the reporting model. What it proves: that the same platform reaches an industry with entirely different objects — events, rooms, menus, contracts — without the spine changing shape.
The horizontal product, and the core the other two stand on: 46 modules covering contacts, pipeline, proposals and estimating, invoicing, marketing, content, messaging and telephony, documents, websites, plans and billing — 668 commits. A live nonprofit deployment runs on a different stack entirely (Cloudflare Workers and D1 rather than Postgres), which is the useful evidence that the architecture is not one lucky arrangement of vendors. What it proves: range — the same operating model applied to a general business, and to a second infrastructure stack.
Designed for tens of thousands of them across an industry — which is a statement about the architecture, not about how many use it today.
A suites business has two populations, and only one of them works for the operator. The professionals renting the rooms are independent businesses: they carry their own insurance and licences, they take their own clients, they have their own brand. Treating them as rows in the operator's system is the design mistake that makes the whole model fall over at scale.
So they are a first-class tenancy of their own, on their own surface. A professional signs in to their own hub and manages their profile and photograph, uploads their licence and certificate of insurance with expiry tracked against them, raises maintenance requests on their room, approves the spotlight the studio wants to publish about them, reads the documents that apply to them, and carries their own scannable code that follows their profile wherever it is printed.
Why that is an architecture question rather than a feature list: it means a third class of identity, with its own permission scope, enforced in the database rather than on the screen — a professional can reach their own records and nothing else, and no amount of client-side mistake changes that. Adding one is data. Adding ten thousand is the same data.
The industry this targets is 2,372 locations across 23 brands — counted from the competitive map the platform itself maintains. At the suite counts these buildings run, that is tens of thousands of independent professionals, each of whom would hold an account.
Row-level policies scope a professional to their own records and their own building. The same rules hold whether the network has one location or two thousand, because the rule is written once, in the data.
Anything a professional can do for themselves is something an operator is not doing for them. Compliance documents, contact details, photographs and requests are all theirs to file — which is what keeps an operator's workload flat as the building fills.
Nothing in this tier assumes whose building it is. The professional's surface takes its name and palette from the operator's configuration, so the same code serves any brand in the industry without a fork.
This is the part that has no equivalent on anyone else's brief, so it is worth being precise about what it actually is.
The work is done by AI agents operating under a written standard, on my own hardware, against real production systems. I set the architecture, the standards and the priorities; sessions pick up work items, open branches, write the code and the tests, and put up pull requests. Nothing merges because an agent believes it is finished — it merges because the gates pass.
Every task is a tracked item with an owner and a next action. Parallel work happens in isolated worktrees, each registered, so two sessions cannot quietly overwrite each other in the same repository.
Continuous integration and release run on self-hosted machines — unit suites, security scanning, simulator test matrices, signing and store upload. Merging to the main branch ships a build.
A merge waits for every check on the exact commit to reach a terminal state and pass. A red gate is a defect to fix, never an obstacle to route around, and the tooling refuses to do it either way.
Architecture decisions, the reasoning behind them and the things deliberately not built are recorded in a shared library as they happen, so the next session inherits the reasoning rather than re-deriving it.
The honest claim is not that this replaces an engineering team. It is that one person can hold the architecture, the standards and the review of a portfolio this size — and that the leverage comes from the discipline around the agents, not from the agents.
A rule nothing checks is a promise. Each of these is enforced in the pipeline.
A claim that something works cites the file and the line, or it is not made. Writing a value is not a feature until the code that reads it has been opened and shown to connect.
New capability comes with a test that fails if it is removed — and where the consumer lives in another repository, the guard reads that repository at test time and hard-fails when it cannot see it, because a skipped guard reads as green.
Before a test is trusted, the bug is reintroduced and the test is watched going red. A control that stays green either way is not a passing test, it is an absent one.
A green deploy is not a shipped change. Releases are confirmed against the commit the edge is actually serving, and database changes against the rows themselves — never against a workflow's success badge.
One secret store is the source of truth; runtime stores are synced from it. Nothing is pasted into a file, and nothing is committed.
A feature that works at one location and silently does nothing at the others is treated as broken, not as shipped with a gap. Behaviour is exercised against more than one tenant before it is called done.
A security gate that could never have worked. The static-analysis job cloned the repository without specifying a branch, so every pull request was scanned as the mainline. It had been passing for months and could not have caught anything a change introduced. Found by moving the job, not by the job.
Two builds with the same number. Release numbering restarts per version, so a lookup by number alone matched both a new build and a four-month-old one. The pipeline distributed the old binary to testers and reported success twice over. What caught it was a step added an hour earlier whose only job is to read the result back and say what is actually there.
An email that kept only its subject. Outbound mail had been storing the subject line and discarding the document, so no one could see what had been sent. Measured across the whole table before the fix, and repaired at the one shared writer rather than at the screen that reported it.
None of these were found by a passing test suite. They were found by verification steps whose only purpose is to check that the thing claimed to have happened actually happened.
Screens from the deepest of the three builds — shown as evidence the rest of this document is describing something real.
Native Swift with a local store, not a wrapper around the website: an operator walks their floor where the signal is poor, and the app has to work there and reconcile when it returns. Its five sections are the product's own structure.
The capability worth assessing: multi-surface parity enforced as a rule rather than a hope. A figure shown on both surfaces is derived once, on the server, because two surfaces that each work an answer out for themselves will drift — and the person who finds out is the operator, standing in the building, holding two different numbers.





The web tier runs at the edge as serverless workers, close to the reader, with a pooled connection to Postgres rather than a server per region.
Row-level security, versioned migrations applied by a reconciling pipeline, and behaviour checks that read the production rows rather than the catalog.
Integrations, scheduled work, webhooks and the AI paths run as independent deployable services, each with its own contract tests.
iOS in Swift with a local store, so the operator's surface works on a floor with poor signal and reconciles when it returns.
AI features are metered, attributed to the tenant that used them, and run on the customer's own key where the customer brings one. No feature depends on a single vendor being available.
Including the operating standards, the architecture decisions and the runbooks — in one library, with the reasoning attached to the decision.