Most of us still price software with a pre-agentic cost model. We skip work because it used to be expensive, without checking whether it still is.

The way I see it, five prices changed at once.

The old cost model	The new one
Engineering time decides build vs. buy	Building your own makes sense far more often
Don't reinvent infrastructure	Reimplementing infrastructure can be reasonable
A specialized tool rarely pays for itself	A tool for one person can be worth building
Implementation is the bottleneck	Verification is the bottleneck
Make developers faster	Rethink which problems are worth solving

Build vs. buy

Build vs. buy used to be an argument about engineering time. Developers cost more than a licence, and the licence worked on Monday. When an agent writes most of the code, a narrow tool that does exactly what you need can cost less than configuring the general one, or waiting for its vendor.

Cheaper to build isn't the same as cheaper to own. Security, updates and support got cheaper too, because the same agents patch, upgrade and answer questions. But that work never ends, and a vendor spreads it across every customer while you carry yours alone. That's why the usual advice is to keep buying the system of record and build only the narrow tools around it. Sometimes the right answer is to go without.

I started at the edges. I built two ERP modules from scratch: Veikko for service and maintenance of heavy equipment accessories, and Tossu for planning and controlling their production. Both work on the existing ERP's data instead of replacing it.

Documents went the same way. Changing a picking list used to mean a proprietary form designer and a consultant, with a lead time measured in weeks. I replaced the form designer with a build script and an agent that edits it. Then I built Spooldoc, which turns IBM i spooled files into PDFs and emails. That's output management, software companies usually buy. Spooldoc doesn't replace the ERP. It reads what the ERP already prints.

Sometimes the gap is wide enough to build the product itself. I looked for service management software for IT, HR and the other desks. Atomicwork and Console were too expensive. In Freshworks and Zendesk, the AI was bolted on, and it wasn't good enough in Finnish. ServiceNow was too complex and too enterprise. So I built Nitoa, with tickets, a self-service portal, a service catalog, a knowledge base, an AI copilot and workflows that run across departments, in English and Finnish.

I'd go further than the usual advice. With those modules built, the ERP itself no longer looks out of reach. I'd be ambitious enough to build that too, as long as every part of it can be checked.

Infrastructure

"Don't reinvent the wheel" made sense when a wheel took a year. Parsers, file formats and protocols were where projects went to die, so you bought them or borrowed them. Now an agent can write a narrow version for your exact case, with input you know, in days instead of months. One dependency fewer is a benefit of its own.

What decides whether it's wise is whether you have something to check it against: a spec, a test suite or the original implementation. The agent-built rewrites that worked all had one. Passing those tests still isn't the same as being trustworthy, especially for code that faces input you don't control.

Spooldoc doesn't ask the IBM i to convert anything. It reads the raw *SCS print stream and parses it itself, in about 150 lines of TypeScript, with its own EBCDIC tables for eight code pages, including 278 for Finland and Sweden. Nothing gets installed or configured on the IBM i.

Tools for one

A tool that saved one person an hour a week used to be a hobby, because writing it cost more than it saved. Now it's often a short conversation.

There are two traps. The first is building tools for building tools. Models and harnesses change every few months, so the tools worth building pay off right away. The second is forgetting that disposable code is cheap because nobody maintains it. Once other people depend on a tool, it isn't disposable anymore.

My MCP server for Db2 for i started because I was tired of pasting table definitions into AI chats. Eight months later it's at version 2.12, with 20 tools, and it's downloaded more than 5,000 times a month on npm. That's more than IBM's own MCP server for IBM i. At that point the cost isn't writing it. It's maintaining it.

Verification

This is the row I'd underline. An agent can build far more than it can check on its own, and more output means more to check. So the work moves to the checks: something that tells you, cheaply and every time, whether the output is right.

Two conditions make a check worth having. The agent can't be able to edit it, or it will find a way to pass. And a check that the output is well-formed is not a check that it's correct. Where there's no clear pass or fail, ambition gets expensive.

In Spooldoc, every template tag is checked against the definition before anything renders. In the Db2 for i server, the tool that helped most lets the IBM i check the SQL before it runs. Both checks sit outside the agent, and both catch structure, not meaning. Meaning gets checked by a person: in Spooldoc, every extracted field next to the printed page.

Which problems

Doing the same work as before, but with AI, gives a smaller speedup than you'd expect, because the parts AI doesn't help with still take as long. The bigger gains are in work that used to be too expensive to bother with. The question changes from "how do we go faster" to "what did we never do". Cheap work still has to be the right work.

In ERP that list is long: the Excel workbook fixed by hand before every meeting, the document change waiting for the next release, the integration nobody quoted because it served one warehouse. None was worth a project. Many are now worth an afternoon, as long as you can check the result.

Be as ambitious as you can check.

We still price software with a pre-agentic cost model

Build vs. buy

Infrastructure

Tools for one

Verification

Which problems

Links

More from the blog

In open source, the code is the cheap part

AI sessions are contractors. Always-on agents are hires.

Eight months of an MCP server for Db2 for i