I used to think building the product was the hard part.
I'm a software engineer. Give me a spec and I'll build it. So I assumed that once the product existed, the rest would follow.
After building HairOver, I realized I had underestimated almost everything that comes after the build. Or, as I put it in my notes for the launch: building is easy compared with earning attention, and earning attention is easy compared with earning trust.
What this means
Entrepreneurship, at its simplest, is turning an uncertain idea into something people will pay for, and learning your way there.
The important word is uncertain. When you start, you don't know if the problem is real, if your solution works, if anyone will find it, or if they'll pay. Most of the work is reducing that uncertainty, one question at a time.
That changes what matters:
Ideas are cheap. Not worthless, just cheap. Lots of people have had the idea for an AI hairstyle app. You can see that by searching the Play Store. The idea by itself doesn't separate you from anyone.
Execution is where the information is. You learn things from building and shipping that you can't get from thinking. What confuses people, what they ignore, what they'd pay for. You can't reason your way to those answers from your desk.
Having an idea and building a business are different jobs. An idea is a guess. A business is a guess that has survived contact with real people, and kept surviving, and pays for itself.
What I learned
Before HairOver, most of my work was for other people. I founded a small software company, Yaks Inc., and ran it for about a year, doing consulting and building products for clients. I also did freelance engineering for US-based clients, including a React Native app and an e-commerce site.
Client work trains a specific question into you: does it work?
The client has already decided the thing is worth building. Your job is to build it well, on time. If it works, you've succeeded.
When I started HairOver, the question changed to: would anyone actually care?
That's a much harder question, and nobody answers it for you. There's no spec, no client sign-off. The only way to find out is to put something in front of people and watch what happens.
It took me a while to really understand that. My engineering instincts kept pulling me toward making things better, when what I needed was to find out if they were wanted.
Real example
Two things from HairOver show both sides of this.
The first version shipped with a lot. By late July 2026, the app, still called Stylora then, had face analysis, a ranked style report with match scores, detailed style pages, try-on on your own photo, a style studio for cuts and colors, a 100+ style library, filters, a home screen, and a separate hair analysis. I wrote a full walkthrough of that version.
Looking back, that's a lot of surface area for a first version. It also means I now have to figure out which of those screens actually matter to people, and that takes real usage data.
Then I rebuilt the landing page about four times before it had real traffic. The website's git history makes this hard to deny: a full landing page on August 24, a revamp on August 30, another on September 1, and the hero rebuilt again on September 7. The full history is here.
Each rebuild felt productive. And to be fair, some of them improved things. But none of them was tested against a real visitor. I was polishing based on my own opinion, which is exactly the thing that doesn't reduce uncertainty.
That's the pattern I try to catch now. Work that feels like progress isn't always progress. Progress is learning something you didn't know yesterday.
Speed vs perfection
"Move fast" gets repeated so much that it sounds like a slogan. Here's what I think it actually means.
Speed isn't about writing sloppy code or skipping care. It's about shortening the time between making a guess and finding out if it was right.
A perfect version you ship in three months gives you one round of feedback in three months. A decent version you ship now gives you feedback now, and you get to improve the next version with real information instead of guesses.
Perfection feels safe because it delays the moment you find out. That's also why it's expensive.
Shipping creates information. Waiting creates opinions.
Thinking in experiments
The most useful habit I've picked up is to treat decisions as experiments instead of bets.
An experiment has three parts:
- What I believe. "People will pay more readily for a subscription than for one-off credit packs."
- What I'll change to test it. Add a subscription option.
- What would change my mind. If conversion doesn't move after enough people have seen the paywall, I was wrong.
Writing the third part down before the result is the important bit. Without it, you'll read whatever happens as support for what you already believed.
I've started publishing plans before their results for this reason. My 30-day X distribution plan went up before I knew if it worked. That makes it harder to quietly rewrite the plan later so it looks like I predicted the outcome.
Uncertainty is normal
When you're early, it's easy to assume everyone else knows something you don't. Usually they don't. Nobody knows whether their pricing will work until they test it. The founders who look certain on social media mostly just aren't posting their uncertainty.
What helped was separating two kinds of not knowing:
- Things I can find out quickly. What a generated image costs, whether the app store takes a cut, which screen people drop off on. I should find these out now.
- Things only time will answer. Whether people come back next month, whether word of mouth kicks in. For these, I set up the measurement and wait.
The first kind is where I've been sloppy before. My original pricing model left out the app store commission entirely, a number I could have looked up in five minutes. (That whole story is here.)
What to do
- Write down the single biggest uncertainty in your idea. Not ten, one. Usually it's "will anyone want this?"
- Find the fastest way to get real information about it. A conversation, a landing page, a rough version. Whatever gets a real reaction soonest.
- Before you build anything, write down what result would change your mind.
- Keep a list of "work that felt like progress." Look at it every week. Ask which items actually taught you something.
- Ship something small to real people this month, even if it embarrasses you a little.
Mistakes to avoid
Treating polish as progress. A fourth landing page redesign isn't learning unless someone new sees it.
Protecting the idea instead of testing it. If you avoid showing it to people because they might not like it, you're choosing comfort over information.
Waiting until you're certain. You won't be. Certainty comes after the experiment, not before.
Skipping the cheap facts. Some uncertainty takes months to resolve. A lot of it takes an afternoon of research. Do the afternoon.
My current thinking
I'm better at this than I was, but I still catch myself doing it wrong.
The pull to polish is strong when you're an engineer, because polishing is something you know how to do well. Talking to strangers, putting out something rough, and hearing that it's not good enough are all less comfortable.
What I'm trying to get better at with HairOver right now is the gap between built and learned. A lot is built. What I don't have yet are clear answers to the basic questions: do people who upload a photo get to a look they care about, do they come back, and will they pay? That's where my attention is going.
Key takeaway
You don't need to know everything before you start. You need a way to learn quickly. Treat your idea as a set of guesses, test the biggest one first, decide in advance what would prove you wrong, and don't mistake polish for progress.
Next: Finding a Real Problem. Before you test anything, you need a problem worth testing.