#77: Cost of Over-Engineering & First 1,000 Users
April 13, 2025 – DevTools Brew #77
I’m Morgan Perry, co-founder of Qovery. Every week, I share the real, often uncomfortable lessons from building and scaling devtool startups—from 0 to 1 and beyond.
In today's edition:
The Cost of Over-Engineering
→ What we learned by trying to build the perfect product (too early).
PostHog’s First 1,000 Users
→ The early decisions that mattered most, and the noise they ignored.
Two different stories, same thread: clarity beats complexity.
Let’s dive in.
The Cost of Over-Engineering
What we learned by trying to build the perfect product (too early).
“Building a great product is hard. Building the right product is even harder.”
In the early days of Qovery, we fell into a common founder trap: obsessing over product excellence instead of product relevance.
The idea seemed sound. Build a rock-solid infrastructure platform to handle all use cases - no exceptions.
And so we built… and built.
But deep down, if we’re being honest—if I’m being honest—we weren’t building for our customers. We were most likely building for ourselves.
We prioritized polish over speed, flexibility over clarity. We thought we were future-proofing the platform. But what we were really doing was delaying learning.
We were solving problems no one had voiced. We were anticipating needs instead of responding to them. It felt like progress. But the metrics said otherwise.
The product got more complex. Adoption slowed. Feedback cycles got longer. Our roadmap kept expanding, but our impact didn’t.
And still, we doubled down - thinking one more feature, one more layer, would change everything.
The turning point came when we realized we were spending more time maintaining low-impact features than doubling down on what was actually working.
So we paused.
We froze development on non-essential work. We spent time with users and on usage data - not about what they wanted us to build, but about what they actually needed to do. We asked and saw how our product fit into their workflow. What it replaced. What they used alongside it. And most importantly - what they didn’t understand (or didn’t need).
That process forced a complete mindset shift.
We stopped asking, “Can we build this?” and started asking, “Should we?”
We made a list of features we’d built that had low usage or unclear ROI. One by one, we started pruning. Saying no. Removing things that looked impressive but didn’t deliver.
And something interesting happened: things got simpler. Feedback became clearer. Usage picked up. Time to value dropped. We started moving and learning faster - not by doing more, but by doing less.
What I've learnt? Over-engineering doesn’t just slow us down - it hides the real signals. The more complex your product, the harder it is to understand what actually matters.
I wish we had asked these three questions earlier:
→ Who exactly are we building for?
→ What’s the painful problem they can’t solve today?
→ And what’s getting in the way of delivering that solution as fast and simply as possible?
Every feature is a bet. The more you build, the more bets you place - and the harder it becomes to double down on the ones that matter.
It’s easy to mistake polish for progress. But clarity beats complexity. Every time.
The First 1,000 Users
PostHog’s Early Bet
“We gave ourselves one month to figure it out. If people weren’t desperate enough to try it, we’d drop the idea.”
That was the mindset James Hawkins (CEO of PostHog) and his co-founder Tim adopted when they pivoted - again - for what would become PostHog. Before that, they had built five different products. None had stuck. They couldn’t get ten companies to use them.
This time, they focused on product analytics for developers - an audience most tools ignored. Instead of building for PMs and execs, they optimized for the developer experience: self-hosting, a permissive open-source license, autocapture to avoid manual instrumentation.
But what really stood out was how methodically they validated demand.
They didn’t launch until strangers could use the product, end-to-end, without help. Then they posted on Hacker News. Within days: 300+ deployments. Not from friends, but from people they’d never spoken to.
That gave them confidence. The product wasn’t just useful—it was wanted.
The early GTM playbook? Personal outreach, smart cold messages, and a clear message that resonated with engineers. No monetization yet. Just traction. They poured their energy into onboarding, support, iteration.
Pricing came later—only after they saw consistent usage. And even then, it was structured around conversations. Not guesswork.
Looking back, what helped PostHog reach its first 1,000 users wasn’t growth hacks or paid ads (even though they did spend $2K on Twitter to trend their GitHub). It was clarity.
They knew exactly who they were building for. What pain they were solving. And what made them different.
That’s the real lesson. Getting to 1,000 users isn’t about doing more - it’s about being razor-sharp on the basics:
→ Build for people no one’s serving.
→ Ship something they can use now.
→ Obsess over what keeps them coming back.
→ Price only when they’re ready to pay.
It’s a playbook worth studying - not because it’s perfect, but because it’s focused. And in early stage, focus is the only edge that compounds.
Final thoughts
Early-stage mistakes often come from building too much - or building too soon.
At Qovery, it meant over-engineering before finding the signal.
At PostHog, it meant ignoring everything except signal.
Different paths, same outcome: focus is the fastest way to learn.
And learning fast is the only way to grow.
That’s it for me today! :)
Thanks for reading and Happy Sunday!
— Morgan
Do you like personal lessons like this? More insights/stories from other devtool founders? Let me know, I’m always open to feedback.
You can reach out to me on LinkedIn.