Shipping Products in 6-Day Sprints

8 min read
indie-hackingproductivitymethodologyshippingsprints

In the age of AI-assisted development, a solo founder with the right stack can ship what used to require a small engineering team. But faster tools don't automatically mean faster shipping. You still need a system.

Here's the 6-day sprint methodology I use to ship products at Helsky Labs.

Why 6 Days?

Traditional agile sprints are 2 weeks. That's designed for teams with coordination overhead, stakeholder reviews, and cross-functional dependencies. As a solo developer, I have none of that.

Six days is long enough to build something meaningful, short enough to maintain intensity, and leaves one day for rest before the next cycle. The constraint forces ruthless prioritization.

It also aligns with a simple truth: if I can't ship a meaningful version in 6 days, I'm probably building the wrong thing or building it wrong.

The Super Individual Era

We're in a unique moment. Claude Code, Cursor, and similar tools have created what's being called the "super individual"—a solo founder who orchestrates AI agents rather than writing every line of code manually.

The numbers are striking:

  • 85% of developers now use AI tools regularly
  • Projects complete 55% faster with AI assistance
  • Y Combinator reported 25% of their Winter 2025 batch had codebases that were 95% AI-generated

This doesn't mean AI does the work for you. It means the bottleneck shifted. The constraint isn't typing speed or syntax knowledge—it's knowing what to build and how to validate it.

The 6-day sprint is designed for this new reality.

Day-by-Day Breakdown

Day 1: Validation and Scope Lock

The first day isn't about coding. It's about making sure I'm building something worth building.

Morning: Validate the Problem

  • Who has this problem? (Specific person, not "users")
  • How are they solving it today? (Competitors, workarounds)
  • Will they pay for a solution? (Or at least use it heavily)

If I can't answer these clearly, I don't start building.

Afternoon: Define the MVP

  • What's the one core feature?
  • What can I cut that seems essential but isn't?
  • What does "done" look like in 5 days?

I write a single sentence describing what I'm building. If it takes more than one sentence, the scope is too big.

Evening: Technical Spike

  • Can I actually build this?
  • What's the riskiest technical assumption?
  • Quick prototype to validate the hardest part

Day 1 ends with a clear, written scope and confidence that the hard parts are solvable.

Days 2-4: Build the Core

This is where AI-assisted development shines. Three days of focused building.

Day 2: Foundation

  • Project setup (I use templates to skip boilerplate)
  • Core data structures and API design
  • Basic UI scaffolding

With Claude Code, I can describe the architecture I want and get a working skeleton in hours. But I review everything—AI code needs human judgment.

# My typical Day 2 flow
1. Create repo from template
2. Define data models with AI assistance
3. Build the happy path end-to-end (no edge cases yet)
4. Test manually, fix obvious breaks

Day 3: Feature Completeness

  • Implement remaining MVP features
  • Connect all the pieces
  • Handle the important edge cases (not all of them)

Day 3 is the longest coding day. I aim to have something that works, even if it's rough.

Day 4: Polish What Matters

  • Fix bugs that would embarrass me
  • Improve UX for the core flow
  • Add error handling for common failures

Polish is infinite. Day 4 polish is bounded: only touch what users will definitely encounter.

Day 5: Distribution Prep

This is the lesson most indie hackers learn the hard way: building without distribution equals zero users.

Morning: Landing Page

  • Clear value proposition
  • Screenshots or demo video
  • Call to action (download, sign up, etc.)

Afternoon: Launch Assets

  • App Store screenshots and description
  • Social media announcement copy
  • One-paragraph pitch for communities (Indie Hackers, relevant subreddits)

I prepare everything I need to tell the world about the product. No "launch later" promises—the assets get created on Day 5.

Day 6: Ship and Decide

Morning: Launch

  • Push to production
  • Publish to App Store / deploy to Vercel
  • Post announcements

Afternoon: Initial Feedback

  • Watch for early user reactions
  • Fix any critical launch bugs
  • Answer questions and comments

