Build vs buy software: when AI can replace a SaaS

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

You look at the bill, look at the few features you use, and think you could make those features yourself. With an AI coding agent, you can now test that thought much more 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 would decide from the work the replacement leaves me responsible for.

The interesting question is how to make that comparison honestly, without treating every subscription as waste or every custom tool as a maintenance disaster.

Start with the part you use

A commercial product serves many customers. Your replacement only needs to serve you, or a particular team.

This difference can make building realistic.

Imagine a translation service. Its full product might support a web editor, reviewer permissions, integrations with multiple 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 would be a substantial project. Automating that smaller workflow is a different task.

Before asking an agent to build anything, I would write down what I use during an ordinary month. I’d include the occasional jobs too. Exporting everything may happen only once, but become essential when it does.

This list should 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 actual subscription with the actual replacement. Otherwise, you tend to compare the vendor’s entire price with your favorite part of the implementation.

A cheap operation can sit inside an expensive workflow

Translation is a good example because producing text is easy to mistake for finishing the job.

An agent can send strings to a model and receive translated strings. That doesn’t establish whether a short label is appropriate in its context, whether a warning became ambiguous, or whether a longer sentence still fits a mobile screen.

The W3C’s explanation of localization includes more than language. Number formats, cultural conventions, and the presentation of dates can all affect whether an application works for a locale.

For our hypothetical replacement, I would distinguish generating drafts from approving them. The tool could help with the first while leaving the second to someone who can evaluate the language and product context.

This doesn’t mean buying a translation service solves every quality problem automatically. You still need to know which work the service does, which work an external reviewer does, and which work belongs to you.

The same issue appears elsewhere. Sending an email through an API is a small operation. Running a dependable email workflow includes what happens when delivery fails or a recipient replies. Producing a PDF is one operation. Getting the right PDF to the right person is a wider job.

Compare the costs you can observe

Suppose a hypothetical subscription costs €80 per month. That’s €960 over a year.

A replacement might require €8 per month in infrastructure and model calls. It looks like an obvious saving until you add the time spent making and looking after it.

Say the initial version takes twelve hours and maintenance takes another hour each month. Those are invented numbers for the example, and they are deliberately ordinary. You now have twenty-four hours of work to compare with €864 in avoided cash spending.

There isn’t a universal correct hourly rate for that calculation. If you’re building for enjoyment on a quiet weekend, cash savings may matter more than a consulting rate you wouldn’t otherwise earn. If the project delays paid work, the delay belongs in the decision.

I would keep cash and time visible separately. Pretending my time is free hides the trade-off. Pretending every hour could have been billed at a premium rate can be equally misleading.

Also include the vendor’s work you already perform. If the existing product needs constant manual cleanup, keeping it has a time cost too.

The comparison gets more useful when both sides describe the workflow as you experience it.

You can also turn the estimate into a limit on the experiment. Using the same invented numbers, suppose you value an hour of this work at €30. The €864 cash saving leaves room for about 29 hours over the first year before the replacement costs as much as the subscription.

The estimate of 24 hours fits, but it leaves little room for surprises. Twelve hours building and one hour maintaining it each month costs €720 in time. Add €96 in running costs, and the replacement totals €816 against the €960 subscription. The estimated first-year saving is €144.

If maintenance takes three hours each month, you spend 48 hours over that year, including the initial build. At the same illustrative rate, the total becomes €1,536. The replacement could still be worthwhile for privacy or a better workflow. You would be paying for those benefits.

I would record time during the experiment. Include the evening spent investigating a broken run. Count reviewing generated code too. A model doing the typing doesn’t make the surrounding work disappear.

For our translation tool, I would also write down what the replacement must do before cancelling the subscription. Existing approved translations need to survive unchanged. A rerun should leave no unexplained differences. Someone needs to be able to finish an update when the usual operator is unavailable.

If meeting those conditions adds several days of work, update the estimate. The useful result of a trial can be discovering that the subscription was reasonably priced. You can keep a small piece of the automation, or stop, while the old workflow still works.

Maintenance has an owner even when it is easy

A small script can remain stable for years. A custom tool doesn’t automatically create a miserable second job.

But somebody needs to own it when something changes.

A service may alter its API. An access token expires. A file format gains a new field. A person accidentally feeds yesterday’s input into today’s job.

An agent can help fix those issues. You still need to notice the problem, provide enough context, review the change, and decide when it’s safe to resume.

For example, an integration using GitHub must handle rate limits. Whether you write the client manually or ask an agent to generate it doesn’t remove the upstream service’s limits.

I would want a replacement to fail in a way I can understand. A clear error message and an unchanged source file are much easier to handle than a script that silently overwrites partially translated output.

That requirement may add little code. It still needs to be part of the job description you give the agent.

The cost of being wrong changes the answer

A tool that creates a weekly draft report can be wrong without causing much damage if someone reviews the report.

A tool that deletes records, sends invoices, or changes account access deserves a different level of care.

I would 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?

Those questions matter more than the number of screens in the app.

A complicated read-only dashboard might be a comfortable first replacement. A small automation with permission to transfer money might be a poor one.

Buying doesn’t eliminate risk either. A vendor can lose data or change a feature you depend on. The advantage of a suitable vendor is that they take responsibility for a defined part of the work. Read what that responsibility includes before counting it as a benefit.

If the contract leaves all meaningful recovery work to you, the comparison may be closer than the marketing suggests.

Ownership can be worth more than the savings

I would sometimes build a tool even if the direct financial saving were small.

I might need it to work offline or keep the data on my machine. The commercial service could also be pushing me into a workflow I don’t want.

These are legitimate reasons to own the software.

A local tool can be deliberately narrow. It can store plain files in a folder I already back up. It can have one button, because I have one job for it.

That simplicity can be valuable every day. A general-purpose product may need account settings, team administration, billing, and onboarding that I have no reason to reproduce.

But ownership also means accepting limits. If I need the tool on several devices, want other people to use it, and expect changes to synchronize automatically, my small local replacement has acquired a different scope.

I would write those limits down before building. Otherwise, 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 buy a dependable service for the central operation and build the awkward connection around it. Keep the accounting product, automate the import. Keep the email provider, create the report you wish its dashboard had.

This approach makes sense when the vendor does important work well but offers a poor fit at the edges of your workflow.

It also helps separate annoyance from economics. A missing button can make a service feel much worse than it is. Fixing that annoyance with a small integration may save you from rebuilding the whole thing.

I would 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. If every action requires a manual workaround, adding another integration may preserve a workflow that deserves to change.

You have to look at what happens in practice, rather than choosing buying or building as a general philosophy.

Try the replacement while the original still works

I would 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. Preserve the original so mistakes are cheap to examine.

Then I’d run the replacement through an actual update. Change an existing string. Remove one. Introduce a placeholder into another. Ask someone who can read a target language to review the output in the application.

A tool that handles its first input can still fail during the second run. Repeated use exposes assumptions the first demo never touched.

The overlap period also gives you a fallback. If the custom tool breaks before a deadline, you can finish the job using the existing product and repair the replacement later.

There is a cost to running both temporarily. I would count that as part of migration, rather than rushing to cancel a bill and discovering that I bought myself an urgent project.

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 make recovery instructions understandable to your future self.

If you are learning these habits, my free Git course covers versioning work so you can inspect and undo changes. The point here is to make an ordinary mistake recoverable before the tool becomes important.

I would also set a limit on the experiment. Decide how much time is reasonable before you start. 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 and more personal version practical. Build one narrow workflow, use it on real work, and look again after the excitement of the first working screen has passed. That’s when you have enough information to decide whether to cancel the subscription.

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