Everyone talks about "building products." Few people talk about the specific chaos of going from zero to one — from nothing to a thing that works, that people use, that you can charge money for.

I'm Leander, co-founder of diepen.io. We're a product studio in Düsseldorf, Germany, and 0-to-1 is literally all we do. Here's what we've learned.

0-to-1 is a different sport

Building a new product from scratch is fundamentally different from adding features to an existing one. The difference isn't just scope — it's the type of decisions you make.

In an existing product, you have:

An architecture to build on
Users who tell you what's broken
Revenue that validates you're on the right track
A team that knows the codebase

In a 0-to-1 product, you have:

Assumptions
A budget that's smaller than you'd like
A deadline that's sooner than you'd like
No users, no revenue, no validation

That changes everything about how you should work.

The actual process (not the blog post version)

Most "how to build a product" articles give you neat phases. Reality is messier, but there is a structure that works:

Week 1–2: Problem validation

Not "market research." Not surveys. Actual conversations with potential users.

What you're trying to learn:

Do people have the problem you think they have?
How are they solving it today? (There's always a current solution, even if it's "we just deal with it")
Would they pay to solve it? How much?

What you should produce:

5–10 user interview notes
A one-paragraph problem statement
A list of "must-have" vs. "nice-to-have" features (be ruthless here)

Common mistake: Skipping this because "we already know the market." You don't. We built Rezeptiona, our AI phone assistant for tradespeople, because we talked to SHK business owners who told us their actual problem wasn't "I need AI" — it was "I miss 30% of my calls because I'm in a basement fixing pipes." That reframe changed the entire product.

Week 2–3: Design + architecture

Simultaneously, not sequentially. Your designer and developer should be in the same room (or call).

Design:

Core user flow (the one thing your product does)
3–5 key screens, not 30
Mobile-first if your users are mobile (ours are literally on construction sites)

Architecture:

Pick a stack you can ship fast with, not the one that "scales to 10M users"
For most products in 2026: Next.js + Supabase/Postgres + Vercel is hard to beat
Don't build auth, don't build payments, don't build email — use services

Common mistake: Over-architecting for scale you don't have. Your V1 doesn't need microservices. It needs to work.

Week 3–6: Build

This is where most teams lose time. Here's how to stay fast:

Ship vertically, not horizontally. Don't build all the backend, then all the frontend, then connect them. Build one complete feature at a time — database to UI. Feature #1 works end-to-end before you start feature #2.

Cut scope daily. Every morning, ask: "Is this feature necessary for the first 10 users?" If not, cut it. You can add it in V1.1.

Deploy from day one. Continuous deployment to a staging environment. Your stakeholders should be able to see progress every day, not every sprint.

Design in the browser. After the initial mockups, design decisions happen in code. Pixel-perfect Figma files for a product nobody's used yet are a waste of time.

Week 6–8: Launch + learn

"Launch" for a V1 product means:

5–20 real users (not friends, not investors — actual target users)
A way to collect feedback (we use a simple feedback widget + WhatsApp group)
Analytics on the one metric that matters (for Rezeptiona: calls successfully handled)

What you're NOT doing yet:

Marketing campaigns
PR
Scaling infrastructure
Building the mobile app

Common mistake: Waiting for "ready." Your V1 will have bugs. Your UX will be rough. That's fine. The goal is learning, not perfection.

What it costs

Real numbers from products we've built:

| Product type | Timeline | Investment | Examples | |-------------|----------|------------|----------| | Simple SaaS (CRUD + auth + payments) | 4–6 weeks | €15K–35K | Booking tools, dashboards, internal tools | | AI-powered product | 6–10 weeks | €30K–70K | Chatbots with real logic, document processing, voice AI | | Platform / marketplace | 8–14 weeks | €50K–120K | Multi-sided platforms, complex user roles |

These are realistic ranges for a senior 2–3 person team. You can spend less (solo developer, longer timeline) or more (larger team, more polish). But this is the sweet spot for "good enough to validate, professional enough to charge for."

The 5 mistakes that kill 0-to-1 projects

1. Building for investors instead of users

Your V1 should impress customers, not pitch decks. If your roadmap is driven by "what will look good in a fundraise," you're building the wrong product.

2. Hiring too early

Don't hire a full team before product-market fit. A founder + a small external team (like us) can move faster and cheaper than 5 full-time employees who need onboarding, equipment, and management.

3. Choosing tech for the resume

"We chose Kubernetes because..." — no. You chose it because it sounded impressive. For a V1 product, a simple PaaS deployment (Vercel, Railway, Render) is enough. You can always migrate later.

4. Skipping design

Engineers love building features. Users love using products that feel good. These are not the same thing. Even for a V1, invest in basic UX. It doesn't need to be beautiful — it needs to be usable.

5. Not defining "done"

Before you start building, agree on what V1 looks like. Write it down. "The product is V1 when a user can [do the core thing] without help." Everything else is V1.1.

When to build in-house vs. with a studio

Build in-house when:

You have a technical co-founder who can lead development
You've already validated the idea and need to scale the team
The product IS the company (you'll be iterating on it for years)

Work with a studio when:

You need to go from idea to product fast (weeks, not months)
You don't have a technical co-founder (yet)
You want to validate before committing to a full team
You need senior expertise without senior salaries

At diepen.io, many of our clients eventually build their own team — and that's great. Our job is to get you to the point where that hire makes sense, with a working product and real users to show for it.

What happens after V1

V1 is not the end. It's the beginning of a much longer process:

Weeks 1–4 post-launch: Listen. Don't build new features. Fix what's broken, learn what's missing.
Month 2–3: Build the 2–3 features users actually asked for (not the 20 you imagined).
Month 3–6: Start thinking about growth, marketing, and team building.

The biggest risk after V1 isn't failure — it's premature optimization. Don't scale what hasn't been validated.

Ready to build?

If you have a product idea and want to go from zero to one, let's talk. A 30-minute intro call costs nothing and will give you clarity on scope, timeline, and budget.

Book an intro call →

No decks, no proposals, no NDAs required. Just an honest conversation about what you're building and whether we're the right team to help.