You have a system that needs building. Maybe your team is copying data between three tools by hand, maybe your booking process lives in a spreadsheet that only one person understands, or maybe you’ve outgrown the off-the-shelf software you started with. So you start looking for a software development company — and within an hour you’re staring at a dozen websites that all say the same things: agile, scalable, end-to-end, trusted partner. None of it tells you who can actually deliver what you need.
This guide is about how to tell them apart. What to ask, what the answers mean, and which warning signs are worth walking away from.
Work out what you’re actually buying first
The biggest source of failed software projects isn’t bad developers. It’s a brief that was never clear enough to build from.
Before you talk to anyone, write down three things in plain language:
- The problem, not the solution. “Our warehouse staff re-enter every order into the accounting system” is a problem. “We need a custom ERP” is a solution you’ve guessed at, and it may be the wrong one.
- Who touches it. List the people and systems involved. Staff, customers, suppliers, your accounting software, your website, that ancient database in the back office.
- What success looks like. Fewer errors? Hours saved each week? Being able to take twice the orders without hiring? Put a number on it if you can.
A good development company will interrogate this and sometimes tell you that you don’t need custom software at all — that configuring an existing platform, or connecting two you already pay for, will get you most of the way for a fraction of the cost. That advice is a strong signal you’re talking to the right people.
Questions that separate a real partner from a sales pitch
Most vendor conversations follow a script. Break it with specific questions and listen carefully to how they answer.
- “Who will actually write the code?” Ask whether the people in the meeting are the people doing the work, whether any of it is subcontracted, and where the team sits. There’s nothing wrong with distributed teams — but you should know before you sign, not after.
- “Walk me through a project that went badly.” Every firm with real history has one. What you’re testing is honesty and what they changed afterwards. A flawless record usually means a short one.
- “Who owns the code and the accounts?” The repository, the hosting, the domain, the third-party API keys — these should be in your name or transferable to you. Get it in writing.
- “What happens when something breaks at 4pm on a Friday?” Ask about support hours, response expectations and how issues are logged. Building software is a project; running it is forever.
- “How do you handle changes mid-project?” Requirements always shift. You want a clear process for pricing and approving changes, not silence followed by an unexpected invoice.
- “Can I see the work in progress?” Regular demos of working software beat status reports. If the first time you see anything is at the end, you’ve taken on all the risk.
Fixed price, time and materials, or retainer
How you pay shapes how the project behaves, so it’s worth understanding the trade-offs rather than just comparing bottom-line numbers.
Fixed price works when the scope is genuinely well defined — a marketing site, a specific integration, a clearly bounded tool. It gives you budget certainty, but it also means every change becomes a negotiation, and the developer carries the risk of estimating wrongly, which tends to show up as conservative scoping.
Time and materials suits work where discovery is part of the job, which is most internal systems. You get flexibility to change direction as you learn. The trade-off is that you need visibility — agreed sprint budgets, regular reporting and the ability to stop.
Retainers make sense once software is live and evolving, or when you need ongoing development capacity without hiring. Be clear about what’s included: does support consume the same hours as new features, or are they separate?
A useful middle path is paying for a short, fixed-price discovery phase first — a few weeks of scoping that produces a technical plan, wireframes and a realistic estimate. You end up owning a document you can take anywhere, even if you don’t proceed with that firm.
Warning signs worth walking away from
Some patterns show up again and again in projects that go wrong:
- A quote arriving with no questions asked. If nobody has explored your process, the number is a guess and the gaps will surface as variations later.
- Technology chosen before the problem is understood. Framework loyalty is fine; leading with it isn’t.
- No written scope. Email threads and verbal agreement are how two reasonable parties end up in a dispute.
- Vague documentation promises. Ask specifically what you’ll receive at handover: setup instructions, architecture notes, credentials, deployment steps.
- Reluctance to discuss what happens if you leave. A confident firm has no problem explaining how you’d move on.
Local, offshore or somewhere in between
Offshore development can be excellent and it can be cheap, but rarely at once, and the deciding factor is usually how much translation your project needs. Software that encodes your specific business rules — pricing logic, compliance steps, the exceptions your staff handle by instinct — requires a lot of back-and-forth with the people who understand it. Time zones and language gaps make that harder and slower.
Projects with tightly specified requirements and less ambiguity travel better. Whatever you choose, judge it on the overlap in working hours, how easily your team can talk to the developers, and who is accountable when priorities need reordering.
If you’re weighing up options for a custom system, an integration between tools you already use, or ongoing development support, the team at Web Champion is happy to talk through the problem before anyone talks about a build — and to tell you honestly if there’s a simpler way to solve it.