why i built an agent-native crm

Fourteen times I’ve taken an enterprise CRM from the first workshop to going live. Fourteen full-cycle projects, and fourteen times more or less the same ritual: an implementation lasting months, a price per user, and a layer of consultants between the people who build the software and the people who have to work with it.

I was one of those consultants myself. I still am, and I do that work happily. For an organization with a complex process landscape, that model holds up: the complexity calls for guidance, and those systems can do things nothing else can.

But somewhere between the first and the fourteenth project, a question started to nag at me. Why is it actually like this everywhere?

the pattern

Look at just about any piece of business software and you’ll find the same three building blocks. A price per user, which grows with your team and therefore grows with your success. An implementation, because the system is too configurable to set up on your own. And an implementation partner as a middle layer, one that didn’t build the software but still bills the hours to get it working.

In the enterprise segment, that can make sense. The problem is that the pattern has been copied straight down, to companies it was never meant for. A service business with eight employees quickly ends up paying several hundred euros a month on typical per-user systems, plus setup costs at the start. For an installation company or a cleaning company that just wants a grip on customers, scheduling, quotes and invoices, that isn’t a service. It’s a tollgate.

software encodes a business model

Here’s the thought I couldn’t let go of: those three building blocks aren’t a technical necessity. They’re choices.

A price per user isn’t a law of nature, it’s a revenue model. An implementation isn’t a law of nature, it’s the consequence of software built in such a way that nobody can set it up without help. The consultant layer isn’t a law of nature, it’s an ecosystem that earns money from exactly that distance between maker and user.

Every line of code encodes an assumption about how money gets made. And if they’re choices, you can make different ones.

the inversion

So that’s what I did. I’m building a business system for service-oriented SMBs, and I’ve inverted each of those three building blocks.

The biggest inversion is in the foundation. Right now, just about every system bolts AI onto an existing product after the fact, as a little assistant in the sidebar. I’ve built it the other way around: the system is agent-native from the very first line of code. The full control surface, from data and custom objects to fields, import and export, runs through an MCP layer. Anything a human can do in the system, an agent can do too. Not because that already looks spectacular today, but because over the coming years your people will increasingly work with AI assistants, and the system needs to be built for that rather than retrofitted to it.

The second inversion: one fixed price per organization per month. No price per user, no setup fee, no implementation costs, no hidden line items for integrations or storage. You pay that amount, and nothing else. I’m happy to leave the math to the customer.

The third inversion: no consultants, the maker himself. You set the system up yourself with an onboarding wizard and a work-instruction wizard that walk you through every step. No project, no middle layer. Whoever builds the software also delivers it, and the knowledge sits in one place. The exact distance I watched grow across fourteen projects has been taken out here.

honest about where it stands

Now the part most product stories leave out: this is young.

The system is built and it works, but it hasn’t been tested by many real companies yet. I don’t hide that, I make it part of the offer. The first three customers aren’t ordinary customers but launching partners: they get a fixed price for two years and a direct line to the builder, and in return they help sharpen the system. That’s a more honest story than selling a product as finished when it hasn’t proven that promise yet.

And there’s a limit I name just as honestly. If a company has a complex, heavy process landscape, that’s an SAP project and not a project for me. I know both worlds well enough to know where one ends and the other begins. It’s exactly that boundary that makes the claim credible: I know what I’m really good at.

for the ones it was never built for

Because that’s what it ultimately comes down to. Enterprise software was never built for the company of five to fifty people that plans and carries out work at customer sites. For the installer, the cleaner, the landscaper, the technical service provider. Those companies always got a stripped-down version of an enterprise idea, revenue model included.

My years on the enterprise side aren’t dead weight in that, they’re the proof. I know the sales and service processes this software has to support, because I’ve set them up fourteen times at the highest level. I’m now translating that to the scale and the budget of a small business. The system is called fikst. and lives at fikst.app.

What has stayed with me after all those go-lives is this: users think they’re looking at software, but they’re looking at the maker’s business model. Software remembers its makers’ choices, far longer than the makers themselves do. All I’m doing is remembering different choices, with every line of code.