Website Development Outsourcing: A Practical Buyer's Guide

Buying software development is unusual: you pay in advance for something you cannot inspect, produced by people you may never meet, and you often lack the expertise to judge quality until much later.

This guide is written for the person doing the buying. Some of it works against our own short-term interest, which we think is the point.

Decide what you are actually buying

"A website" covers wildly different things, and the gap is where most budget disputes begin.

A brochure site presents your company. The work is mostly design and content; the technical part is modest. Judge it on how it looks and how fast it loads.

A platform does something — takes bookings, lists properties, processes applications, shows data. The visible design is maybe a third of the work. The rest is logic, edge cases, and the admin side nobody sees.

An integration project connects systems that were not built to talk to each other. Almost all the cost sits in the parts you cannot see, and the estimate is least reliable here because it depends on the other system's behaviour.

Be explicit about which you are buying. Quotes that seem far apart are often answering different questions.

The questions that actually separate partners

Anyone can show a portfolio. These questions are harder to fake:

"What would you push back on in this brief?" A partner who has read carefully will have found something — an assumption, a feature that will cost more than it is worth, a timeline that does not survive contact with your approval process. A partner with nothing to say has either not read it or will not tell you when things are going wrong.

"Show me an admin panel you built." Every agency has attractive homepages in its portfolio. The admin side reveals whether they think about the people who use the system daily, which is where quality really shows.

"What happens if we want to change direction in month two?" Listen for a process, not reassurance. "We would re-estimate the affected scope and show you the trade-off" is a real answer. "We are flexible" is not.

"Who owns the code, and can we host it ourselves?" The right answer is immediate and unambiguous. Hesitation here tells you something important.

"What went wrong on your last project?" Everyone has one. The answer reveals whether they learn or deflect.

Reading a quote properly

Compare quotes on scope and assumptions, not on the total.

A quote that lists what is excluded is usually written by someone who has done this before. Content entry, data migration, third-party licences, and browser support for old software are the classic gaps — each can add real cost after you have signed.

Watch for estimates with no contingency. Software estimates are wrong; a partner who has built in room for that is being realistic, not padding.

Be suspicious of a number far below the others. It usually means a narrower reading of scope, junior staff, or a plan to recover margin through change requests. Occasionally it means someone is hungry and good — but ask what is excluded before you assume that.

Contract terms that matter more than day rate

Intellectual property transfers on payment. Not on completion, not on final sign-off. If a dispute arises, you do not want your code hostage to it.

Source code in a repository you own, from the first commit. Not delivered as a zip at the end.

A defined warranty period for defects — typically 30 to 90 days after launch, covering things that do not work as specified, not new requests.

Named people. If you are paying for seniority, the contract should say who. Otherwise the senior developer you met in the pitch can be replaced quietly.

An exit clause that includes handover. What happens to credentials, documentation, and work in progress if either side ends it.

How to tell it is going well

You do not need technical expertise to read these signals.

You see working software early and often — not screenshots, not progress percentages, but something you can click. If the first demo is in month three, that is a warning regardless of what the reports say.

Bad news arrives early. A partner who tells you in week two that a feature will take longer than estimated is doing their job. One who tells you in week nine has been hoping.

Questions keep coming. A team that has stopped asking has either finished understanding your business — unlikely — or stopped trying.

The demo matches the brief, and where it does not, they say so first.

Common expensive mistakes

Paying for a specification you cannot evaluate. If the discovery phase produces a document you do not understand, it has failed. Ask for it in plain language.

Approving designs without seeing content. Layouts with placeholder text hide the problem that your real headings are three times longer.

Leaving content until the end. It is the single most common cause of delayed launches, and it is almost always the client's side that is late. Start writing it while development runs.

Treating launch as the finish. The first month after launch produces the most valuable feedback you will ever get. Budget for acting on it.

When not to outsource

If the thing being built is the core of your business and you intend to keep improving it for years, building internal capability will serve you better in the long run. Outsourcing is right for the first version, for capacity, and for capabilities you genuinely do not need permanently — not as a permanent substitute for owning your own product.

A good partner will tell you this. It costs them the larger engagement and earns the relationship, which is usually worth more.

If you are evaluating proposals right now and want an outside read on one of them, we are happy to look — including when the answer is that someone else's is the better fit.