Things I Wish I Knew Before Building My Product

When I started building my product, I was full of excitement, energy—and assumptions.

Looking back, I realize I could’ve saved myself months of time and a lot of unnecessary complexity if I had just done a few things differently. So I’m writing this in the hope that it helps someone else who’s building something new.

Here are the top mistakes I made—and what I’d do differently today:

Mistake #1: Overengineering the First Version

As an engineer, I had this itch to build everything right from day one. Clean architecture, best practices, scalable for millions of users—even though we barely had ten. I was thinking about edge cases, performance, reliability… all before figuring out if people actually wanted what we were building.

Looking back, I realize I was designing a skyscraper before even laying the foundation.

💡 What I’d Do Differently:

• Start scrappy. Make the MVP intentionally small and simple—just enough to validate with early users.

• Use low-code or no-code when possible. Speed matters more than perfect code.

• Leverage existing SaaS tools for common things like authentication, email, and payments.

• Minimize components—less moving parts means fewer things breaking.

• Use micro backends and DB-as-a-service to avoid infrastructure overhead.

• Skip full CICD initially. Basic version control and manual deploys are usually enough for the first few weeks/months.

You’ll end up rewriting anyway. But you’ll rewrite with clarity, feedback, and real usage in mind—which is way better than premature optimization.

Mistake #2: Not Writing Down the Idea Clearly

I had the idea in my head. I spoke to friends about it, pitched it in conversations, and even started building it. But every time I described it, it sounded a little different. Why? Because I hadn’t taken the time to write it down clearly. And if you can’t write it in a sentence, you probably don’t understand it well enough.

💡 What I’d Do Differently:

Start by writing the idea in one clear sentence. If you can make it shorter, even better. Then expand that into a one-pager answering key questions:

1. What problem am I solving, and is it already being solved by others?
   Understand the existing solutions and identify your unique edge.

2. Why do I want to build this?
   Clarify your motivation—whether it’s passion, market gap, or a personal itch.

3. Who exactly are my users?
   Be specific. Narrow down to personas or segments instead of vague demographics.

4. How are people currently addressing this problem?
   Study current workarounds, tools, or behaviors to validate the need.

5. What’s my business model?
   Think about how this can sustain itself—free, freemium, B2B, subscriptions, etc.

Clarity isn’t just for pitching—it's the foundation for building, getting feedback, and keeping your team aligned.

Mistake #3: Building Based on Assumptions

Once a few people told me the idea was great, I was off to the races. I started building with confidence—without any real validation. Looking back, I now know I was mostly hearing what I wanted to hear.

It’s easy to fall into the trap of early compliments and friendly encouragement. But those aren't proof that people need—or will use—what you're building.

💡 What I’d Do Differently:

• Find where your users hang out. Whether it’s Reddit, LinkedIn, Discord, Twitter—your early users are somewhere. Go there.

• Run a short questionnaire or poll to collect early signals about the problem.

• Talk to strangers, not just friends. Your friends will often support you no matter what—and they may not be the target users.

• Look at your competitors. What are people saying in their reviews? Support forums? Communities? Those are real pain points you can learn from.

Assumptions are expensive. It’s better to “waste time” validating than to waste months building something no one needs.

Mistake #4: Building All the Features

I thought having more features would make my product more appealing. That it would attract more users, cover more use cases, and justify a higher price. In reality, it just made things more complicated, delayed launch, and confused users.

A bloated MVP is no longer an MVP—it’s just a product that hasn’t been validated.

💡 What I’d Do Differently:

• Start with the one core feature that truly solves the user’s main problem.

• Avoid unnecessary integrations. Focus only on the ones your early target users need right now.

• Define your user persona very clearly—then narrow it down even more.

• Ship early, even if it feels bare. Let users tell you what’s missing.

• Skip pricing at first. Let users experience the product, then ask them what it’s worth. Real feedback is better than guesses.

More features don’t mean more users. Solving one problem really well gets you your first ten real users—and they’ll guide you to the next ten.

Mistake #5: Spending Too Much Time on Branding, Design, and Website Polish (Too Early)

I wanted my product to feel unique—stand out with a distinctive brand, beautiful color palette, and a perfect website. So I spent weeks crafting it all. The problem? None of that mattered when the product wasn’t yet validated.

In the MVP stage, your focus should be speed and simplicity. If your product actually solves a real problem, users will use it—regardless of the logo or pixel-perfect UI. Ironically, I rebranded my product twice after launch, realizing all that early time spent on branding was premature.

💡 What I’d Do Differently:

• Use familiar UX patterns: Don’t reinvent the wheel. Design your MVP like the tools your users already love—it lowers the learning curve.

• Focus on the core feature: Strip everything else out. Let users experience the one thing your product does best.

• Keep the website dead simple: One homepage that explains what it does in 10 seconds is enough.

• Leverage UI frameworks: Use existing systems like Tailwind or component libraries to build faster and stay consistent.

• Think like a developer: Design for ease of development. A beautiful design that’s hard to implement will slow you down—make it easy to ship.

Wrapping Up

These were some of the biggest mistakes I made while building my first product—from overengineering to unclear ideas, building on assumptions, and trying to do too much too soon. The good news? Every mistake came with a lesson, and those lessons are shaping how I build today.

In the upcoming newsletter, I’ll go deeper into:

• How to deploy your MVP efficiently

• Quick ways to prototype (even without code)

• Tactics to reach your early users

• How to create and run user surveys that actually work

If you're building something, or planning to, stay tuned. I’ll be sharing practical steps that’ll save you time, energy, and maybe a few gray hairs.