What I take on
Fast Delivery.
Built by me, start to deploy
A working MVP in 7 days, and a date I beat rather than miss.
Why this gets built
What usually kills a small build is not the engineering. It is a week waiting on a decision, and a scope that grew while nobody was looking. I would rather put something real in front of you in a week and be wrong about part of it than be right about all of it in three months.
What I build
- Seven days to an MVP that runs: the path a user takes, the data behind it, deployed somewhere you can open it.
- One scope agreed on day one. Anything added after that moves the date, and you hear that when it happens rather than at the end.
- Progress you can open yourself every day, instead of a status message saying it is going well.
- If you set the date, I work to beat it. If it cannot hold, you hear that in the first week, while it is still cheap to change.
- What ships in week one is real code in your repository, not a prototype to be thrown away when the proper build starts.
How long it takes
7 days to a working MVP. Each slice after that gets its own date.
Seven days is real for one product path with one person who can make decisions. It is not real for something that needs a vendor's approval, a licence, or four people agreeing on the rules first. I will tell you which one yours is on the first call.
What ships
- A deployed MVP at the end of week one
- Repository and deployment in your own accounts
- The written scope, and what was cut from it
- What the next slice would take
- Handover session
Tech stack
Next step
Let’s talk, 30 minutesNeed this built?
Tell me what you’re running and where it breaks. Half an hour is usually enough for me to say what it takes and what I’d do first.