When you need a tool, a familiar decision comes up: should you buy something ready-made or build it yourself?
With agents, that question needs a clarification. Asking one to build an app is still building: you end up with software of your own to maintain. The third option appears when you delegate a task directly and receive a result, without creating your own app to handle it each time.
Homemade mini-apps are an example of building with AI: small tools to organize expenses, convert data, or automate a repetitive task. They can be very useful, especially when they solve a personal problem a generic product does not account for.
But being able to get one running easily does not mean it is free to maintain. The question is no longer just “Can I build it?” It is also “Do I want to take responsibility for it?”
Building has become more accessible
On October 14, Epic Games introduced a preview of its new launcher with a provocative line: programming is hard, so they had used vibe coding to build a new one.
It is worth reading that in context. Epic describes the release as a preview, “a speedboat and not a yacht,” and says it is still missing features. Its team said it started from scratch and used AI to write and review features in a different technology stack. It is an interesting story about how the development process is changing, but it does not prove that building and sustaining a large product has become trivial.
Now imagine a homemade tool for preparing a newsletter. Generating the text and a preview may meet a personal need. Turning it into an email service for other people adds work: handling bounces, unsubscribes, permissions, and delivery failures, as well as protecting recipients' data.
That example raises a useful question: what work does it take to keep something running once it is no longer a personal experiment?
AI reduces the cost of getting started. It does not automatically remove what comes next.
Three questions to guide the decision
To compare buying software, building your own tool, or delegating a task to an agent, I would suggest three simple questions.
1. Does it differentiate you?
If the tool contains an important part of what makes your business different, keeping it under your control may be worthwhile. You might be able to tailor it more closely to the way you work and change it as the business changes.
If the task is common — billing, email, payroll, or contact management — there may already be products that handle it with more experience, integrations, and support.
Not everything a company uses has to be a competitive advantage. Sometimes it is better to let another organization handle the parts that do not set you apart.
2. What happens if it fails?
A small tool for organizing your notes can stop working and become an annoyance. A system that processes payments, customer data, or financial records can cause much greater harm.
The more costly an error would be, the more reliability, security, recovery, and support matter. In a regulated process, applicable obligations and controls matter too.
Buying a product does not make risk disappear. You still need to evaluate the provider, understand where the data lives, and know how an outage is handled. But it may mean that some of the maintenance and operations sit with a team dedicated to them.
3. Who will maintain it two years from now?
An agent can create a first version very quickly. Updates, dependencies, permissions, backups, changes to external services, and errors that show up in real use still remain.
For an internal tool used by one person to solve a small problem, that commitment may be reasonable. For a product customers or revenue depend on, someone needs to own it and decide how it will be tested, secured, and fixed.
The cost is not just building it. It is keeping it useful and safe.
If you delegate a one-off task — converting a copy of a file and reviewing the result, for example — you may not need an app to maintain. You still need to consider execution costs, the data and permissions the agent receives, and how you check its work. If you end up using it every day with your own integrations and rules, you have an automation someone needs to maintain.
A mental guide, not a formula
You can organize the decision around two questions: how much the tool differentiates you and how costly a failure would be.
- It differentiates you and a failure would have little impact: building it may make sense, perhaps with AI assistance.
- It does not differentiate you and a failure would be costly: buying a proven solution may save work, after evaluating the provider.
- It is for personal or internal use, solves a narrow problem, and may have a short life: a small agent-built app may be enough.
- It is a one-off task and its result can be reviewed: delegating it to an agent may avoid building your own tool.
- It differentiates you, but a failure would be costly: building it calls for engineering, testing, review, and a clear owner.
This is not a formula that decides automatically. It helps put costs on the table that often stay out of the first demo.
Mini-apps have their place
I do not want this to sound like a warning against building. Being able to solve small problems with tools of our own is valuable. A simple app can fit one person’s workflow exactly, save steps, and teach a lot in the process.
The limit appears when we confuse “it works on my computer” with “it is a service ready to depend on.” If the tool starts handling sensitive data, money, or other people’s work, responsibility changes. We need to think about access, backups, testing, privacy, and what happens when something breaks.
There is also a difference between building something to learn and making it a critical part of an operation. The same code can be an excellent experiment and a poor piece of infrastructure.
The first day got cheaper; the commitment remains
Agents are moving the starting point. For many ideas, it is now easier to prepare a prototype, automate a step, or check whether a solution could work.
That does not mean we should replace every subscription or build our own app for everything. Time once spent on the first implementation can reappear as time spent on review, maintenance, and support.
So, when facing the next software decision, I would ask less “Can we make it?” and a little more: “What advantage would it give us, how much would a failure cost, and who will keep it running?”
Building it got cheaper. Taking responsibility for it did not.
References
- Epic Games, introduction to the new Launcher preview, October 14, 2026.
- Ars Technica, Epic says its new vibe-coded Launcher is faster than Steam, October 14, 2026.
This reflection continues a conversation I explored in From software access to work completed and Too much code: who reviews all of it?. Take care.