w4web.

How I work ยท No surprises

Four steps from
first call to live.

I keep the process simple because complicated processes hide problems. You always know what is happening, what it costs and what comes next.

The four steps

  1. A proper conversation

    Twenty minutes on the phone. What the problem is, who it affects, what success looks like. No pitch deck, no sales script.

  2. A written plan and a price

    Scope, milestones and a fixed price or a clear day rate. You know exactly what you are getting before anything starts.

  3. Build in the open

    Weekly demos on a staging URL. You see progress and can change your mind while it is still cheap to do so.

  4. Launch and stay supported

    Deployment, monitoring, handover docs. Then ongoing support if you want it, and no lock-in if you do not.

What to expect

The standards I hold myself to

One point of contact

You brief me, I build it, I deploy it. Nothing gets lost between a salesperson and a developer.

Replies within a working day

Usually much faster. If something is on fire, you will hear from me the same hour.

A staging site from week one

Real URL, real data where possible, so feedback is about the actual thing rather than a mockup.

Tests and documentation as standard

Not an optional extra. They are what make the second and third releases uneventful.

Your repository, your hosting

Everything lives in accounts you own from day one. Leaving is as simple as changing a password.

Honest about trade-offs

Every shortcut has a cost. I will tell you what it is so you can decide whether it is worth paying.

Straight answers

Questions I get asked

Do you charge fixed price or day rate?
Both. Well-defined projects work best at a fixed price so you carry no risk on estimates. Ongoing or exploratory work runs on a day rate with an agreed cap.
How long does a typical project take?
A small business website usually takes three to six weeks. An MVP is typically four to eight weeks. Larger applications are broken into milestones so you see something useful early rather than waiting months.
What do you need from me to get started?
A conversation about the problem, access to any existing systems or content, and someone who can make decisions. I will handle the rest and tell you exactly when I need your input.
What happens if I want to change something mid-project?
You say so at the weekly demo. Small changes get absorbed. Bigger ones get written up with the impact on time and cost so you can decide with your eyes open.
What happens after launch?
You get deployment notes, documentation and a handover call. From there you can take a support retainer, call me when you need something, or hand it to another developer. All three are fine.

Ready for a project
that runs like that?

Whether you have a full specification or a spark of an idea, the first step is the same: a straightforward conversation.