How we work

No mystery, no drift, no surprise invoice

Most bad experiences with a developer come down to three things: nobody wrote down what was being built, the price moved, and the client could not see progress. The process below exists to remove all three.

01

15 minutes, free

The call

You describe the problem rather than the solution. I ask the awkward questions — who is this for, what happens when it works, what have you already tried. By the end of it you will know whether I can help and roughly what it costs, and if the answer is that you need something other than what I sell, you will hear that on this call rather than after an invoice.

What I need from you

  • A rough idea of what you want to change
  • Anything you already have — a site, designs, a spreadsheet

02

Within 3 working days

The proposal

A written scope: what is being built, what is explicitly not being built, the fixed price, the payment split, a delivery date, and a list of exactly what I need from you and when. Nothing starts until you have read it and said yes. If it is a larger project I will usually propose a small paid discovery first rather than guess at a big number.

What I need from you

  • A decision
  • 50% deposit to book the slot in the calendar

03

3–12 weeks typically

The build

You see working software every week — a link you can click or a build on your phone, not a percentage-complete report. Feedback is cheapest early, so the rhythm is deliberately frequent. Change requests are welcome; they get scoped and priced before they happen so there is never a surprise at the end.

What I need from you

  • Content, photos and logins as listed in the proposal
  • Feedback within a couple of days so the schedule holds

04

Go-live, then optional

Launch and after

Deployment, testing on real devices, analytics verified, structured data checked, and a handover call with written documentation covering how to change things yourself. Final payment is due at go-live. After that you can take a care plan, call me when you need something, or never speak to me again — all three are fine.

What I need from you

  • Domain access, or I can walk you through it
  • Final 50% on go-live

The commitments

Things I will not do to you.

Hold your domain hostage

The domain is registered in your name with me as technical contact. Same for developer accounts, ad accounts and analytics. Leaving is a matter of removing my access, not a negotiation.

Bill for the scope I got wrong

If I underestimated something in a fixed-price build, that is my problem and my cost. You pay for changes you asked for, not for my estimate being optimistic.

Promise a Google position

Nobody can guarantee rankings. What I will commit to is the work, the reporting, and telling you plainly when a channel is not paying for itself.

Disappear after go-live

Faults in what I built get fixed for 90 days at no charge, care plan or not. That is a warranty, not a favour.

Sell you the bigger thing

If a £750 website solves it, I will not talk you into a £5,000 app. The whole model depends on people recommending me afterwards.

Hide behind a ticket system

You get my mobile number. During a build you can ring it. It is one of the few genuine advantages of a studio this size and I am not going to pretend otherwise.

The honest bit

What you give up by hiring one person

It would be dishonest to list the advantages and stop there.

A one-engineer studio has no bench. If I am ill, the week slips. If you need five people for six months, I am the wrong call and I will say so. I take on a limited number of projects at a time, so occasionally the answer is that I cannot start until next month.

What you get in exchange is that nothing is lost in translation, decisions happen in a phone call rather than a change-request process, and the person who knows your project best is always available — because there is only one of him.

Working with an existing developer?

That is common and usually fine. I can pick up a codebase someone else wrote, work alongside an in-house team, or hand over cleanly to whoever comes next.

What I will not do is rubbish the last developer's work to win the job. Most bad code was written under bad constraints, and you were probably not told about them.

Start with the fifteen minutes.

No preparation needed and nothing to sign. Worst case you get a free opinion from someone who has built this sort of thing before.