What to have ready before a build starts

Most projects that run long did not run long because the work was slow. They ran long waiting for something only the client could provide, and the waiting is invisible while it happens: nobody sends an update saying the build stopped nine days ago pending a logo.

Nearly all of it can be gathered before anyone writes a line of code. A client who arrives with these in hand gets a shorter project and a cheaper one, because waiting is not free for either side.

The words

This is the big one. It causes more delay than every technical problem combined, and it catches nearly everybody.

Design needs real text. A layout built around placeholder text falls apart when the actual heading is three times longer, and the version you approve is not the version you get. So the writing has to happen, and it turns out to be the hardest thing to make time for, because it is the only part of the project the client cannot delegate to us and cannot do in an afternoon.

The sentence to be suspicious of when you hear yourself saying it is "we will send the content later". It is never a small delay. It is usually the difference between a build finishing this month and next quarter.

You do not need it polished. Rough and complete beats elegant and half done, because we can edit sentences and we cannot invent your service descriptions. If writing it is genuinely not going to happen, say that at the start so it can be scoped as work rather than discovered as a blocker in week three.

The pictures

Real photographs of your actual premises, products, team and work, at the largest size you have them. Straight off the camera is ideal. A photo pulled from your old website has already been compressed once and cannot be made sharp again.

Stock photography is a fallback rather than a plan. It is instantly recognisable as stock to most people now, and a slightly imperfect real photograph of your actual shop does more for trust than a flawless picture of a stranger's.

If you are going to commission photography, book it early. It has a lead time and it tends to be discovered late.

The logo

The original file if it exists, ideally a vector, which is the kind that stays sharp at any size. File extensions like svg, ai, eps or pdf usually mean vector. A jpg or png pulled off a business card does not, and it will look soft on a large screen and worse on a high resolution phone.

If the original is genuinely lost, say so early. Redrawing a logo is a small, cheap job when it is planned and an annoying one when it surfaces the day before launch.

The access

The list that stalls launches, because it always involves a password somebody had five years ago.

Your domain registrar login. Your current hosting, if there is a site already. Analytics, if you want the history kept. Any account for a system the new site has to talk to: payment processor, booking tool, mailing list, accounting software. If somebody who no longer works with you set those up, start the recovery process now, because recovering an account you cannot prove you own takes weeks and depends entirely on a support queue.

While you are in there, check whether the domain is in your name. That is worth doing regardless.

The one decision maker

Name the person who signs things off, and give them the time to do it.

Reviews by committee are where schedules go to die, not because groups have bad taste but because getting four people to agree takes a week per round and nobody owns the outcome. One person who can decide, with a way to consult others when it matters, moves faster and produces a more coherent result.

The same person needs actual capacity. Reviewing software properly is real work landing on top of somebody's existing job, and a project that needs six reviews from someone with no free hours is a project that has already slipped.

What you should not prepare

A few things people arrive with that cost them money.

A finished design, unless you have a designer. You are paying for design; specifying it in advance means either paying twice or getting a worse result than the one you could have had.

A detailed technical specification. Describe the problem and how your business actually works. Choosing the technology is our job, and a spec written without knowing the options tends to lock in decisions that turn out to be expensive.

A feature list copied from a competitor. It tells us what somebody else built and nothing about why, and half of it will be things their business needed and yours does not.

The short version

Words, pictures, logo, logins, and one person who can say yes.

That is the whole list. A client who turns up with those gets a build that runs on engineering time rather than waiting time, and it is by a distance the cheapest thing you can do to lower the price of a project.