Building Custom Software with AI – Why the Math Has Changed

For decades a simple rule held: custom software is for large corporations. Mid-sized companies buy standard software and adapt their processes to it – not the other way around. That rule no longer holds, and the reason is AI-assisted development.

I'm not writing this as an observer but from my own practice: over the past few years I've built several internal tools myself – from my own acquisition CRM to the internal tool index that documents our deployments and standards. None of it would have paid off five years ago. Today, things like this come together in days to weeks, alongside the day-to-day business.

What has changed

Tools like Claude Code or Codex don't just write lines of code faster. They change the structure of the work: a small team – or a single person with process understanding – can now build in weeks what used to take a project team months. The bottleneck shifts from programming to specifying: whoever can precisely describe how a process should work gets working software.

That sounds trivial, but it inverts the old economics. Implementation used to be the expensive part – requirements documents, quotes, a development team, acceptance testing. The costs were so high that only high-volume processes could justify them. But once implementation becomes cheap, the equation flips: suddenly the scarce resource is no longer development time, but the knowledge of how the process actually works. And that knowledge sits inside the company, not at the vendor.

That's exactly why mid-sized companies benefit disproportionately. Corporations could always afford custom software. What's new is that a twenty-person operation can have a tailor-made tool built for its proposal workflow – or, with some guidance, build it themselves.

An example from my own practice

Our acquisition CRM is a good case study. The requirement was specific: automatically read along with emails from two company inboxes, build contacts and companies from them, manage follow-ups – without anyone having to maintain data, and without handing our entire business correspondence to a cloud provider. No standard CRM maps that; HubSpot and Pipedrive want you to adopt their process.

The classic answer would have been: live with it. The new answer was: build the tool ourselves in a few weeks, exactly along our own workflow. The decisive effort wasn't in the code but in the decisions before it – which emails count as acquisition, when a contact goes cold, what happens on replies. That's process work, not programming work. After that, the code was the smallest problem.

Where custom software makes sense now

Three patterns have emerged from our project practice:

• The gap case: there's a hole between two standard systems, bridged with Excel and email. Someone exports from system A, reformats, imports into system B – every week, for years. Exactly these bridges are cheap to build today, and they often pay for themselves within months.
• The differentiator case: a process is what makes a company distinctive – the way it calculates, configures, advises. Forcing it into standard software would mean throwing away the advantage. Custom software was always right here; what's new is that it's affordable.
• The automation case: recurring tasks with clear rules – proposal creation, data prep, reporting – can be integrated directly into the workflow with AI agents. This is the youngest category and the one with the biggest leverage, because it doesn't just produce software – it actually removes work.

Where it doesn't

Honesty requires the counter-list too. Accounting, payroll, standard sales – anything regulated by law or identical across an industry belongs in standard software. Those products contain decades of edge cases, certifications, and maintenance that nobody should rebuild just because they now could. The question is never "can we build this ourselves?" – many can, today. The question is whether the process is company-specific enough to justify its own software, and whether someone is willing to own it long-term.

How a project runs today

What has proven itself in our projects is a short, iterative sequence instead of the classic requirements document: first, capture the real process – not the documented one, but the lived one, including all the Excel workarounds. From that, a working prototype emerges within days, and the future users work with it early. Then iterate: what annoys people gets cut; what's missing gets added. After a few weeks the tool runs in production, and from then on it grows with the process.

The difference from the old model: there is no point at which a thick specification gets "frozen." The software stays as flexible as the process it maps. I've described how to set up this kind of start in a separate post: how to start AI consulting the right way.

What has stayed the same

AI writes code, but it doesn't take responsibility for it. Three things remain hand-crafted work: understanding the actual (not the documented) process, deciding what the software should deliberately not be able to do, and operations – updates, security, further development. Software nobody maintains is a liability with a user interface.

That last point in particular is underestimated. The low barrier to entry tempts you to build many small tools and then let them go feral. We responded with an internal standard: every tool is deployed the same way, documented the same way, and shows up in a central index. Anyone serious about custom software needs that kind of discipline – otherwise you just trade Excel chaos for tool chaos.

Conclusion

The question is no longer "can we afford custom software?" but "which of our processes deserves it first?" Whoever's looking for the answer shouldn't start with the technology, but with the process that creates the most friction today – where Excel lists circulate, data is maintained twice, and everyone knows it "really should work differently." That's where the first prototype pays off. And if you want to see what that looks like in practice: that's how my own CRM came about.