From Vision to Product Definition — how we decided what to build | by Suntouched | Sep, 2025

After the Waitlist Flop

When our waitlist experiment crashed and burned, it was still weighing heavily on my mind.

For me, thinking, designing, building software is pure joy. I could have opened an IDE that very night and started coding.

But I knew better. If things were going to work, I had to resist that temptation and step back. First, we needed clarity: What are we actually building?

So, we split responsibilities. Louis (our CEO) and Sinbad focused on the dream. I focused on dreamforging — hammering that dream into a blueprint we could actually build.

The Mission and Vision

What followed was a month of endless discussions and sleepless nights.

I still remember waking up at 3 a.m., checking Discord messages, then staring out over the city from my balcony. Thinking. Sometimes I drifted back to sleep. Most times I didn’t.

The first thing that crystallized for Louis and Sinbad — which I immediately embraced — was our mission:

Help small business owners.
People running their business alone or with a tiny team. The ones who usually need the most help but get the least.

That mission led naturally into our vision: to build a tool so reliable and powerful that it could give people their time back. Something so trustworthy it might even embolden someone to finally start their own gig — because they’d know someone had their back.

But a mission and a vision weren’t enough. We needed something more tangible — a name to rally around. And that turned out to be its own battle.

Naming the product

Finding a name in this day and age is like losing your engagement ring in the Sahara — and then having to look for it in 50 km/h winds, while being chased by starving lions.

If we had a penny for every failed attempt, we could have self-funded our Series A.

Naming is notoriously hard in computer science too, though at least there you sometimes get a hint of logic. My favorite example: I once saw a variable called woof. What did it stand for? Width of operating field. Obvious, right?

We set a few ground rules to keep ourselves sane, but most of the process was endless back-and-forth. Every suggestion was subjective, every debate heated. What makes one name better than another? Nobody could ever agree.

And then, in the depths of collective despair, one name clicked instantly: ClientHero.

We weren’t building “just another CRM.” We were building something that could actually be a hero for small businesses — helping them win back time, focus, and confidence.

That name has carried us ever since. Even now, it feels like wind in our sails as we continue navigating some very stormy seas.

Mandatory Foundations

Now it was my turn to forge.
I drew a vertical line on a whiteboard with two columns:

• Mandatory
• Product Features

The mandatory side wasn’t glamorous, but it was critical.

Take passwords, for example. Of course, it’s a good idea to block “password123.” But some systems go overboard. I once saw requirements like:

• 8–30 characters
• One uppercase, one lowercase, one number, one special character
• No use of your name
• a haiku
• your favorite Greek letter

Who wants to sign up for that? Nobody.

So our must-haves were obvious, but we kept them sane:

• Accounts
• Login & password recovery
• Security basics
• Access controls

Nobody will ever thank you for having password recovery that just works. But the day it doesn’t work? That’s all they’ll remember.

Trust is hard to gain, easy to lose. If we fumbled security or account reliability, nothing else would matter. So here we innovated as little as possible — we stuck to industry best practices, no shortcuts.

Product Features: The Wishlist

On the other side of the board was the fun part: the wishlist of product features.

We ran a little experiment. Each of us got the same “budget” of imaginary points to “spend” on features. A day later, we compared results.

• Some features had all three of us buying in.
• Most had only one.

What stood out wasn’t just the overlap, but the lack of it. It forced us to focus.

The features with full buy-in became our MVP foundation:

• Services → Define and price what your company offers.
• Clients → Track recurring and new customers easily.
• Documents → Store bills, receipts, x-rays, whatever ties to a client.
• Smart Appointments → Schedule meetings with automatic reminders, confirmations, and cancellations.

These weren’t glamorous moonshots — they were painkillers. Exactly the kind of things our early users needed most.

The Debates We Had

Reading this far, you might think it was mostly smooth sailing. Nothing could be further from the truth.

Do you know what happens when three people with completely different backgrounds care deeply about the same product? They agree on absolutely nothing. That was us.

We could agree on which features to build, but when it came to defining how those features should actually work — chaos. Louis and I fought constantly over the details.

I don’t have formal product design training, but I’ve spent my career living inside software tools. I recognize patterns — and more importantly, anti-patterns — when I see them. To me, some of Louis’s suggestions looked like landmines.

But Louis had his own ammo: research. He’d spent weeks diving into our target market, interviewing potential users, and mapping needs. So while I’d throw out “That’s an anti-pattern,” he’d fire back, “This is what our users are telling us.” I remember snapping, “From a sample size of two?” He wasn’t being arrogant, though. He had done the homework, and that carried weight.

Looking back, I probably dismissed some of Louis’s points too quickly. It wasn’t arrogance — it was me clinging too tightly to patterns I trusted, instead of listening with fresh ears.

Sinbad? He usually ended up in the middle — balancing my obsession with clean design against Louis’s user-first instincts, while adding his own left-field ideas to the mix.

The truth is, these debates nearly drained us. At times it felt like we were spinning in circles. But in hindsight, they were necessary. They forced us to hammer vague ideas into clear definitions. Even if none of us got everything we wanted, at least we left the room knowing exactly what “this feature” was supposed to be.

And yet, just when we thought we had alignment, a new storm rolled in. Because once you settle on what to build, you face an even bigger monster: figuring out what those features actually mean.

The Galaxy of Questions

Of course, even those “simple” MVP features unleashed a galaxy of new questions:

• What exactly is a “client”? A person? A company? Both?
• How long should we store their data?
• What compliance rules apply (hello GDPR)?
• What counts as a “document” — and how do we safely handle it?

Each feature was like opening a Russian doll — one question hiding another hiding another.

Some questions were serious. Others… less so. At one point, a logic bug let you book an appointment for one client with another client. I stared at it thinking: listen, we’re not building Tinder here.

Our Guiding Star: Build for One

Here’s what we realized: we didn’t need to solve everything up front.

Instead, we picked a principle: Build for one.

We already had small business owners we knew personally. So we decided:

• Build for them.
• Solve their problems first.
• Then look for others with the same problems.

This wasn’t just easier. It was liberating. Every time we faced a thorny question, we asked: How does our guiding customer do it today? What would make their life easier?

That kept us grounded in reality instead of drowning in hypotheticals.

What’s Next

That month gave us a blueprint, a name, and a direction.

It wasn’t perfect. It wasn’t final. But it was enough to start moving.

Next week, I’ll share how we chose the technology stack to bring ClientHero to life — and how our plan to “build it in a month” turned into a comedy of underestimations.