why I built an agent-native business system

Fourteen times I’ve taken an enterprise CRM from the first workshop all the way to live. Fourteen of them, full cycle, start to finish. And every time, pretty much the same song and dance. Months of implementation. A price per user. And a whole layer of consultants wedged between the people who build the software and the people who’ve actually got to work with it.

I was one of those consultants. Still am, and I like the work, genuinely. Sit an organization down with a truly tangled process landscape and that model holds up fine. All that complexity needs the hand-holding, and those systems do things nothing else touches.

But somewhere between that first project and the fourteenth, something started to nag at me. Why’s it like this everywhere? And I mean everywhere.

the pattern

Look at just about any piece of business software and you’ll spot the same three building blocks. A price per user, that grows with your team, so it grows with your success. An implementation, because the thing’s too configurable to stand up on your own. And a partner in the middle, who didn’t build the software at all, but who’ll happily bill you the hours to get it running.

In the enterprise world? Sure, that can all add up. Thing is, the pattern got copied straight down the ladder. To companies it was never meant for. Take a service business with eight people. On the usual per-user systems they’re a few hundred euros a month, easy, and that’s before the setup costs at the start. And an installation firm that just wants a grip on its customers, its scheduling, its quotes and invoices? That’s not a service anymore. That’s a tollgate.

what happens next

And that tollgate isn’t there just once, mind you. It’s there with every package you add.

The packages that do cover the whole thing are so expensive that most smaller firms never even start. So you buy separate pieces. A CRM, an accounting package, something for quotes, something for the refrigerant logbook, something for the heat loss calculation. Each one at a price that’s still easy enough to defend for that one piece.

That’s how you grow, in a few years, into six systems and six suppliers, tied together with custom integrations. And that’s where it goes wrong. An integration knows nothing about intent, it just moves fields. Something changes on one side? Then it stops, or it quietly writes the wrong thing. And you only find out when the invoice doesn’t go out.

At the first customer that wasn’t theory. Six packages side by side, and one of them existed only to tie the other five together. Together they cost 14,880 euros a year, and that number comes from their own books. They’re all gone now. The whole sum is on fikst.app.

software encodes a business model

And here’s the thought I couldn’t shake. Those three building blocks? Not one of them is a technical must. They’re choices. Somebody, at some point, decided.

A price per user isn’t handed down from nature. Someone figured it ought to make money, and so it became a revenue model. The implementation isn’t there because it has to be. It’s there because the software got built so that nobody stands it up without help. And that consultant layer? A whole ecosystem living off exactly one thing: the distance between the people who make the software and the people who use it. No accident, that.

Every line of code locks in an assumption about how the money gets made. And if they’re all choices, well. You can go and make different ones.

the inversion

So that’s what I did. I’m building a business system for installation companies, from air conditioning and heat pumps to electrical work, and those three blocks, I flipped every single one.

The big one’s in the foundation. Look, just about every system out there bolts AI on afterward right now. Onto a product that’s already sitting there, like a little assistant tucked in the sidebar. I did it the other way round. From the very first line of code the thing is agent-native. The whole control surface runs over an MCP layer: your data, custom objects, fields, import, export, the lot. Whatever a person can do in there, an agent can do just as well. And not because it looks spectacular today, mind you. It doesn’t, not yet, and that’s not the point. The point is your people are going to be working with AI assistants more and more over the next few years. So you want a system built for that from day one, instead of one that got it retrofitted on later.

Second thing I flipped: you pay for your office. Your field technicians cost nothing. In this trade most of your team is out in the van, and a price per user taxes exactly those people. At the first customer, sixteen of the twenty-two are on the road. So I only count the people in the office, fifty euros per office user per month excluding VAT, and that’s right there on the site. There is an implementation. A fixed price we agree on up front, depending on the size of your team and on what needs moving over. And once you go live, your first month is free, no contract. Only after that does your subscription start. The math I’ll happily leave to the customer.

Third: no consultant layer in between. I do the setup myself, together with the customer, the way that company actually works. So no implementation partner who never built the software but bills the hours anyway. Whoever builds the software is the one who hands it over, so all the knowledge sits in one place. Your question lands with the person who wrote the code. That exact distance I watched grow across fourteen projects? Here I just pull it out.

And want to keep building yourself after that? You can, with your own agent, through our MCP layer. Because anything you can set up inside Fikst, you can do over that MCP just as well. Over four hundred actions, always within the rights you have. A functional admin sets up their own fields and automations with it, no trouble. And that, that’s exactly the consultant layer from up above. Here it just evaporates.

honest about where it stands

Now the bit most product stories quietly skip. This is young.

The system’s built, and it works. It just hasn’t been through a whole lot of real companies yet, and I’m not going to pretend otherwise. Matter of fact, I put it right in the offer. Those first five customers? I don’t call them customers. Launching partners. They get a fixed price for two years and a direct line to the person who actually built the thing, and in return they help me sharpen it. And that beats selling a product as finished when it hasn’t earned the word yet. By a fair bit.

And there’s a line, and I’ll name it just as plainly. Has a company got a genuinely complex, heavy process landscape? Then that’s an SAP job, and not one for me. I know both those worlds well enough to see exactly where the one stops and the other starts. And that bit of drawing the line is the very thing that makes the rest of it believable. Because I know precisely what I’m genuinely good at.

for the ones it was never built for

Because this is what it all comes down to, in the end. Enterprise software was never built for the five-to-fifty-person company that plans work and then goes and does it, out at the customer’s site. The installer. The refrigeration engineer. The heat pump specialist. The technical service provider. They always got handed a stripped-down version of an enterprise idea. Revenue model thrown in for free.

And those years on the enterprise side, for me that’s not dead weight. That’s the whole proof, really. I know the sales and service processes this software has to carry, simply because I set them up fourteen times at the very highest level there is. And that’s exactly what I’m translating now, down to the scale and the budget of an installation company. The system’s called Fikst and it lives at fikst.app.

And what’s stuck with me most, after all those go-lives, is this. People think they’re looking at software. They’re not. They’re looking at the maker’s business model. Software remembers the choices its makers made, long after those makers have forgotten them. And the only thing I’m really doing? Remembering a different set of choices. One line of code at a time.