> From https://dialect-engineering.ai/sections/13-evidence, the companion site to the paper "SaaS architecture when code is cheap". Draft, September 2026.

# SaaS architecture when code is cheap

## 13. Evidence from two applications

The two applications illustrate the two directions of travel in section 5. The house-design application, Wadi, is the greenfield case: it was built around its language from the start. The onboarding language, On2Go, is the brownfield case: an overlay on a product that already has customers.

### 13.1 A parametric design language

The first is a house-design application built on this architecture. The domain grammar has primitives at the level a designer works in: floors, rooms, walls, windows, furniture anchored to a position within a room, rather than geometric shapes. A validated document compiles to a model that drives a 3D view, floor plans, elevations, roof details and material quantities.

Four properties bear on the argument.

**The configuration surface is generated from the document.** The document declares which parameters are adjustable, and the interface for adjusting them is produced from that declaration at run time. Adding a parameter to the document adds a control to the interface with no change to the application. This is the one benefit in this paper that genuinely needs a greenfield: generating the surface from the document requires the platform to accept a desired-state description, which an existing product generally does not.

**An agent authors it over MCP.** The grammar, worked examples, a validator and a test runner are exposed to a coding agent through an MCP server. The agent writes and checks documents without the application in the loop. A single instruction such as adding a floor with the same plan as the one below produces a valid document and a rendered result.

**The agent is confined to the language.** It cannot add an API, a table or new application code to satisfy a request. Requests outside the language are designed to be refused. Under delivery pressure the validator gained an advisory tier, and the case corpus that section 12 describes was not built.

**It was verified by looking at output.** The fastest check on a complicated geometry turned out to be rendering it and looking. A missing balcony wall on a newly added floor was obvious in the render and easy to miss in the document.

### 13.2 A customer onboarding language

The second is a demonstration built against a dealer-management ERP vendor's product and run on test onboarding data. Onboarding for that product moves substantial reference data for each new customer: warehouses, parts, part-to-warehouse mappings, on-hand inventory, hundreds of records per entity, arriving from spreadsheets, accounting systems and CRM in a different shape for every customer. The current process is manual manipulation of whatever the customer sends, because there is no standard format.

The demonstration defines a grammar in that product's own vocabulary, derived from its knowledge graph, with per-customer source mappings held as project templates. An operator uploads the customer's files without classifying them, the language's configuration identifies which input each file corresponds to, and the onboarding run executes. Validation results report per entity, failures cite the specific records, and a failure links to the line of the language that rejected it. The rejected records go back to the customer as a file.

Two points about this case matter more than the demonstration itself.

The scope today is data migration, which is the narrowest useful version. The intended path is for the same language to cover configuration, and eventually screen and workflow definition. That is a substantially harder claim and is not evidenced by what runs now.

The product is untouched. The language compiles to inputs the product already accepts, which makes it an overlay rather than a rewrite, and makes it available to an existing product with customers on it.

---

---

Previous: [12. Verification moves from reading to running](https://dialect-engineering.ai/sections/12-verification.md) · Next: [14. What this asks of a product roadmap](https://dialect-engineering.ai/sections/14-roadmap.md)