Evening: Decide

  • Is this worth another sprint?
  • What's the single most important improvement?
  • Or: kill it and move on

Day 6 ends with a decision. Either I commit to iterating on this product, or I learn from it and start something new.

The Rest Day

Day 7 is off. No coding, no product thinking. This isn't optional.

Solo founders burn out at alarming rates—54% report burnout in the past year. The sustainable pace isn't maximum speed; it's consistent speed with recovery built in.

The rest day also creates psychological distance. Problems that seemed intractable on Day 6 often have obvious solutions on Day 8.

Real Examples

DropVox (Privacy-First Voice Transcription)

Day 1: Validated that I personally needed this daily. Confirmed Whisper could run locally. Scoped to: menu bar app that transcribes dropped audio files.

Days 2-4: Built with Python and rumps. Integrated Whisper. Added progress indicator and copy-to-clipboard.

Day 5: Created landing page, GitHub readme, basic screenshots.

Day 6: Shipped to GitHub. Posted on a few communities. Got immediate positive feedback.

Decision: Iterate. Users wanted batch processing and timestamp support.

Days as Numbers (Life in Days App)

Day 1: Validated with friends who resonated with the concept. Scoped to: single screen showing your age in days.

Days 2-4: Built with React Native and Expo. Onboarding flow, day calculation, milestone detection.

Day 5: App Store assets, screenshots, description. Tested on multiple devices.

Day 6: Submitted to App Store. Soft launch to friends.

Decision: Feature complete for now. Add widget in future sprint.

Tools That Enable This Pace

My standard stack for 6-day sprints:

For Web Apps:

  • Next.js (App Router) — conventions over configuration
  • Tailwind CSS — rapid styling without context switching
  • Supabase — auth, database, and storage in one
  • Vercel — deploy on push

For Mobile Apps:

  • React Native + Expo — JavaScript I already know
  • Expo Router — file-based routing
  • EAS Build — handles App Store complexity

For AI Assistance:

  • Claude Code — architecture discussions, complex implementations
  • Cursor — inline coding with context awareness

For Distribution:

  • Simple landing pages from my own template
  • Umami for analytics (self-hosted, privacy-respecting)
  • Direct App Store submission (no third-party services)

The stack is boring by design. Every unfamiliar tool is friction that slows the sprint.

What This Methodology Doesn't Do

Let me be honest about limitations.

It doesn't guarantee success. Shipping fast reduces the cost of failure—it doesn't prevent failure. Most products don't find product-market fit, no matter how quickly you ship them.

It doesn't work for everything. Some products genuinely need longer timelines. A complex B2B SaaS with integrations can't be built in 6 days. But a surprising amount can be MVP'd in 6 days.

It doesn't replace distribution. You still need users. The 6-day sprint includes distribution prep, but building an audience is a separate, ongoing effort.

The Portfolio Mindset

Daniel Vassallo's "small bets" philosophy has gone mainstream in indie hacker circles. The idea: instead of betting everything on one product, build a portfolio of small products. Some will fail, some will modestly succeed, occasionally one will hit.

The 6-day sprint is the tactical layer for this strategy. Each sprint is a small bet. Ship, learn, decide. Build the portfolio over time.

Marc Louvion (ShipFast creator) reached ~$50k/month revenue by launching dozens of small products. Alex West hit $42k MRR after failing 19 times. The 6-day sprint makes that iteration speed sustainable.

Start Your Own Sprint

If you're sitting on an idea, here's my challenge: give it 6 days.

Not 6 days of research. Not 6 days of planning. Six days of building and shipping.

At the end, you'll have either a launched product or a clear understanding of why it shouldn't be built. Both are valuable. Both beat months of hypothetical planning.

The best time to start a sprint was last week. The second best time is Monday.

Want to follow along as I ship products in public? Check out Helsky Labs for current projects or reach out on GitHub and Twitter/X.