AI makes it easier to get a first version of software working. That makes build versus buy a more interesting decision, but the first version is only part of what a business takes on. My starting point is to compare four options: buy something, build something, connect what already exists, or leave the process alone for now.
The question I want to answer is: Is this a capability I actually want to own?
A cheaper beginning changes the decision
There is evidence that businesses are reconsidering what they purchase. In McKinsey’s August 2026 survey, 32% of respondents said their organizations had decided against buying at least one software product or feature because they could build it internally with agentic coding tools.
Retool’s 2026 report found that 35% of teams surveyed had replaced at least one SaaS tool with a custom build. Its sample was 817 Retool customers and builders surveyed in late 2025. That is a useful view of people already close to custom software, rather than a representative sample of every business.
Both findings describe reported choices. Neither establishes that the resulting software costs less to own, stays useful, or survives its original builder moving on. Those are questions I would put into the decision itself.
Understand what you are replacing
In The Reinvention Fallacy, I wrote about rebuilding a system as a way of understanding it, sometimes arriving at something much like what was there before. A faster way to write code does not remove that possibility. It can make the reconstruction easier to begin.
Before replacing a tool, I would follow one real piece of work through it. Who enters the information? Who corrects it? What happens when it is incomplete? Which exceptions does somebody handle without documenting them? The screens are visible. The agreements and recovery procedures around them may be harder to see.
A useful problem statement names the person, the repeated difficulty, and the consequence. “We need our own CRM” has already selected a solution. “Someone has to reconcile three records before responding to a customer” gives us something to investigate.
Four options worth keeping open
Buy when the standard workflow is good enough
I would lean toward an existing product when the work is common and its constraints are acceptable. Evaluate the full arrangement: configuration, migration, training, support, integrations, and the ability to leave. A subscription delegates some responsibility, but someone inside the business still has to own how the tool is used.
Build when the difference matters enough to maintain
A custom build becomes more compelling when the workflow is important, understood, and poorly served by available products. I want a specific explanation of the mismatch, a bounded first release, and a named person responsible after launch. “We can generate it” establishes feasibility. It leaves the operating commitment undecided.
Compose when the missing piece is a connection
Sometimes the existing tools do their individual jobs well. The gap is between them: a handoff, a shared identifier, a status update, or a small interface. Connecting those tools can preserve capabilities that would be expensive to recreate. The connection still needs error handling, clear data ownership, and a person who notices when it fails.
Do nothing yet when the problem is still uncertain
A manual process can be a reasonable experiment. If the work is infrequent, the rules keep changing, or nobody can describe the consequence of leaving it alone, I would gather more evidence before adding software. Set a review condition, such as a repeated error or a measured time burden, so waiting is a deliberate choice.
How I applied this to my own website
When I updated this site’s inquiry and newsletter paths, I kept WordPress for publishing, Jetpack for business contact forms, and Mailchimp for newsletter signup. The custom work connected the journeys and preserved useful source context. It did not recreate a publishing platform, form service, or email platform.
I separated a request for help from a newsletter subscription, added a service choice to the contact journey, and connected the page context to the received inquiry. Then I checked the actual path with labeled tests: stored responses, inbox arrival, and newsletter confirmation. Those checks established that the tested paths worked. They did not establish new customers or revenue.
I have also chosen to build a custom system: Erich OS, my project hub. Its purpose is to keep project context, decisions, tasks, and AI-assisted work connected. I own the responsibility for that choice. The existence of a working application does not settle whether every part deserves continued investment.
Write the ownership decision on one page
For a business evaluating a new tool, I would write down six things before committing:
- The problem: who experiences it, how often, and what it costs in time, errors, or missed work.
- The alternatives: buy, build, compose, and wait, including the smallest credible version of each.
- The full cost: setup, subscriptions, hosting, review, maintenance, support, and eventual migration. Estimate time as well as money.
- The owner: who handles access, updates, failed integrations, data recovery, and changing requirements.
- The test: what observable change would make the effort worthwhile, compared with today.
- The exit: how to retrieve the data, continue the work manually, or replace the tool if the experiment disappoints.
This connects to how I think about state, trajectory, and feedback. Record the current state, choose the change you want to see, and come back with evidence. A launch date tells you when software became available. It does not tell you whether the work improved.
Choose a responsibility you are willing to carry
I want to use the increased ability to build to make better choices about what deserves building. Sometimes that will mean custom software. Sometimes it will mean a small connection between existing tools, or a clearer agreement about who does the work.
If you are evaluating a website or business systems change, my skills and services page describes the work I can help with. For a defined implementation, Market Jack’s website and systems project service explains the project path. Tell me what you are trying to accomplish, what already exists, and where the current process falls short.