SENIOR PRODUCT DEVELOPMENT
Build the product before you build the team.
You do not need a technical co-founder to get a working product. You need a senior developer for the length of the build, and clean code you can hand to a team later.
THE SITUATION
The founder's development problem.
You have a product idea, some validation, and a runway that does not stretch to a full engineering salary, let alone the months of hiring before that salary produces anything.
The alternative is to buy the build. Get a working product in front of real users, then make the hiring decision when you know what you are actually building.
THE BETTER FIRST MOVE
Build the first version, learn from real users, then hire for the product you know you need.
WHAT I BUILD FOR FOUNDERS
What I build.
MVPs
A genuinely working first version: not a prototype that needs throwing away, and not a two-year platform you do not need yet.
SaaS products
Subscriptions, user management, admin tooling, and multi-tenancy cover the infrastructure every SaaS needs before it can charge anyone.
Mobile apps
iOS and Android from one React Native codebase, which is usually the right economics at your stage.
Web applications
Dashboards, marketplaces, internal tools, and customer portals built around the workflow that matters.
BUILT TO BE HANDED OVER
Built for the team you'll hire later.
The most expensive mistake in early product development is code that only works for the person who wrote it. When you hire your first engineer, they inherit whatever exists.
I build under the assumption that someone else takes it over. The goal is a product your next hire can improve, not rewrite.
Conventional patterns
Code built with familiar, maintainable patterns instead of clever shortcuts only one person understands.
Real documentation
The decisions, setup, and operating details your future engineer needs are recorded where they can find them.
Sensible commits
A visible project history that gives the next team a useful record of what changed and why.
Clean handover
Deployment, walkthrough, and access organised before the project closes instead of being treated as an afterthought.
Full IP transfer
On completion, the product and its code are entirely yours.
SCOPE HONESTY
What I'll tell you before we start.
Founders get sold more software than they need. Before quoting, I will tell you which parts of your scope belong in version one and which are genuinely version three, even though the smaller build means a smaller invoice.
If your idea can be validated without custom development at all, I will say so. A no-code build or landing page test costs a fraction of an MVP and can answer the same question.
“The smaller build is sometimes the better decision.”
The operating principle
HOW A BUILD RUNS
Visible work. Clean handover.
Scope
A conversation about what you are building and why, then a written scope with a fixed price.
Design
Interface and flow before code, so you are approving a product rather than a description.
Build
Visible progress in your repo, a check-in rhythm that suits you, and decisions raised as they come up.
Launch
Deployment, documentation, and a walkthrough of how it all fits together.
After
I step away. Available again when version two needs building.
FOUNDER QUESTIONS
Clear before you commit.
The commercial, technical, and ownership details should be clear before you spend a pound on development.
Do you take equity instead of payment?
No. Fixed fee, and you keep all your equity.
Who owns the code?
You do, completely, on final payment.
What if I need changes after launch?
Most founders do. We agree a scope and price for the next round the same way as the first.
Can you help me decide what to build?
Within reason. I will push back on scope and suggest what to cut, but I am a developer rather than a product strategist, so I will not pretend to validate your market for you.
How long does an MVP take?
Most land between six and twelve weeks depending on scope. I will give you a real number after seeing the requirements.
What happens when I hire an engineer?
They inherit a documented, conventional codebase and I brief them on it. That outcome is what the whole build is designed for.
Ready to build the first version?
Tell me what you are making and who it is for. I will tell you what it takes to build and what it should cost.