Getting the Most From a Build Partner

Bringing in an outside team to build your website is a reasonable decision. You get people who have shipped this kind of thing before, without carrying the salaries between projects.

What nobody tells you is that the outcome depends at least as much on how you run the engagement as on who you hire. We have watched capable studios produce mediocre work because the brief kept moving, and we have watched modest budgets produce excellent sites because the client was clear, decisive and available.

Here are the four things that separate those two outcomes. None of them requires technical knowledge. All of them require about an hour a week.

What a build partner is actually for

A studio is a temporary team with a permanent memory of how these projects go wrong. You are buying design and engineering, yes, but the part that earns the fee is usually judgement: knowing which third of your wish list matters, what will be painful to maintain, and where the project is likely to stall.

Which means the worst way to use one is as a pair of hands. If you hand over a fully specified list of screens and ask for a quote, you get exactly those screens, including the ones that were a bad idea. The studio had opinions; nobody asked for them.

Come with the problem, not just the solution. “We need a booking page” is a solution. “Half of our enquiries arrive by phone during service hours and we lose them” is a problem, and it might have a cheaper answer than the one you had in mind.

Step 1: Do the homework

Work out what you actually need before you go shopping. A marketing site with a blog, a product with accounts and billing, and a migration off an ageing platform are three different skill sets, and very few teams are genuinely good at all three.

Then look at what candidates have shipped, not what they say. Open the sites. Load them on a phone on a bad connection. Read the case studies for constraints and trade-offs rather than adjectives — anyone can publish a screenshot; describing why a decision was made is harder to fake.

Ask for two references and actually call them. The question worth asking is not “were you happy” but “what went wrong, and how did they handle it”. Every project has a bad fortnight. You are hiring for the response.

Finally, check the boring things: who owns the code and the design files, what happens if the project pauses, what the handover includes. An honest answer here predicts the whole engagement.

Step 2: Write goals you can check

“Modern” and “clean” are not goals; they are moods, and moods cannot be tested. Goals should be things a stranger could verify without asking your opinion.

Try shapes like these. Enquiries from the site go from a dozen a month to thirty. The team can publish a case study without a developer. Largest contentful paint stays under two seconds on a mid-range phone. The checkout works on the three browsers our customers actually use.

Each of those tells the studio something concrete about where to spend effort. Together they give you a way to say “done” that does not depend on whether you liked the shade of blue that week.

Attach a budget and a date to the list, and mark which items are negotiable. Scope, time and money: you can fix two. Deciding which two up front is the single most useful hour of the project.

Step 3: Agree the rhythm

Set the communication pattern in the first week, before there is anything to argue about. Who is the one person on your side who can make a decision. How often you meet. Where questions go, and how quickly they get answered.

Our own default is a short weekly call against something running — not slides, not a status document, the actual thing in a browser. It takes half an hour and it surfaces misunderstandings while they are still cheap. Between calls, everything goes in one written channel so it can be found again.

Two habits are worth enforcing. First, decisions get written down, even tiny ones, with the reasoning attached; six weeks later nobody will remember why the pricing page has three tiers instead of four. Second, questions get answered within a day. A studio blocked on a question is still billing, and momentum is remarkably hard to restart.

Step 4: Review as you go

Look at the work every week against the goals you wrote in step two, not against your mood that morning. Is the thing that is being built still the thing that was meant to be built?

Give feedback in terms of the problem rather than the fix. “This section does not tell me what it costs” is useful. “Make the heading bigger” is a redesign request wearing a costume, and it removes the one thing you hired a designer for.

Watch for the two classic failure modes. Scope creep — the wish list grows quietly and the date does not move. And silent drift — a fortnight of “going well” with nothing to look at. Both are fixed the same way: by asking to see something running.

Near the end, spend real time on handover. Get a walkthrough recorded, confirm you can edit what you were promised you could edit, and check that the repository, the domain and the hosting account are in your name. That last one has ruined more relationships than any design disagreement.

In short

Research properly, write goals you can check, agree how you will work, and review against those goals every week. It is not complicated and it is not free — it costs you about an hour a week and a willingness to make decisions.

Do it and a good studio will do its best work for you. Skip it and even a good studio will hand you something that technically matches the brief, which is a different thing entirely.