What changed this quarter
Dear friends, this is a short letter: where we are, what we learned, and what we are watching.
Something is changing in how business software gets bought, and it is the reason we exist. Cloud was always sold to technology departments; the business then rented finished SaaS built on top of it, per seat, forever. The layer that is disappearing is that rented generic product. The builder is not disappearing at all — they are starting to sell to the commercial director who has the problem and the budget, instead of to IT.
We spent two years getting ready for that, building the layer underneath before we sold anything. Not an application — our own cloud, and a set of primitives on top of it: data, compute, identity, delivery. That is a long time to spend with no revenue, and it is the reason most of what follows is possible. Anybody reselling someone else's infrastructure has a price floor they cannot go beneath. We do not have one.
We started taking customers in mid-September. Three weeks ago. Everything below has happened since, which is both more than we expected and early enough that we would rather tell you what is actually signed than what is nearly signed.
We pointed it at one segment first: mid-sized enterprises. We chose it because it is where both halves of a good market turned out to be — acute pain, and the budget to pay for the fix.
And one discipline we are holding to: the cloud grows in step with cash flow, not ahead of it. We watch utilisation as closely as we watch revenue, because the cost advantage only exists if we are not carrying capacity nobody has bought.
The bet
Mid-sized companies cannot buy software that fits them. Large enterprises reshape themselves around a platform and can afford to. Companies of ten bend to the SaaS, which is cheap at that size. The two-hundred-person company can do neither — its processes are specific enough that generic software fights them, and its budget will not stretch to making a generic platform fit.
So it ends up with the same arrangement everywhere, whatever the system is for: the software it bought, and a spreadsheet beside it that is the real system of record. Ask a sales director where the forecast lives and they will name the CRM; ask which version goes to the board and it is the spreadsheet. The production schedule, the project tracker, the stock sheet, the hiring pipeline — the same shape every time, because the part that makes the company money is the part the software never had.
We think that has been a tooling problem, not a budget one. Two-thirds of any bespoke build is identical across every customer — auth, data layer, environments, deployment, CI — and that two-thirds is where the money and the quarters go. Build it once, properly, and the economics change. That is what the two years bought.
What we have: cloud primitives
There are two ways to get software built today and neither suits this size of company.
Raw cloud hands you a box of parts — a database, a queue, a load balancer, and the job of making them all agree with one another. Powerful, and it needs a team to assemble and a team to keep standing.
A finished platform hands you the opposite problem. Everything works on day one, and nothing bends to how you actually operate. You get somebody else's process with your logo on it.
Primitives are the middle, and they are what we spent two years building. Ready-made pieces that already work together: an application ships here with no login code written into it at all, because identity is not something you assemble. Nothing to put together and nothing to configure around — you point them at your process instead of building up to them or bending around them.
Three things about them we think are the actual moat:
- An AI coding agent — Claude, Codex — can drive all of it. Not "has an API an agent could call": the agent provisions the database, deploys the application, issues its credentials and reads its own build logs, with nobody in the loop. The code was never the expensive part of a business system. Everything around it was, and that is the part the agent now does, which is why implementation is weeks rather than quarters. We wrote the method down and handed it to agents that had never seen it, with us playing the customer: one day produced a signed-off design, ten screens and 36 tests named after the requirements — and two places the method itself failed. The whole account is here.
- We run our own cloud, which is where the price floor went.
- One copy of the data is why the AI works. One database answers the ordinary questions, the similarity questions and the relationship questions over a single copy of your data — set up in a click, rather than five services you integrate and then keep in sync. So the assistant reads the live system of record at the moment you ask, instead of an overnight copy that has gone confidently stale. No larger model fixes the alternative.
Pricing: not SaaS, not an SAP implementation
Two ways to pay for business software, and this size of company is badly served by both.
SaaS rents you a seat, forever. A system meant to run a business gets better the more of the business is on it — and per-seat pricing charges you for precisely that. So licences get capped, half the company stays on the spreadsheet, and you have paid monthly to recreate the problem you were solving.
An enterprise implementation charges you once, enormously, before anything works. A mid-market SAP or Oracle programme is quoted in the hundreds of thousands before a single person has used it — and quoted honestly, because bending a forty-year-old product to a business it was never built for really is that much work.
We do neither. A customer takes a committed monthly amount covering an agreed volume, and that is the bill. Usage beyond it is charged at rates agreed up front, with a hard limit by default and nothing invoiced without written approval — usage pricing is only attractive if it cannot surprise you, and finance directors are right to ask. Implementation is weeks rather than quarters, because the assembly that used to be the bulk of the invoice is the part the agent now does.
It is also how the revenue grows. When a customer puts more of the business through the system, the committed volume steps up — so we are paid more when the system is doing more, not when a procurement list gets longer. The customer's growth and ours are the same number.
We are not competing with those forty years of modules. We are arguing you do not need them.
Traction, three weeks in
Seventeen organisations are on the platform, two of them the mid-sized companies this is built for. That is the shape of it three weeks in: real, and small. Distribution through software houses is the part we still have to prove, and it starts this quarter.
Our own company runs on it. Pipeline, quotes, contracts with real signatures, proposals, campaigns. Our money is in it; when it is wrong we feel it that week. It is the only evidence we fully trust, and it is why we started selling when we did — what is in that package is written down.
A prominent European media group is moving its commercial operations onto one of these systems. What they are buying is not a set of modules. It is a system that runs on their own live data with the AI native to it rather than bolted on: it drafts from their past work, chases what is late, writes the reports from what actually happened, and explains any number by pointing at the record behind it. Everything it writes is a draft a person sends, and everything it does is listed and reversible — a commercial team will put real work through an assistant they approve and can audit, and will quietly route around one they cannot.
That is the part worth understanding about all of this. An assistant is only useful when it reads the system of record as the business is running it, and a system is only affordable at this size when the layer underneath it is ours and an agent assembles it. Neither of those works alone. Together they are the business.
One further client has signed. The conversations opening after it are in logistics.
The distribution thesis
If growth depends on how many projects we can staff, the platform is just a nice internal tool and the ceiling is our own headcount. So the business is the people who build on it.
Software houses already serve these companies and already lose money on the undifferentiated two-thirds. Independent builders — the people shipping real software with Claude or Codex beside them — stopped being constrained by writing the code a while ago. What still constrains them is everything around it, which is the part we removed.
Which is the shift at the top of this letter, from the builder's side: the same work, a better margin on it, and a buyer who signs without a technology committee.
What we are watching
- Share of a build that is undifferentiated. The argument is that it goes to nothing.
- Software houses shipping on the platform. They are how distribution grows, so signing the first of them matters more than our own project list does.
- Utilisation against revenue. The cloud is the asset; carrying it ahead of the cash flow is the one way this gets expensive.
We are early on the second. That is the honest state of it.
— Seemo, for the DODIL team
— Seemo, for the DODIL team