Zero to 0.5: The Hardest Part of Building Anything
If you’ve worked in tech or games over the past 10 years, you’ve probably heard someone drop the phrase “Zero to One” — yeah, that one, from Peter Thiel’s book. I’ve always felt like there’s a big missing piece in that framework.
See, most of that book is about what it takes to launch a product or company — and don’t get me wrong, that’s cool and helpful and very Silicon Valley. But for people like me, who start lots of projects from literally nothing, the hardest part isn’t launch. It’s getting from idea soup to something real enough to work with. I call this phase Zero to 0.5. Halfway to somewhere.
As a PM, I usually get pulled in right between 0.5 and 1. Some founder or CEO has focused on the 0-0.5 phase, doing the early product stuff themselves, and then realizes, “Wait, we need someone to actually make this happen.” That’s usually when I show up.
So this post is for anyone stuck in that weird, messy, early phase. Not idea stage. Not MVP. That weird space in between where everything is vague. Here's what I want to cover:
Why this stage is where most things die.
What the common traps are.
How to actually build momentum — especially with no money, no team, and a lot of uncertainty.
I’ll use Side Quest Games as the example, since that’s what I’ve been building lately — and it's 100% a “zero to 0.5” project in the wild.
Ok, You’ve Got an Idea. Now What?
Let’s say you’ve got an idea. You’re probably not technical (I’m not). Or maybe you are technical, but you don’t want to do all the work alone. So… what do you do?
This is where most ideas go to die.
I’ve heard thousands of ideas. Literally. They’re fun to talk about. People love them at parties or over drinks. But the second you try to actually make something? Game over. First wave of excuses:
“It’s not the right time.”
“I can’t code.”
My own personal favorites:
“The market’s too small.”
“There are too many edge cases.”
“This would be hard to launch logistically because XYZ.”
All legit! But here’s the real danger: stopping.
I told myself this early on and I still repeat it all the time:
If you stop, it means you quit. If you keep going, it just means you're figuring stuff out.
So write down the problems. Call out the flaws. But don’t stop. That's it. That's the trick.
You can even make it a little PM exercise: write up the risks, rank them, and make a plan. Or better yet, ask yourself: Which of these risks actually matter this week? Not in a year. Not in six months. This week. That’ll help you stop obsessing over future hypotheticals and start actually moving.
Let Me Back Up: What Is Side Quest Games?
Before we go too deep, let me tell you how Side Quest Games started. It’ll explain a lot of the random pain points I’ll mention later.
So, I’ve been in games for 15 years. I’ve shipped a bunch of stuff. But I’ve never made a game of my own. And I had this moment with my mentor years ago where I said, “I want to run my own studio someday.” And then I just… never did. Life, work, all that.
So I finally said screw it and posted on LinkedIn:
“Does anyone want to make a game with me?”
And to my surprise — a ton of people said yes. I ended up with ~20 people, all early-career folks or folks between jobs. I told them up front: there’s no funding, we’re doing this for fun and exposure, maybe a portfolio piece, and if we ever launch something, we’ll just split revenue evenly.
I interviewed everyone, spun up a Discord, and we kicked things off with a hangouts call. Most people were in other states. It was scrappy. We treated it like a game jam — 2 to 3 weeks to make something small. Everyone contributed to the idea and development. Super flat structure, super experimental.
Of course, that’s why all the messy team/org stuff popped up later.
Here’s a rare photo of me and some of the team in the wild. I can’t tell you how important it is to actually spend time with your team in person. This was one of the most valuable conversations we had.
The Volunteer Team Lifecycle (aka Why Everything Falls Apart)
Here’s how these projects usually go:
Excitement Phase — Everyone's stoked. Ideas are flying.
Reality Check Phase — Oh wait. This is… a lot of work.
Pain Cave Phase — This is really hard. People start ghosting.
Survivors Phase — If you’ve still got a team, congrats — you’ve found your core crew.
We started with 20. We’re down to 7. All awesome, talented people. All still juggling interviews and freelance gigs. Because again — this is a side quest.
Scheduling gets tricky fast. The best thing I’ve learned? Plan around the side quest nature. Make your cadence fit people’s real lives, not the fantasy of a full-time startup.
The Messy Middle: Team, Tools, and Tech
So once you’ve got the idea, the rough team, and some energy, the “business stuff” starts creeping in:
Who owns the IP?
Are we an LLC? A studio?
What tools are we using?
Who’s doing what?
I didn’t want to deal with it. Legal docs feel like bad vibes when you’re just trying to have fun. But eventually, we hit a wall. So here’s what we did:
Made a game jam agreement + commercialization doc (via SignNow)
Formed an LLC
Picked tools: Discord (chat), Linear (tasks), Miro (planning), Fellow (notes), Google Hangouts (calls)
Loosely defined roles and promoted some leads
Not perfect, but enough to keep moving.
The Tech Trap: Unreal vs Unity vs Whatever
We lost so much time talking about engines. Unreal has this, Unity does that, what about Godot?
Here’s my advice: don’t debate tech unless you absolutely have to. Let your most senior technical person decide. If they’re cool with the group picking, cool. But someone needs to make the call.
Ask questions like:
Can we decide this later?
Will this affect the prototype?
What’s fastest to build with based on our team’s skills?
The answer, for us, was Unity. Done (we later revisited this hence why I advise not derailing or switching).
Building Without Devs (Yet)
Our dev needed time. So we didn’t wait. We started prototyping with no-code and low-code tools:
Paper prototyping — Like, actual Post-its and board game pieces.
Tabletop Simulator — Digital board game sandbox.
Figma — For UX and flow.
Unreal blueprints — Quick and dirty logic.
The goal here was to find the fun before we wrote a line of real code. This saved us weeks — maybe months.
Pro tip: don’t waste your dev team’s time. Test ideas as scrappily as possible. Give them clarity, not complexity.
Regular Builds or Bust
Eventually, we got builds out. But they were slow. Unreal was a beast to set up, GitHub was a pain, and we over-scoped the first version.
So we fell back to prototyping while dev caught up. We ran a few playtests with our sandbox tabletop game, kept it lightweight, and kept iterating.
Meanwhile, our art team shrank, so we used placeholder assets and leaned on designers with some visual chops to fill the gap. Not ideal, but it worked.
Common Pitfalls From 0 to 0.5
Let’s just bullet these out:
Don’t depend 100% on dev — prototype in parallel.
Don’t expect polished art — use placeholders or rough sketches.
Don’t spend weeks debating engines — timebox the decision.
Don’t skip playtesting — get something testable ASAP.
Don’t assume people have time — plan around real life.
Wrapping It Up (For Now)
Once you’ve got something playable, tested, and getting actual feedback — you’re past 0.5.
From here, you’re into the territory that Zero to One and Hooked talk about: product-market fit, growth loops, go-to-market, and monetization. That stuff is important — and I’ll write more about it later — but honestly? Getting to this point is the real grind.
So if you’re in the trenches, wondering if your idea is worth it — just keep going. Keep moving. Keep testing. Even if it’s ugly, even if it’s slow.
That’s Zero to 0.5. That’s the hard part. And if you’ve made it this far — you’re already doing better than most. And if you are in my team and you’ve made it this far, big shoutout to all the folks who hung in there. This is the most difficult hurtle to get over imho and it shows that you all have patience, fortitude, and determination to build something for yourself.
More to come soon.
