"How long until something is actually working?" is the question clients ask most on the first call. My answer has been the same for a while: four weeks to go from an idea to a web app in production, with a clearly defined scope. It's not a magic template, it's a process I've refined project after project. Here's exactly how I run it.
Week 1: Discovery and architecture
No code yet. This week is about defining the real scope: what problem the app solves, who uses it, which flows are critical and which can wait for v2. I come out of this with a short document (never more than 2-3 pages) covering the data model, technical architecture, and a prioritized feature list. The goal is as little ambiguity as possible before writing the first line of code.
Week 2: Working MVP
I build the full skeleton: auth, database, main routes, and the critical flow end to end, even if it's ugly. I'd rather have something clickable and functional than a polished interface with no logic behind it. This is the week real data-modeling problems tend to surface, and they're much cheaper to fix now than in week 4.
Week 3: Polish and content
With the logic working, it's time for real UI, loading and error states, validation, responsive design, and real content instead of lorem ipsum. This is also when the client starts actually using the app, not just watching a demo, and that's when the UX adjustments that never come up on a call finally surface.
Week 4: QA, deploy and handoff
Manual testing of critical flows, a basic security review (RLS, environment variables, permissions), production deploy, and minimal documentation so the client can operate the app without depending on me for everything. I close with a handoff call and a prioritized backlog for v2.
The stack I use
- Next.js + TypeScript for the frontend and API routes.
- Tailwind so I don't waste time fighting CSS.
- Supabase for auth, database, and storage without building infrastructure from scratch.
- Vercel for continuous deploy from the first commit, not just at the end.
Lessons learned
- Scope creep kills timelines, not technical complexity. Any new feature that shows up mid-project goes straight to the v2 list, no exceptions.
- Deploying from day one, even when there's nothing to see yet, avoids last-minute surprises with the production environment.
- Showing the ugly MVP in week 2 gets better feedback than showing something pretty in week 4, because the client reacts to function, not color.
- A short, signed-off scope document is worth more than a hundred meetings. It cuts "but I thought this was included" conversations down to almost zero.
If you have an idea and want to know whether it fits a four-week process, reach out and let's look at it together.