why I built an agent-native crm

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, or a cleaning company that just wants a grip on its customers, its scheduling, its quotes and invoices? That’s not a service anymore. That’s a tollgate.

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 service-oriented SMBs, 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: one fixed price, per organization, per month. No price per user. No setup fee, no implementation costs, no sneaky line items for integrations or storage. You pay that one number and that’s the end of it. The math I’ll happily leave to the customer.

Third: the consultants are gone, and it’s the makers instead. You set the thing up yourself, with an onboarding agent and a work-instruction wizard that take you by the hand at every step. No project, no middle layer. Whoever builds the software is the one who hands it over, so all the knowledge sits in one place. That exact distance I watched grow across fourteen projects? Here I just pull it out.

And that setup goes even more direct than a wizard. Every first environment gets an onboarding agent. A few questions and it’s already laid out most of your system for you. Not all of it, of course. For the rest you just carry on 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. Right up to the standard admin role. A functional admin gets their whole system going with it, plus their own automation flows. 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 three 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 cleaner. The landscaper. 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 a small business. 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.