Build vs buy software: when AI can replace a SaaS

A subscription renewal is a very effective way to get interested in building software.

You look at the bill, look at the few features you use, and think you could make those yourself. With an AI coding agent you can now test that thought cheaply.

Sometimes building your own version is a good decision. Sometimes you trade a predictable bill for an unfinished project that interrupts you whenever you’re busy. I wouldn’t decide from the prototype alone. I’d decide from the work the replacement leaves me responsible for.

Start with the part you use

A commercial product serves many customers, while your replacement only needs to serve you, or one team. That’s what can make building realistic.

Take a translation service. The full product might have a web editor, reviewer permissions, integrations with several repositories, and workflows for external translators. A solo developer might only need to find new strings, produce draft translations, and save files in Git. Copying the whole service is a big project, and automating that smaller workflow is a much smaller one.

Before asking an agent to build anything, I’d write down what I use in an ordinary month, including the occasional jobs. Exporting everything may happen once a year, but it’s essential when it does.

Describe outcomes. “Produce reviewable translation files when English strings change” is more useful than “clone the dashboard”. Once the scope is clear you can compare the real subscription with the real replacement, instead of the vendor’s whole price with your favorite part of the implementation.

A cheap operation can sit inside an expensive workflow

Translation is easy to mistake for finished once the text exists. An agent can send strings to a model and get translated strings back, and you still don’t know whether a short label fits its context, whether a warning became ambiguous, or whether a longer sentence still fits a mobile screen.

The W3C’s explanation of localization goes beyond language: number formats, cultural conventions, and how dates are shown all affect whether an app works for a locale.

So I’d separate generating drafts from approving them. The tool can help with the first and leave the second to someone who can judge the language and the product context. Buying a translation service doesn’t solve that automatically either, you still need to know which work the service does, which an external reviewer does, and which is yours.

Email works the same way. Sending one through an API is a small operation, and running a dependable email workflow includes what happens when delivery fails or a recipient replies.

What owning it costs me

I run my newsletter on Sendy, a self-hosted app I bought once for $69, on a $12 a month DigitalOcean droplet, sending through Amazon SES for about $100 a month. When I checked hosted newsletter tools in May 2026, Kit would have cost $1,179 a month for a list this size and Bento $1,500.

That’s a big saving, and it came with work no invoice shows. After a server migration, my send rate dropped to 20 emails a second and a newsletter took eight hours to go out. Then a Cloudflare proxy setting blocked the bounce webhooks. I wrote both up in solving an issue with sending emails on my server. Before that, a process got killed on the server, and later a bot added around 5,000 addresses through the signup form.

At 150,000 subscribers the saving covers a lot of evenings like those. With a list of a few thousand people, a hosted tool would cost far less, and the comparison could easily go the other way.

Keep cash and time visible separately. Pretending your time is free hides the trade-off, and pretending every hour could have been billed at a premium rate is just as misleading. If the project delays paid work, the delay belongs in the decision. Count the vendor’s work you already do too: if the existing product needs constant manual cleanup, keeping it costs time.

The build or buy calculator does this arithmetic. Its starting example is a hypothetical €80 monthly subscription against €8 of replacement services, twelve hours to build, one hour a month of maintenance, and time valued at €30 an hour. That’s €816 against €960 after a year, a €144 saving. With one month running both systems, the saving falls to €64, and the replacement first costs less at the end of month eleven.

If maintenance takes three hours a month instead of one, the same replacement costs €1,536 in the first year. It could still be worth it for privacy or a better workflow, but then you’re paying for those.

I’d record time during the experiment, including the evening spent investigating a broken run and the time spent reviewing generated code.

For the translation tool, I’d also write down what the replacement must do before I cancel anything. Existing approved translations survive unchanged, a rerun leaves no unexplained differences, and someone can finish an update when the usual operator is away. If meeting that adds several days of work, update the estimate. Finding out the subscription was reasonably priced is a fine result, and you can keep a small piece of the automation or stop while the old workflow still works.

Maintenance has an owner even when it’s easy

