The sensible version of this story does not exist. Nobody sensible decides to build finance, stock, purchasing, manufacturing, projects, HR, support, commerce, communication and website building as one system, alone, while studying.
I want to explain why it happened anyway, because the reasoning turns out to matter for what the product became.
The thing I could not stop noticing
Every small company I saw up close ran on the same architecture: four or five pieces of software that did not know about each other, held together by a person with a spreadsheet.
The spreadsheet was never the problem. The spreadsheet was the symptom. The problem was that the company’s own information was scattered across systems bought at different times by different people for different reasons, and nobody could see all of it at once. Every question that mattered required somebody to go and assemble the answer by hand.
The software industry’s answer to this is integration, and integration is a treadmill. You buy a platform to connect the systems, then you maintain the connections, then you buy a reporting tool because no single system can answer a cross-system question, then you hire someone to maintain that.
At some point it stopped looking like a hard problem and started looking like an unquestioned assumption. Businesses buy software per function because that is how it is sold, not because it is how a business works.
Why not knowing better helped
I did not come to this from twenty years inside enterprise software, and that turned out to be the advantage rather than the handicap I assumed it was.
Someone with that background knows that building an ERP takes a large team and several years, so they do not start. They know that suites are assembled through acquisition, so they plan for federation. They know that AI features ship as an index over everything, so they build the index.
I did not know any of that was mandatory. So the architecture came from first principles: one database, one permission model, one transaction boundary, and applications that are views onto the same records rather than products that talk to each other.
That decision is why the whole thing is possible for a very small team. Most of the cost in enterprise software is not the features. It is the seams between them.
What it actually took
Years of evenings and weekends, and the parts nobody writes about: understanding double-entry bookkeeping properly, learning why stock valuation methods differ and when it matters, reading Dutch VAT rules until they made sense, working out what payroll actually requires.
The applications are the visible part. Underneath there is the provisioning system that creates an isolated Site in minutes, the backup and restore machinery, the monitoring, the billing meters, the update pipeline that rolls back cleanly when a migration fails. That layer is unglamorous and it is the reason customers can buy a managed service rather than a codebase.
The agent layer came last, and only because the foundation allowed it to be built safely. Permission inheritance is trivial when there is one permission model. Retaining nothing is possible when retrieval is fast because everything is in one place.
What being small means for a customer
I am not going to pretend a small company is an unqualified advantage for you. It is a real risk and you should price it in.
What I can do is remove the parts of that risk that are within my control. Your data is exportable in full, in open formats, at any moment, at no cost. There is no exit fee. The terms are readable. Nothing about the design assumes you cannot leave.
And there is a genuine upside. When you write to support, you reach someone who knows the system rather than a first line whose job is deflection. When you need a feature and several other customers need it too, it gets built in weeks rather than being filed against a roadmap. When something breaks, you get an explanation rather than a status page platitude.
What I am actually trying to do
Make it normal for a company of any size to run on one system, where every employee has access because access is free, where the AI in the software works on live records and keeps none of them, and where the bill reflects what the business used rather than how many people it hired.
That is not a modest goal, and I would rather state it plainly than dress it up. The Netherlands is a good place to attempt it: small companies, high standards, and an entirely reasonable insistence on knowing exactly where the data lives.
