Building a digital product solo in 30 days: an unfiltered retrospective

In short — Building a digital product solo in 30 days is doable, but not for the reasons people think: AI doesn’t replace strategic thinking, it accelerates execution once you know exactly what to build. The real bottleneck isn’t the code — it’s the decision.

Thirty days. One dev. No co-founder, no marketing budget, no meetings. This isn’t a Twitter challenge. It’s the reality of a solo indie studio — and it’s more complicated and more instructive than any 280-character thread can capture.

This retrospective is chronological, quantified where possible, and honest about the moments it nearly went off the rails. If you’re looking for polished inspiration, move on. If you want to understand how a digital product actually gets built solo in the AI era, keep reading.

Week 1: choosing the idea and validating without touching the code

You don’t code in week 1. If you’re coding in week 1, you’ve already lost.

The rule I follow: no line of code until I have at least minimal proof that someone has the problem and is looking for a solution. Not an “interesting idea” — a real, documented friction point.

How I identify the idea

I always start from a pain I’ve personally felt or directly observed in my freelance dev work. Ideas that come from nowhere have an abandonment rate close to 100% — at least on short sprints. When the problem is real to you, you push through the week 3 blockers because you want the solution just as much as your future users do.

In practice: I list the tasks that cost me time or energy in the last 90 days. Not abstract ideas — specific moments where I thought “there should be a tool for this.”

Validating in 5 days with AI

AI comes into play here, but not as a developer. It plays the role of a critical sparring partner.

Days 1–2: define the problem precisely. I describe the problem to a language model and ask it to keep asking me questions until the definition is unambiguous. This exercise takes 1 to 2 hours and consistently reveals blind spots in my initial framing.

Day 3: map the alternatives. I ask the AI to list everything that already exists to solve this problem — tools, manual workarounds, indirect competitors. If nothing exists, that’s not necessarily a good sign: it might mean the market is too small or the problem isn’t painful enough.

Day 4: build a landing page in 4 hours. No custom code. A no-code tool or a template, a one-sentence value proposition, a sign-up form or waitlist. The goal: have a URL to share.

Day 5: manual distribution. I share the landing in 2 or 3 communities where the problem is being discussed. No spam — a reply to an existing thread, a post that adds value before mentioning the tool. I measure clicks, sign-ups, and direct replies.

The threshold I set for myself: if nobody clicks or signs up within 48 hours of honest distribution, the problem isn’t painful enough. I pivot or abandon — and that’s a win, not a failure. I’ve just avoided 3 weeks of development on something nobody wanted.

Weeks 2–3: building the MVP with AI as co-developer

Validation done, the development sprint begins. Two weeks, not three. If the MVP takes more than 14 days of coding, the scope is too wide.

The 3-feature rule

A solo MVP in 30 days has exactly 3 features. Not 5, not 7. Three. The one without which the product doesn’t exist, the one that makes the experience acceptable, and the one that makes people want to come back.

Everything else goes into a backlog.md file I don’t open during the sprint. This discipline is the hardest to maintain — and the most important.

How AI concretely accelerates development

I’ll be specific, because “AI helps me code” means nothing without examples.

What AI does well in a solo sprint:

Generating boilerplate — authentication, role management, transactional emails, third-party API connections. These are tasks that used to take a full day and now fall to 2–3 hours with a good prompt and a serious review of the generated code.
Unblocking technical dead ends — when I’ve been stuck on a bug for more than 30 minutes, I describe the context to the AI. It suggests 3 to 5 leads. One in five is directly usable, the others steer my thinking. It’s faster than Stack Overflow in 70% of cases.
Writing unit tests — I describe the expected behaviour, the AI generates the tests. I review and correct them. It takes 20 minutes instead of 90.
Writing internal documentation — README, comments for complex functions, API documentation. Delegating this to AI saves me 1 to 2 hours per week without sacrificing quality.

What AI doesn’t do well:

Architecture decisions. When I ask “how should I structure my database for this use case,” it gives me a generically correct answer that isn’t adapted to my actual constraints (budget, expected volume, existing stack). That’s my call.
Consistency across sessions. AI doesn’t remember yesterday’s context. I maintain a context.md file that I paste at the start of each session to avoid re-explaining everything.
Detecting subtle security vulnerabilities. I review all authentication and payment-related code myself, line by line.

The real rhythm of weeks 2–3

No 14-hour days. Focused 4 to 6-hour development blocks, mornings preferred. Evenings: review the code produced during the day, update backlog.md, note blockers for tomorrow.

By week 3, decision fatigue starts to kick in. That’s where the context file and the 3-feature rule do their job: they eliminate decisions that need to be made and keep things on track. AI carries the cognitive load of repetitive tasks — I save my attention for the decisions that matter.

