Should you build your own tools now that coding agents make it cheap?

The renewal email lands for a tool you open once a week, for one feature, and the price went up again. A coding agent could write that feature this afternoon. So should you build your own tools now that agents make the first version cheap? Plenty of companies have decided yes. In McKinsey's State of AI survey this year, 32% of respondents said their organization had dropped at least one software purchase because it could be built in-house with agentic coding tools. Those are organizations with engineering teams, though. When you work alone, every tool you build has one maintainer for as long as you keep it, and that maintainer is you. That changes which tools are worth building, and the build vs buy guides ranking today, mostly written by vendors and agencies for companies, leave it out.

TL;DR: Coding agents make a tool's first version cheap. Owning it costs what it always did. Build your own tools when you're the only user, they sit in work you do every week, and you'd fix them the day they break. Keep paying for anything that holds customers' money, logins or data, where a bug becomes someone else's problem.

Why build your own tools now?

A coding agent can now turn out a first version in an afternoon, and companies are already acting on it. McKinsey's 2026 survey of 1,719 respondents found 32% had passed on buying software to build it with agentic coding tools, and 41% in the technology sector (the business paper Mint, reporting McKinsey's The state of AI in 2026 (opens in a new tab)). Retool, which sells a platform for building internal tools, surveyed 817 builders, its own customers among them. 35% had already replaced at least one SaaS tool with a custom build, and 78% expected to build more this year (Retool (opens in a new tab)).

In a February Hacker News thread about AI and SaaS, one commenter described the shift as AI making the "20% happy path" so easy to finish (Hacker News (opens in a new tab)). The happy path is what an agent makes cheap. A vendor's other work is the edge cases, the patches and the support, and that's the part of the renewal you'd have to replace yourself.

The renewal is a real cost too. Vertice, which sells software-buying tools to finance teams, puts SaaS price inflation at 13.2% in its 2026 index (Vertice (opens in a new tab)), and a vendor can raise prices, drop the feature you use or shut down. Both sides carry risk. When you work alone, every risk of a tool you build lands on you.

What does a coding agent leave you to pay for?

A coding agent leaves you everything that happens after the first version works. Dependencies need updates, the API you call changes its auth, and a backup can fail for a month before you notice. When the tool breaks on the day you need it, there's nobody to file a ticket with.

The surveys see this too. In Retool's report, 26% of respondents named maintenance burden as a blocker, only 8% used AI-written code without changing it, and 44% tested it thoroughly before deploying. Those are people already building, inside companies with IT departments behind them.

Security decides how far a weekend build can go. Veracode tested more than 100 models in 2026 and found that roughly 44% of AI code generation tasks introduced a risky vulnerability. The average security pass rate was 56%, against 55% in its first report a year earlier, so newer models write working code without writing much safer code. On cross-site scripting the pass rate was 15% (Veracode (opens in a new tab)). A script that runs on your laptop can live with that, because nobody else can reach it and you can read what it does before you run it. A tool on the internet behind a login can't, and the moment you deploy one, you're running a security product.

Another commenter in the same Hacker News thread said what they get from a big vendor: "I know they read CVEs and issue patch notes." Build the tool and that work is yours.

Which tools should a solo developer build?

Build the tools that pass three tests. I've been building for the web since 2014, and the tools worth owning have always been small, boring and close to my own work. Agents make more of them affordable without changing what the good ones share.

1. You're the only user. One person, your own data, nothing a customer logs into, ideally nothing reachable from the internet at all. That removes most of what Jetadmin, a vendor in this space, lists as the real cost of building: authentication, permissions and audit logs. Its summary: "The first version is the cheap part, and AI makes it cheaper still" (Jetadmin (opens in a new tab)).
2. It sits in work you do every week, and the paid tool fits it badly. Fit is the reason to build: a script that turns your invoices into the format your accountant wants, a dashboard over your own database, a checklist that runs before every release. If the paid tool already fits and your only complaint is the price, a few afternoons of fixes can cost more than the subscription did.
3. You'd fix it the day it breaks. You can check this one before you build: look at the last script you wrote for yourself and whether you fixed it when it stopped working. A tool you'd let rot costs you twice, once to build it and again to move back to something you pay for.

What should you keep buying?

Keep buying whatever fails on someone else. When your invoice script breaks, you lose an hour. When your homemade login breaks, your users lose their accounts.

Payments, user authentication, sending email at volume and anything with a legal requirement attached (tax invoices, data protection) belong on the buy side, however easy the first version looks. What you pay for there is the patch notes and someone on call at night when it goes wrong. A third commenter in the same thread explained why a big company keeps paying: "I don't have to pay my own people to worry about maintenance or vulnerabilities." A solo developer has less spare attention than any company's IT team, so the argument gets stronger when you work alone.

The same goes for tools whose roadmap moves faster than yours would. If the vendor ships a feature a month that you'll use, your version starts falling behind the week you finish it.

How do you get out of a tool you built?

Decide how you'd stop using a tool before you build it, the same way you'd check a vendor's export before you sign up. Keep the tool's data in a format something else can read, such as CSV, SQLite or plain Markdown, so going back to a paid tool takes one import. Export everything from the subscription before you cancel it, because the vendor's export is often the only full copy of your history.

Then write tests for the behaviour you depend on. In six months you won't remember why the invoice script rounds the way it does, and neither will the agent you ask to change it. The tests are what tell that agent it broke something.

The exit test also catches the tools you shouldn't build. If you can't say how you'd get your data out, or you'd be stuck the month you stopped maintaining it, keep paying for that one.

What to do before you cancel the subscription

Write down the one feature you actually use, then run it through the three tests: only you use it, it's weekly work the paid tool fits badly, and you'd fix it when it breaks. If it passes, have an agent build that one feature, with tests, and run both side by side for a month before you cancel. If it touches someone else's money, logins or data, keep paying and spend the afternoon on your product.

More posts on building alone with coding agents are on the gabs.app blog. I'm a full-stack engineer and my work is on gabs.app; if you're hiring, the contact form comes straight to me.