A small script can stay stable for years, so a custom tool doesn’t automatically become a miserable second job. But somebody has to own it when something changes.

A service changes its API, an access token expires, a file format gains a field, or someone feeds yesterday’s input into today’s job. An agent can help fix those, and you still need to notice the problem, give it enough context, review the change, and decide when it’s safe to resume.

An integration with GitHub, for example, has to handle rate limits, whether you write the client yourself or an agent generates it.

I’d want a replacement to fail in a way I can understand. A clear error and an unchanged source file are much easier to deal with than a script that silently overwrites half-translated output. That may add little code, but it has to be in the job description you give the agent.

The cost of being wrong changes the answer

A tool that drafts a weekly report can be wrong without much damage if someone reviews the report. A tool that deletes records, sends invoices, or changes account access needs a different level of care.

So I’d decide what happens after a bad result. Can I rerun the operation? Can I restore the previous state? Will anyone outside the company receive something before I review it? A complicated read-only dashboard can be a comfortable first replacement, and a small automation that can move money a poor one, whatever the screen count.

Buying doesn’t remove risk either. A vendor can lose data or change a feature you depend on. A suitable vendor takes responsibility for a defined part of the work, so read what that part includes. If the contract leaves all the meaningful recovery work to you, the comparison is closer than the marketing suggests.

Ownership can be worth more than the savings

I’d sometimes build a tool even if the saving were small. I might need it to work offline, keep the data on my machine, or avoid a workflow the commercial service pushes on me.

A local tool can be deliberately narrow. It can store plain files in a folder I already back up, and have one button because I have one job for it. Several of my apps started like that, as tools I built for my own work. A general-purpose product needs account settings, team administration, billing, and onboarding that I have no reason to reproduce.

Ownership also means accepting limits. If I need the tool on several devices, want other people to use it, and expect changes to sync, my small local replacement has a different scope now. I’d write those limits down before building, or the modest replacement slowly grows into the service I was trying to stop paying for.

You can build around a product you keep

The decision doesn’t always involve cancelling something. You can keep a dependable service for the central operation and build the awkward connection around it: keep the accounting product and automate the import, or keep the email provider and create the report you wish its dashboard had.

This fits when the vendor does the important work well but fits poorly at the edges of your workflow. It also separates annoyance from economics, since a missing button can make a service feel much worse than it is.

I’d check whether the product has an API or useful exports before imagining a replacement. Sometimes a scheduled script is enough. Other times the limitation is central to the product, and if every action needs a manual workaround, another integration may preserve a workflow that should change.

Try the replacement while the original still works

I’d avoid making the cancellation the first milestone.

For a translation tool, I’d begin with a copy of the files, generate drafts, and compare the result with the existing process. Then I’d run the replacement through a real update: change an existing string, remove one, add a placeholder to another, and ask someone who reads the target language to review the output in the app. A tool that handles its first input can still fail on the second run.

The overlap also gives you a fallback. If the custom tool breaks before a deadline, you finish the job with the existing product and repair the replacement later. Running both costs money for a while, and I’d count that as part of the migration rather than rushing to cancel a bill and buying myself an urgent project. I went through how to run that comparison in testing your SaaS replacement before cancelling the original.

Leave yourself a way to stop

A replacement should have an exit too. Store the inputs in a format you can reuse, document how to run the job and what a successful result looks like, keep credentials out of the repository, and write recovery instructions your future self can follow.

If you’re learning these habits, my free Git course covers versioning your work so you can inspect and undo changes.

Decide before you start how much time the experiment gets. If the replacement keeps uncovering jobs you don’t want to own, keeping the subscription is an acceptable result.

For the tools that do fit, AI makes a smaller, more personal version practical. I listed 15 apps you can vibe code instead of subscribing if you want a starting point. Build one narrow workflow, use it on real work, and look at it again once the excitement of the first working screen has passed.

If you sell the product someone is replacing, How to compete with AI-generated SaaS clones is the other side of this.

Want me to talk about your product? You can sponsor this site.