People ask how long it takes. The answer is about five weeks from the first conversation to launch — sometimes four, occasionally six if the material has to be found rather than chosen.
That's faster than most people expect, and the reason isn't that the work is small. It's the order the work happens in.
What follows is a composite, drawn from six projects delivered over the past year — soloists, a chamber ensemble, conservatory faculty — folded into a single timeline. No client is named, because the useful part of this account is where the work slows down, and nobody wants to see their own project's delays in a sales page.
Weeks 1–2: one question, and the material
The first conversation is not about pages, colours or menus. It's one question: who needs to find this site, and what do they need to be able to do once they're there?
Most people arrive with an answer that sounds right and isn't. "I need a professional online presence." That's a wish, not an answer. The useful version is narrower and slightly uncomfortable: an artistic director who heard my name needs to hear me play within thirty seconds, and a parent looking for lessons needs to know whether I take beginners.
Those two sentences decide the entire structure. One puts recordings at the top; the other puts a teaching page in the main navigation. A site built without answering the question can look excellent and still fail, because it's arranged around what the musician wants to say rather than what the visitor came to find out.
This is also where I say no to things. A blog nobody will write. A shop with two items. A newsletter signup with no newsletter behind it. Each is a maintenance obligation, and an obligation nobody meets becomes visible neglect within a year.
In parallel, the material. Most musicians get me everything I need within a week or two, which is why the whole project fits into a month — but this is still the part most likely to stretch, and it's worth understanding why.
Musicians have hundreds of photographs and no criterion for choosing among them. That makes complete sense: you spent twenty years refining how you play, not deciding how you present yourself. Selecting promotional material about yourself is a separate craft and nobody teaches it in a conservatory. Faced with three hundred images, the question which one is best has no answer — each is better in one respect and worse in another — so the folder stays closed.
Which is why I don't ask for photographs. I ask for three specific ones:
- a portrait, looking at the viewer, for the biography
- a performance shot, with the instrument and the room visible
- a working shot — rehearsal, teaching, studio. The rarest and the most useful, because it's the only one that shows something other people's sites don't
Three questions, three answers, three files. The same applies to press: don't send me the review, send me the sentence. The strongest part of a review is usually one line buried in the third paragraph, and the line worth keeping is the one that says what you do, not the one that says how good you are. "An interpretation of rare intelligence" helps nobody decide anything. "He built the first movement as a single arc, never giving in to the temptation of effect" tells an artistic director what to expect on the night.
Weeks 3–5: building in the open
Here is the part that actually determines the timeline, and it's a choice about method rather than speed.
I don't disappear for a month and come back with a finished site. I build section by section and show you each one as it's done — the biography, then the calendar, then the recordings. You see the thing taking shape while it's still cheap to change.
Two things follow from that, and both of them save weeks.
Feedback arrives while it's still useful. A correction on the biography page in week three costs an afternoon. The same correction after everything is built and interlinked costs days, because the biography sets the tone the rest of the site was written against. Most of the delay in website projects isn't work — it's rework, and rework comes from finding out too late.
There is no reveal at the end. By launch day you've already seen every page and approved it once. Nothing is a surprise, which means launch day is administrative rather than nerve-racking. Projects that end with a grand unveiling end with a long list of changes, because that's the client's only remaining chance to have an opinion.
The place where this matters most is the header images. I use a layout where each section opens with a full-width image, and it isn't decoration: the image tells the reader in what frame to read what follows. The same contact page under a rehearsal-room photograph and under a photograph of a full auditorium says two different things about who you are and what you're being asked for.
This is where clients engage most, and they're right to. When you tell me which image belongs at the top of a section, you're making a content decision, not an aesthetic one — and it's right that you make it. Seeing sections as they're finished is what makes that decision possible, because you're choosing an image for a page you can actually read.
Launch, and the part that decides whether it was worth it
The site goes live in week five. Then the real variable appears.
Clients who never learn to update their own site have a good website for about eight months. Then the calendar goes stale — and a calendar whose most recent entry is eight months old communicates inactivity even when that's false. It's the only page that answers where can I hear him play, and the only content with a natural expiry date: left alone, it updates only in the wrong direction.
What holds people back isn't the software. It's the fear of breaking something. That fear makes people reread three times, postpone, ask for confirmation before every step — until a five-minute update fills an afternoon, and after two of those afternoons they stop.
What I've seen is that the ones who get past that stage manage their own site better than I would, because they know the dates and the material months before I do. The shift doesn't come from training. It comes from doing the same small operation three or four times until it stops feeling dangerous. So the handover isn't a document: it's doing the first update together, then the second one with me watching, then none.
What keeps it to five weeks
Two of these are yours and one is mine.
Answer the question before you ask for a quote. Who needs to find you, and what do they need to be able to do? Two sentences. Any developer worth hiring will ask, and the ones who don't ask are the ones to avoid.
Choose three photographs, not thirty, and one sentence per review rather than the whole piece. If you can't decide within an hour, ask someone who has heard you play to choose — they'll pick better than you will, for exactly the reason above.
Insist on seeing the work in progress. Not a mockup at the start and a finished site at the end: the actual sections, as they're completed. It's how you keep a month from turning into a quarter, and it works with any developer, not only with me.
If you'd like to talk through what your own site would need, the brief takes about ten minutes and there's no charge for the conversation that follows. Costs and timelines are set out in what a musician's website costs in 2026.