Approach
Six stages, and what each one asks of you.
Most of the risk in a software project is not technical. It is agreeing what “done” means, and finding out too late that it meant different things to different people.
So each stage below says plainly what I do and what I need from you. If you can only give an hour a fortnight, that is workable — but it needs saying at stage one, not stage four.
01
Conversation
A call or a long email. You describe what is going wrong and what you have tried. I ask the awkward questions early — who else touches this, what happens if it is wrong, what have you already bought that has to keep working.
You
An hour, and honesty about the mess.
Me
A straight answer on whether I am the right person. No charge.
02
Scoping
I write down what gets built, what explicitly does not, and what it costs. Short and in plain English — something you could hand to a colleague who was not on the call. Nothing starts until you have read it and agreed.
You
Read it properly and push back on what is missing.
Me
A fixed scope and a price you can plan against.
03
Build
Working software on a real URL from the first week, updated as it goes. You can open it whenever you like. This is deliberate: it is much cheaper to say “that is not what I meant” in week two than in month three.
You
A short look each week and quick answers when I am blocked.
Me
Visible progress and early warning if something slips.
04
Review
The people who will actually use it get their hands on it, with real data, before launch. Not a demo — a proper go at breaking it. Whatever they find gets fixed or gets written down as a known limit, never quietly ignored.
You
The right people, for a real session, not a five-minute look.
Me
Fixes, and an honest list of what is not changing before launch.
05
Launch
Data migrated, everything under your accounts and your domain, and a rollback plan for the first fortnight. I am reachable on the day and the day after — launch is when the real edge cases turn up.
You
A date that suits your quiet week, not your busiest one.
Me
Migration, cutover, and someone on the end of the phone.
06
Handover & support
You own the code, the accounts, and the documentation from day one — not on request, and not held over you. Ongoing support is a choice you make afterwards, and you can take the whole thing to another developer without asking me first.
You
Decide whether you want ongoing support or not.
Me
Repository access, credentials, and written handover notes.
Stage one costs you an hour.
That is the whole commitment to find out whether this is worth doing at all.
Start a conversation