Why your software proposal looks so complicated (and how to tell if it needs to be)

You explained the problem clearly. You need a way for customers to book appointments, or staff to log jobs, or orders to stop falling through the gaps between two systems that don't talk to each other. The proposal that came back is three pages long, mentions technologies you've never heard of, and costs more than you expected.

This happens a lot. It doesn't always mean the proposal is wrong, but it's worth understanding what's driving the complexity before you sign anything.

Complexity has two sources

Some complexity is real. If the software needs to handle sensitive data, connect to several existing systems, or be used by thousands of customers simultaneously, the proposal is going to reflect that. Corners cut here cause real problems later.

But a lot of complexity in software proposals isn't driven by the problem. It's driven by habit. Developers reach for the tools and approaches they know, and those tools are often sized for organisations much larger than yours. The result is infrastructure designed for a business ten times your size, maintained at a cost that makes no sense for what you actually need.

The difference matters because you're the one who'll pay to maintain it.

The questions worth asking

Before accepting a proposal at face value, three questions will tell you a lot.

How many people will use this? Software used by five members of staff and software used by five thousand customers at once are different problems with different price tags. If the answer is a small number of known users, the architecture should be simple. If the proposal reads like it's designed for scale you're not going to reach for years, ask why.

What happens if it goes down for an hour? For most small businesses, the honest answer is: it's inconvenient, but not catastrophic. If that's true for you, the level of redundancy built into the proposal should reflect it. Systems designed to never go down cost significantly more to build and run. That investment is worth it when downtime has serious consequences. Yet, it often isn't.

Who looks after it when something goes wrong? This is the question most proposals don't answer clearly. A system can be impressively built and completely unsupportable if the person who built it isn't available, or charges a premium every time you need a change. Simple systems built by someone who stays reachable are almost always worth more to a small business than complex systems built by someone who moves on.

What good infrastructure actually looks like for a small business

The goal isn't impressive technology. The goal is software that does its job reliably, that you can afford to run, and that someone can fix when it breaks.

For most small businesses, that means: a system that restarts itself if something crashes, a backup that runs automatically, a simple alert if something stops working, and a clear line to the person responsible for it. That's it. None of it requires the kind of complexity that tends to appear in enterprise-grade proposals with enterprise budgets.

The simplest system that solves your problem well is almost always the right answer. Complexity is a cost driver, not a feature.

Red flags in a proposal

A proposal is worth scrutinising more carefully when it includes technology that requires specialist knowledge to maintain, ongoing fees that aren't clearly tied to specific work, and language that makes it hard to take the code elsewhere if you need to. These aren't always dealbreakers, but they're worth understanding before you commit.

The clearest green flag is the opposite: a proposal that describes what will be built, what it won't do, what it will cost to run, and what the handover looks like if you ever need to move on. That's a developer who is confident enough in their work not to make leaving difficult.

If you've received a proposal that's hard to evaluate, I'm happy to give a second opinion. Sometimes the complexity is genuinely warranted. Often there's a simpler approach that costs less to build and less to run, and I'll tell you either way.

Have you ever been quoted something that felt out of proportion to the problem? I'd like to hear about it in the comments.