How I work
No surprises. Just the work.
Hiring a developer means trusting someone with something that matters. So here is exactly how a project runs: what I do, what I need from you, and what you have in your hands at the end of every phase.
Six phases, and your part in each one
Pick any phase to see what happens inside it.
Phase 1 of 6
Discovery
Understand the problem properly before anyone writes code.
What I do
- Ask about your business, not just your feature list
- Map how people actually move through what you have today
- Check what is realistic with your existing systems and data
- Agree on what "this worked" will mean
What you do
- One conversation, and honest answers in it
- Share whatever exists: notes, sketches, a competitor you like
- Tell me what you would consider a failure
What you have when this phase ends
- A written brief in plain English
- Scope, spelled out
- The one number we are trying to move
Phase 2 of 6
Planning & Architecture
Decide the shape of the thing while it is still cheap to change.
What I do
- Choose the stack and write down why
- Design the data model before the screens
- Plan the API surface your product will grow into
- Find the risky part and solve that one first
What you do
- Read one document and tell me what is wrong in it
- Confirm what is in scope, and what is deliberately out
What you have when this phase ends
- A technical plan you own
- The data model
- A scope document with the exclusions written down
Phase 3 of 6
Design & Prototyping
You click through it before it is built.
What I do
- Design the screens that carry the business first
- Make it work on a phone before it works on a desktop
- Check colour contrast and keyboard access as I go
- Turn it into something you can actually click
What you do
- Click through the prototype and react to it
- Say what feels wrong. You do not need design vocabulary
What you have when this phase ends
- A clickable prototype
- Mobile and desktop layouts
- A small design system the build reuses
Phase 4 of 6
Development
The work happens in the open, on a link you can check any time.
What I do
- Push to a staging URL you can open whenever you want
- Write code meant to be read by whoever comes next
- Keep credentials on the server, never in the browser
- Optimise while building rather than bolting it on later
What you do
- Look at staging as it changes
- Flag anything that surprises you early, not at the end
What you have when this phase ends
- A staging link that is always current
- Readable, documented code
- Steady updates in writing
Phase 5 of 6
Testing & Hardening
Find the problems before your users are the ones finding them.
What I do
- Test on real devices, not just a resized browser window
- Audit load performance and fix what is slow
- Check screen reader and keyboard paths
- Review the security-sensitive routes line by line
What you do
- Use it the way your customers will
- Try to break it, and tell me when you do
What you have when this phase ends
- A tested build
- Performance and accessibility results
- Every known issue either fixed or written down
Phase 6 of 6
Launch & After
Ship it, hand over everything, and make sure it keeps working.
What I do
- Deploy it properly, with monitoring that tells us when something breaks
- Set up analytics so you can see what people actually do
- Hand over every account, key and credential
- Stay reachable
What you do
- Own it
- Ask me things
What you have when this phase ends
- A live product
- Full access to everything it runs on
- A handover document written for a human
Four things that do not change
Whatever the project is, these hold.
You always know where things stand
No silent weeks. Work goes to a staging link you can open yourself, so progress is something you see rather than something you are told about.
Scope is written down
What is included, and what is deliberately not, exists in writing before building starts. Changes are agreed out loud, never discovered in an invoice.
You own all of it
Code, repositories, hosting, domains, keys. Everything is in your name and handed over. There is no version of this where I hold your product hostage.
Built to be handed over
Readable code, real documentation, conventional tooling. Another developer can pick this up without me, which is exactly what you want from a one-person team.
The questions you are actually asking
Straight answers, including the uncomfortable ones.
Why work with one developer instead of an agency?
You talk to the person doing the work. Nothing is lost between an account manager, a designer and an offshore build team, and no one is quietly learning on your budget. The honest trade-off is capacity: an agency can put five people on a deadline and I cannot. If your project genuinely needs a parallel team, I will tell you that early rather than take the work.
What if the scope changes halfway through?
It usually does, and that is fine. New work gets estimated and agreed before I build it, so the change is a decision you make with the cost in front of you instead of a surprise at the end. The scope document is updated so we both keep working from the same version of the truth.
Who owns the code?
You do, completely, from the first commit. The repository, hosting, domain and third-party accounts are created in your name or transferred to you. There is no license, no retained rights, and nothing you have to keep paying me for in order to keep using what you paid for.
What if I need to hand this to another developer later?
That case is designed for. The stack is mainstream, the code is documented, the setup is reproducible from the README, and the handover document explains how the system fits together. Being replaceable is a feature. It is what makes hiring one person safe.
How do you price work?
Discovery and planning come first, because pricing anything before the scope exists is guesswork. Once the scope is written down you get a fixed price for that scope in writing, and you approve it before any build work starts. Ongoing work after launch is arranged separately, so you are never locked into something you have stopped needing.
What do you actually need from me?
Less than you probably fear, but not nothing. The parts that need you are marked in every phase above: one real conversation at the start, a document to read and correct, a prototype to click through, and a look at staging while it is being built. Projects slow down when feedback stops, not when clients are busy.
What happens after launch?
Monitoring is in place, so problems surface without you having to notice them first. You have every credential and a handover document. If you want ongoing work, whether that is new features, maintenance, or just someone to call when something breaks, it is arranged as its own thing rather than assumed.
How do we start?
Send a message describing what you are trying to build or fix. If it is something I can genuinely help with, the next step is one conversation to understand it properly. If it is not, I will say so and point you somewhere better.
Still reading? Then let's talk.
Tell me what you are trying to build or fix. If I am the right person for it, I will say so and we will start with a conversation. If I am not, I will tell you that too.