Tenean is one platform — multi-tenant, modular, industry-neutral by design —
built for two sectors: salon suite owners and service businesses. About
4,500+ commits across eight repositories, 166 serverless
services and 780 versioned schema migrations, running in production on the web, on iPhone and
Android, on the TV in the building and on the phone line. Designed, built and operated by a small,
senior team at Cadence Advisers directing an autonomous AI engineering organization, under a
governance framework a board could review.
5surfaces: owner web, professional web, iPhone, Android, TV
2sectors 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 services product is data and configuration
sitting on top of it, never a fork. That choice is what lets a small team carry two sectors, 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
Two sectors, one spine.
These are the sectors Tenean is built for and the owners it is aimed at
— described as capability, not as a customer list. A third sector is a configuration, not a rewrite.
Salon suitesTENEAN FOR SALON SUITES · THE DEEPEST BUILD
An operating system for an owner who rents suites to independent professionals: find the next
site and underwrite it, open it, fill the suites, market it, run the floor, handle the money, and
give every resident professional their own portal. Owner web, professional web, native iPhone and
Android, the screens in the building and a voice attendant over a shared backend. Live and in daily
use in the founder's own location. What it proves: that the spine holds up under a real owner's whole
business, with three classes of user, external systems of record, and money moving through it.
ServicesTENEAN FOR SERVICES · THE SECOND SECTOR
The same platform for a plumber, an electrician, a cleaner: the first call answered on the
business's own line, the visit booked on the real calendar, the estimate, the job, the invoice,
and the morning read of money won, estimates waiting and invoices past due. The building's rooms
switch off and the work's rooms take their place, by configuration. What it proves: that a
second sector is data on the spine — the same inbox, calendar, customers, money and
marketing, with the sector's own words and rooms — not a second codebase.
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 Tenean for Salon Suites — 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. 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.
tenean · markets
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.
tenean · command
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.
tenean · money
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.
tenean · grow
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.
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.
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.
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.