End of week 3: a working product, deployed on a real domain, accessible to the people who signed up in week 1. Not pretty, not complete, but functional.

Week 4: launch, distribute, measure — the real results

Week 4 is not a development week. It’s a distribution week. If you’re still coding in week 4, you’re postponing the moment of truth.

What “launching” actually means solo

A solo launch isn’t a Product Hunt launch with 500 upvotes on day one. It’s a gradual rollout, channel by channel, with measurement at each step.

Days 22–23: activating week 1 sign-ups. The people who left their email get access. Not a marketing email — a personal message (or near-personal with light personalisation) explaining what they’ll find and asking for direct feedback. The response rate on this type of message exceeds 30% when the list is small and qualified.

Days 24–25: one detailed post on one channel. Not a generic Twitter/X thread. A post that tells the story of the problem, the solution, and the early feedback — with real numbers. Maker and indie hacker communities respond well to this format, as long as it’s honest and not promotional.

Days 26–28: measure and iterate fast. I look at three metrics only: the number of active users (who completed the core action at least once), the D+3 retention rate (do they come back?), and direct qualitative feedback (what’s blocking them?).

Days 29–30: decision. Continue, pivot, or stop. This decision is made on data, not emotion.

The real results of a 30-day sprint

I’ll be honest about what you can reasonably expect:

A working product, deployed, with real users: yes, that’s achievable.
Significant recurring revenue after 30 days: no, except in rare cases. Distribution takes time. First revenue typically comes between day 30 and day 90, if the initial validation was solid.
A perfect product: never. And that’s the point. An imperfect product being used is worth infinitely more than a perfect product that doesn’t exist yet.

What the 30-day sprint actually produces is a real feedback loop. You know whether you’re solving a real problem. You have data to decide what to build next. That’s the value — not month 1 revenue.

For a deeper look at the numbers around the solopreneur economy and what AI concretely changes in the equation, I’ve compiled solid sources in our solopreneur & AI 2026 statistics report.

What I’d do differently — and the central lesson

After several cycles of this kind of sprint, here are the mistakes I make less often — and the ones I consistently see other makers repeat.

Recurring mistakes

Starting to code too early. This is mistake number one. Code gives the feeling of progress. Validation gives real information. They’re not the same thing.

Underestimating distribution. A product without distribution doesn’t exist. Solo, you have no marketing team — so either you build an audience before launching, or you rely on existing communities. There’s no third option. If distribution is something you want to dig into, the site audit can surface visibility issues you hadn’t spotted.

Trying to validate multiple ideas in parallel. In a 30-day solo sprint, one idea at a time. Spreading yourself kills short sprints.

Ignoring decision fatigue. After 15 days of intensive development, decision quality drops. Putting systems in place (3-feature rule, context file, closed backlog) isn’t about organisation — it’s about cognitive survival.

The central lesson

The cost of building a digital product has collapsed. AI made that real, not just theoretical. A solo dev in 2026 ships what a small team shipped in 2019, on certain dimensions.

But the cost of deciding what to build and for whom hasn’t dropped a cent. That’s where everything is decided. AI can generate code, write emails, unblock bugs — it can’t decide whether your idea is worth building. That’s your job.

The 30-day sprint is a decision-making tool disguised as a development tool. Its real purpose: forcing you to confront your idea with reality before investing months in it.

If you’re stuck on a technical issue during a sprint like this — a stubborn bug, an integration that won’t cooperate — Unstuck exists for exactly that: fast technical unblocking, no long-term commitment.

Thirty days is short. Short enough to maintain momentum, long enough to get a real feedback loop. It’s the format that fits the reality of a solo studio best: no infinite runway, no team to absorb mistakes, but the ability to ship and learn fast that heavier structures simply don’t have.

Ship · Earn · Keep.

Sébastien de Bollivier has been a freelance dev since 2008 and builds products solo from La Réunion. If you’re looking for a dev to accelerate a project or validate an architecture, his profile is at sebastiendebollivier.com.

Frequently asked questions

Is it really possible to build a digital product solo in 30 days?

Yes, as long as you define a very strict MVP scope (3 features max) and validate the idea before writing a single line of code. AI reduces development time by 40 to 60% on repetitive tasks, but the decision of what to build remains entirely human.

What tech stack should you choose to move fast alone?

Stick with a stack you already know 80% of. Switching languages or frameworks mid 30-day sprint is the surest way to never finish. AI can cover the remaining 20% — it can't rescue a poor stack choice.

How do you distribute a solo product without an existing audience?

Start with a single channel: a targeted community (Discord, forum, subreddit) where your problem is already being discussed. Trying to hit multiple channels in week 4 of a solo sprint means spreading yourself too thin. One channel worked well beats five channels barely touched.

Got an idea to ship? A website, a SaaS, an AI automation — built with you.

Talk about your project