What I Would Tell Myself Before Starting a 25-Day Build Sprint

The 25-day sprint is done. The four sites are live. The summary sounds clean: four platforms, one developer, 25 days.

The reality was messier. Here is what I would tell myself before doing it again.

The Mindset Going In

I started the sprint with a rough idea that it would feel like four short projects in sequence. It did not. It felt like one long project with four simultaneous threads, each pulling in a different direction.

The mental model I wish I had going in: you are not building four things. You are managing four contexts simultaneously. The work is not just coding — it is the overhead of knowing where each project is, what it needs next, and which one to prioritize when two of them need attention on the same morning.

If you go in expecting the sprint to feel like focused project work, you will be surprised by how much of the day is coordination overhead. Going in expecting coordination overhead makes it easier to plan for it.

What Broke First

Not the code. The schedule.

Day one: I planned to spend the full day on santoshpaudel.me. I also spent three hours on a client call that was not on the calendar. Day one ended with four hours of actual work instead of eight.

The sprint schedule did not have slack. Every day needed to deliver its planned output for the timeline to hold. When day one delivered half the output, day two needed to compensate. That debt accumulated.

The lesson: a sprint this aggressive needs a 20% time buffer baked in from the start. Not for rest. For the things that go wrong — client calls, unexpected complexity, a bug that takes six hours instead of one.

The Tools That Mattered Most

In order of actual impact:

Claude Code — The most important. The difference between getting four projects done in 25 days and getting them done in 60. Not because it writes code you do not understand — because it writes code you would have written yourself, just faster.

Supabase — The second most important. A database with auth, storage, and real-time built in, a generous free tier, and a dashboard that lets you inspect data without writing queries. Removing the backend infrastructure problem from the sprint was significant.

Vercel — Third. Deployment that requires no configuration and takes 90 seconds. Without this, the deploy step would have cost a full day of setup per project.

Antigravity — Fourth. The context preservation made multi-project work manageable. Without it, switching between projects was noticeably more disorienting.

What mattered less than I expected: the specific framework version, the component library choice, the specific AI model for most tasks.

What I Would Change About the Pacing

Day 1–5 was too front-loaded on santoshpaudel.me. By the time I got to the gaming platform backend (day 16–22), I was tired and the client's requirements were more complex than initially scoped. The hard client work should have come earlier in the sprint when I had more energy.

I also should have done the SEO layer across all four projects together on day 3, not spread across the final days. SEO setup is repetitive and systematic — it is faster to do it four times in a row than to context-switch back to it four times at different points in the sprint.

Advice for Anyone Doing Something Similar

Write the session notes. At the end of every work session, write 3–5 sentences about where you are, what the next step is, and what the open questions are. This is the most important habit for multi-project work. It takes 3 minutes and saves 20 minutes every morning.

Scope the client project tighter than you think you need to. Scope always expands. Document the agreed scope before writing a line of code.

The sprint is when you build. The work after is when you learn. The sites go live at the end of the sprint. The interesting data — what gets traffic, what converts, what needs to be fixed — comes in the three months after. Give yourself space after the sprint to do something with what you built.

---

Related Posts

• —How I Shipped 4 Full-Stack Platforms in 25 Days — the sprint this post reflects on, with the timeline and stack breakdown
• —Running 3 Projects at Once: My Multitasking System With Claude Code — the multitasking system, built partly in response to the early sprint mistakes described here
• —The New Solo Dev Stack: What Replaced a 5-Person Team in 2026 — the broader case for the tools that made the sprint possible despite the pacing problems

---

Thinking about doing a build sprint of your own? I consult with developers and founders on sprint planning, stack selection, and workflow setup. Get in touch before you start — 30 minutes of input before day one saves days of correction mid-sprint.