Services / MVP build
MVP development: idea to live product in 4–6 weeks.
One senior engineer, one written scope. You get a production application rather than a prototype, with a demo every week and your core flow live by week two.
Typically 4–6 weeks
This is for you if…
- You're pre-seed to seed and need a real product investors and users can touch.
- You know roughly what the first version should do, and you'd rather build it than specify it for another quarter.
- You want one accountable person to talk to, not an account manager relaying messages to a rotating team.
- You need auth, payments, and a working core loop: the spine of the product, not every feature on the roadmap.
What you get
- Architecture decisions documented
- Production deployment + custom domain
- Auth, payments, core flow shipping in week 2
- 30-day post-launch support included
Process
How the engagement runs.
- 01
Scope, written down
A conversation about what you're building, then a written scope: what's in, what's out, and what ships in which week. Nothing starts until we agree it describes the same product.
- 02
Week 1–2: skeleton to core flow
Repo, CI, production deployment, and auth land in week 1. Week 2 demos the core user flow, the thing your product IS.
- 03
Week 3–5: build-out
Payments, admin, edge cases, polish. Weekly demo every Friday; you steer priorities between demos.
- 04
Launch + 30 days support
Custom domain, monitoring, documented architecture decisions. I stay on for 30 days after launch, included, for the things that only surface once real users arrive.
FAQ
Common questions.
Everything you need to trust the number before you act on it.
What stack do you build MVPs with?
Next.js and TypeScript by default, the same stack I run in production on an ImmoScout24-facing platform. Postgres or MongoDB for data, Stripe for payments, deployed on Vercel or Cloudflare. If your team already has stack constraints, we scope around them.
How can the scope be fixed for software?
Because it's written down before anything is built. The scope document lists exactly which flows ship; anything outside it becomes a change order we agree on first. That discipline is what makes 4–6 weeks a real estimate rather than an aspirational one.
What if we want to change direction mid-build?
It happens, and it's usually a good sign: you've learned something. We swap it into the scope explicitly: what comes out to make room, and what that does to the timeline. What I won't do is absorb the change quietly and let the launch date drift without telling you.
What happens after the 30-day support window?
You own the code and the infrastructure outright. Standard work-for-hire IP assignment, so there's no lock-in to me. Most people either take it in-house from there or continue with a fractional retainer for ongoing feature work.
Contact
Get in touch.
If you're building something and want a hand, write to me. Same if you just want a second opinion on an architecture decision.
Prefer to talk? Grab 15 minutes in my calendar.