Web app development: build, buy, or just automate it?

You have three options, not one

Every "we need a web app" conversation has three possible endings, and only one of them involves paying developers for months.

1. 1Buy it. Someone has almost certainly built this. It will be cheaper, better tested, and available on Monday. Your process is rarely as unique as it feels from the inside.
2. 2Automate it. If the problem is data moving between systems and humans doing the moving, you do not need an application. You need the hand-off to happen without anyone touching it.
3. 3Build it. Correct when your process is a genuine competitive advantage, or when nothing off the shelf fits without contorting the business around it.

The order matters. Most businesses start at option three because it is the most exciting and the one everybody asks for. It should be the last resort, not the first instinct.

The manual task that should have been automated

The most common version of this: a team is copy-pasting leads between forms, spreadsheets and a CRM by hand. It works, until it does not. Data gets missed, follow-up gets slow, and eventually nobody trusts the numbers.

The instinct is to commission a platform that does everything in one place. The cheaper answer is usually an agent handling the hand-off end to end, the data moves itself, the reporting finally lines up, and the team gets back the hours they were spending on clerical work.

A custom build would have solved it too. It would also have cost many times more and taken months longer, and you would still be maintaining it in three years.

When building genuinely is right

• The process is your edge. If how you do it is why customers choose you, do not flatten it to fit someone else's software.
• Off-the-shelf forces you to change the business. Configuring is fine. Contorting is not.
• Integration is the whole point. Sometimes the value is precisely in joining systems nobody else joins.
• Scale makes license fees absurd. At some volumes, per-seat pricing stops making sense and a build pays for itself.

And the warning that applies to all four: automate a broken process and you just get to be wrong faster. The same is true of building software around one. If the process itself is a mess, fix that before you commit it to code, because code makes bad processes permanent and expensive to change.

A cheap way to decide

Before you get a development quote, do this. Write down the process as it actually happens today, not as it is supposed to. Count the hours it consumes. Identify which steps are decisions and which are just moving data around.

If most steps are data movement, you have an automation problem, and it is solvable in weeks. If most steps are genuine judgment calls that need an interface and a workflow, you may have a real software problem, and now you can scope it honestly, because you understand it.

The cheapest software project is the one you talked yourself out of.

The questions to answer before anyone writes code

If you have worked through build, buy and automate and still think you need custom software, good. Now answer these before a developer starts, because each one is cheaper to resolve on paper than in code.

1. 1What is the problem, in one sentence, without mentioning a solution? "Our techs waste 40 minutes a day on job sheets" is a problem. "We need an app with offline sync" is a solution wearing a problem's clothes.
2. 2What does phase one deliberately not do? Write it down. This single list is the difference between a project that ships and a project that keeps growing.
3. 3Which steps are decisions and which are just data moving? The data movement should be automated. The decisions need an interface. Confusing the two builds the wrong thing.
4. 4How will we know it worked? A number, agreed before the build, that someone is accountable for.
5. 5Who maintains it in two years? If the answer is nobody, you are building a future problem.

That third question is the one that most often changes the project. Teams describe a complex system and, when you map it properly, discover that most of the complexity is people manually shuffling information between tools that could simply talk to each other.

And the rule that catches everything else: automate a broken process and you just get to be wrong faster. Software makes whatever it encodes permanent and expensive to change. If the process is a mess today, committing it to code does not fix the mess. It gives it a version number.

If you do build, build it to last

Custom software is a long-term commitment dressed up as a project. A few decisions early determine whether you own an asset or inherit a liability.

• Boring technology. Choose the stack with the deepest hiring pool, not the most interesting one. In three years you will want someone to be able to pick it up.
• Accessibility from the start. WCAG is not a compliance checkbox to add later; retrofitting it is materially more expensive than building with it in mind, and it makes the product better for everyone.
• Performance as a requirement. If it has a browser-facing side, Core Web Vitals apply. Slow internal tools are a tax your team pays every single day.
• Documentation that survives the developer. The bus factor is real, and it is usually one.
• A way out. Data export, hosting you control, code you own. Assume you will one day want to move.

None of that adds much cost up front. All of it saves a great deal later, and every item on the list is something businesses discover the hard way at the least convenient possible moment.

Frequently asked questions