Capability brief · Peter Lewis

I build the systems
a business runs on.

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 built
7,900+commits across 20 repositories
131serverless services; 399 versioned schema migrations
46modules on the core platform
3industries served by one spine
The core

One platform. The industry is configuration.

A 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:

Isolation that is enforced, not intended

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.

Three audiences, three products

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.

Permissions default-deny

Access is granted door by door and validated on the server, never in the client. An unknown key grants nothing. Demotion revokes cleanly.

Credentials belong to the tenant

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.

Metered and billed per tenant

Usage is recorded where it is incurred, attributed to the account that incurred it, and reconciled against the plan.

Integrations are pluggable

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.

Where it is aimed

Three industries, one spine.

These are the markets the platform is built for and the audiences it is aimed at — described as capability, not as a customer list.

Salon suites, wellness & beautySUITEOS · THE DEEPEST BUILD

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.

HospitalityMAVEN · VENUE OPERATIONS

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.

Small businessTEMPO · THE CADENCE PLATFORM

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.

The second tenancy tier

Every professional in the building gets their own account.

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 scale it is built for

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.

Isolation is the load-bearing part

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.

Self-service, or it does not scale

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.

Brand-neutral by construction

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.

How it gets built

One person, directing an engineering organization that isn't people.

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.

Work is dispatched, not improvised

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.

The pipeline is ours

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.

Merging is mechanical

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.

Decisions are written down

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.

Discipline

Standards that are enforced by machinery, not by intention.

A rule nothing checks is a promise. Each of these is enforced in the pipeline.

Nothing is true unless it is verified in code

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.

A control ships with its guard, in the same commit

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.

A guard must be proven able to fail

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.

Verify what production serves

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.

Secrets live in one place

One secret store is the source of truth; runtime stores are synced from it. Nothing is pasted into a file, and nothing is committed.

Every change works for every tenant

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.

What that catches

Three real ones, all from a single day.

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.

In depth

What it looks like in production.

Screens from the deepest of the three builds — shown as evidence the rest of this document is describing something real.

the underwriting workbook
Every number checked against the franchisor's own standards, as it is typed.
Every number checked against the franchisor's own standards, as it is typed. This site comes back 5 of 6 ratios at or above guidance, with 19 of 23 assumptions inside their bands and one flagged optimistic — each explained where it sits: “$0/mo is below franchisor guidance ($50–$75/mo) — this makes the deal look better than it is.” The capability: domain rules encoded as data, so the model argues with the person filling it in rather than flattering them.
cadence · markets
Every site in an industry, on one map.
Every site in an industry, on one map. Competitor locations as switchable layers, rings and drive-times around any corner, and a score against the criteria that matter for that industry. The capability: geographic and demographic analysis as a product surface, not a consulting deliverable.
cadence · command
One screen that answers “what needs me today”.
One screen that answers “what needs me today”. Occupancy, money, the day's exceptions and the work waiting on a decision, assembled from every subsystem. The capability: cross-module aggregation that stays fast because the reads are shaped for it, not because the data is small.
cadence · money
The books, read by the system rather than by a person.
The books, read by the system rather than by a person. Statements are imported, reconciled and turned into the figures an operator actually asks for. The capability: financial data handled with the care it requires — attribution, provenance and an audit trail behind every number.
cadence · grow
Pipeline, from first enquiry to signed.
Pipeline, from first enquiry to signed. Leads arrive from several channels, resolve to one person, and move through stages the business defines. The capability: a CRM-agnostic spine — the same pipeline runs on a third-party CRM or on the platform's own, by configuration.
Native iOS

The same platform, in a pocket — and the same numbers.

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.

Command — The day, in one screen — what needs attention, occupancy, and the money position.
Command
The day, in one screen — what needs attention, occupancy, and the money position.
Money — The books read by the system: net income, assets, cash on hand, and the health ratios behind them.
Money
The books read by the system: net income, assets, cash on hand, and the health ratios behind them.
Agent — A voice and chat assistant over the operator's own data, not a general chatbot.
Agent
A voice and chat assistant over the operator's own data, not a general chatbot.
Grow — Pipeline and onboarding — where leads came from and how far each has moved.
Grow
Pipeline and onboarding — where leads came from and how far each has moved.
The floor — The building itself: every suite, who is in it, and what it earns.
The floor
The building itself: every suite, who is in it, and what it earns.
Architecture

The stack, and why each piece is there.

Edge-first

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.

Postgres as the system of record

Row-level security, versioned migrations applied by a reconciling pipeline, and behaviour checks that read the production rows rather than the catalog.

Serverless services for everything that isn't a page

Integrations, scheduled work, webhooks and the AI paths run as independent deployable services, each with its own contract tests.

Native where native matters

iOS in Swift with a local store, so the operator's surface works on a floor with poor signal and reconciles when it returns.

Models are a dependency, not the product

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.

Everything is in version control

Including the operating standards, the architecture decisions and the runbooks — in one library, with the reasoning attached to the decision.

Peter Lewis · Cadence Advisers · Boston, MA · [email protected] · (617) 314-3772 · linkedin.com/in/peter-lewis-boston