Building a product from scratch is different from everything else in software. Here's what we've learned shipping 0-to-1 products — the real process, real costs, and real mistakes.
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.
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:
In a 0-to-1 product, you have:
That changes everything about how you should work.
Most "how to build a product" articles give you neat phases. Reality is messier, but there is a structure that works:
Not "market research." Not surveys. Actual conversations with potential users.
What you're trying to learn:
What you should produce:
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.
Simultaneously, not sequentially. Your designer and developer should be in the same room (or call).
Design:
Architecture:
Common mistake: Over-architecting for scale you don't have. Your V1 doesn't need microservices. It needs to work.
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.
"Launch" for a V1 product means:
What you're NOT doing yet:
Common mistake: Waiting for "ready." Your V1 will have bugs. Your UX will be rough. That's fine. The goal is learning, not perfection.
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."
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.
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.
"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.
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.
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.
Build in-house when:
Work with a studio when:
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.
V1 is not the end. It's the beginning of a much longer process:
The biggest risk after V1 isn't failure — it's premature optimization. Don't scale what hasn't been validated.
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.
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.