Draft, September 2026

Home / Pick a layer / Interface and APIs

Interface and APIs, today and after the multi-tenancy line moves

The explainer video for the paper SaaS architecture when code is cheap
Transcript

Scene 6: The interface and APIs today

Beneath onboarding are the interface and the APIs. The customer wants screens that fit how their people work, down to the individual user, and increasingly wants their own agents to operate the product. Today every customer sees the same screens, and personalisation stops at the tenant. An API lets a program bypass the screens, through the same service the screens use, and an agent using it still has to learn the product's rules from somewhere else. For a buyer who expects agents to operate the software, a product that needs a person clicking through menus is one their agents cannot use. For the provider, fitting the product to every customer and their agents means hundreds or thousands of screens, fronting a capability described only through forms, APIs and a configuration schema. Modernising them means wireframe, build and review, one screen at a time. Agents make each screen faster, and the cost still grows with the number of screens.

Scene 20: the interface

Next comes the interface, where the customer wanted the product personalised down to the individual user and operable by their own agents. With a grammar of what a screen can be, a screen becomes a document too: which entities it shows, which fields, in what order, with what validation, all checked against the domain's rules. Each tenant's layout, or one user's, is a variation of the screen's document, which the agent can write. In an existing product, the compiler emits those screens as source code at build time, reviewed and deployed through the normal pipeline, so each variation is a build. Composing the interface at run time, per user, needs a platform that accepts a desired-state description, which usually means new platform work. For the provider, there is a fixed cost to build the grammar and the compiler, then a cost per screen that falls as converted screens become worked examples, with close review of the first ones. The evidence supports converting screens at a faster rate, with review still needed. The same language is what a customer's own agent needs to operate the product in the domain's terms.

Go deeper