The tunnel felt safe
Building in the tunnel is strangely comfortable.
It’s just me, the screen, and the work.
I know what to do there: design, implement, refactor, repeat. I can stay in motion without asking anyone for permission or feedback. Progress is visible in commits, tasks, and prototypes. In that space, Utably is clean, controlled, and entirely in my head.
Now we’ve started our first internal tests.
That safety is gone.
People outside the immediate team are touching something I have been obsessing over for months. They click through flows I was sure were obvious. They get stuck where I thought everything was clear. They find bugs in places I considered “done”.
On paper this is what I wanted: feedback, signal, reality.
In practice, it feels like putting my judgment under a microscope. Every “this is confusing” lands not just as a product insight, but as a small hit to the ego.
This is the cost of daylight.
Competent, and still a beginner
My background is a mix of management consulting, engineering, and software. I know how to structure problems, ship projects, and talk to stakeholders. I know how to design systems and debug tricky issues. Yet nothing could prepare me for my role as first time CEO of a startup.
It is a different game. The edges are sharper. Suddenly it is not enough to be good at the work. I also have to be good at focus, communication, and decisions that affect other people’s lives and time.
I am used to being the person who executes.
As CEO, I also have to be the person who initiates:
- Reaching out to people who might become early customers or partners.
- Setting up conversations where the answer might be “this doesn’t make sense yet”.
- Showing the product before it matches the version in my head.
I still prefer building to any of that. Give me a full day of product work and I’m happy. Give me a full day of outreach and I will instinctively look for “just one more feature” to finish first.
But staying in the tunnel is not leadership. It’s hiding in productivity.
When work becomes visible
Opening the doors to initial testers changed the feeling of progress.
Before, most of the judgment came from inside the team. We know what Utably is trying to be. We see past rough edges and missing pieces. We can imagine the future version.
Testers do not care about the future version.
They only see what is on the screen right now.
They don’t know that a certain feature is “coming soon”.
They don’t read the code.
They don’t share my mental model of how everything is supposed to work together.
They click. They hesitate. They ask questions I did not expect. Sometimes they ignore entire sections I thought were central.
The first bug reports on flows I was proud of were not fun to read. My first instinct was to defend the decisions, to explain what they “should” have done. But their experience is the product. My explanation does not ship with it.
The shift is simple and brutal:
From “How elegant is this in my head?”
To “What actually happens on a tired Wednesday night when someone uses this in the middle of a stressful job hunt?”
Bugs and ego
Bugs used to be just technical problems. Now they are also emotional ones.
Every time someone reports a bug, it is a reminder that my mental model was incomplete. When the product is young, those reminders are frequent. It’s tempting to read them as a verdict:
You’re not ready. This isn’t good enough. You missed too much.
But that’s a story, not a fact.
There is another way to read it: as tuition.
You pay with pride, time, and a bit of discomfort, and in return you get knowledge you couldn’t have had on your own.
A pristine prototype with no users is a comforting illusion.
A slightly messy product in real hands is uncomfortable truth.
I’m trying to choose the truth, even when it stings.
Builder brain vs. CEO work
Most days I can feel two modes fighting inside my schedule:
- Builder brain wants long stretches of deep work, clear technical problems, and the satisfaction of shipping something tangible.
- CEO work means talking to people, asking questions, hearing “this part doesn’t work for me”, and picking what to do next, not just what to do now.
If I let things run on default, builder brain wins. There is always one more flow to polish, one more automation to script, one more improvement that feels “almost done”.
The problem: none of that matters if the product never leaves the tunnel.
Internal tests force the balance back:
- Sessions with testers go on the calendar first.
- Conversations about what they experienced come before new feature ideas.
- We write down what we expect they’ll do, then compare it to what actually happens.
It’s uncomfortable, but it turns vague “we should improve the UX” into concrete “this button label confused three people in a row.”
Inviting feedback earlier
For a long time, I treated feedback as something you earned once things were polished. The mental script was: “Let me get this to a high standard, then I’ll show it.”
Reality does not care about that script.
Feedback is most useful when the product is still flexible. When changing a flow is a day of work, not a three-month refactor. When you are still emotionally willing to delete features that felt like “your idea”.
With Utably’s first testers, I am learning to:
- Share rough edges with people I trust and say explicitly: “This is not finished. I want your honest reactions.”
- Ask narrower questions: “Where did you hesitate?” instead of “What do you think?”
- Treat confusion as a design issue, not a user issue.
- Log patterns instead of reacting to single comments.
Every loop puts a small dent in the ego.
Every loop also sharpens the product.
Separating self from product
The hardest part is not technical or logistical. It’s internal.
When someone says “this flow is confusing,” it’s easy to hear “you failed”. When a tester doesn’t get the value immediately, it’s easy to interpret that as “your vision is wrong.”
The lines between my identity and my work blur quickly. Founding a company makes that almost automatic. Utably is not just a project; it’s a big part of my daily life, my thinking, my energy.
But if I fully merge “me” with “the product”, every bug becomes a personal attack, and every suggestion becomes a threat. That is not sustainable.
So I am practicing a simpler frame:
- The product’s job is to reveal its weak points when people use it.
- The feedback’s job is to show what I could not see alone.
- My job is to listen, decide, and improve, and not to defend my past self.
Some days I manage that separation well. Other days, a single comment can derail my mood. Both are part of the process right now.
Why this phase matters
Utably exists because job hunting is chaotic and often invisible. Applications disappear into black boxes. Feedback is rare, vague, or non-existent. People are left guessing.
If we want to fix that, we cannot hide from feedback ourselves. We have to live the thing we are building:
- Clear loops.
- Honest signals.
- Adjustments based on what actually happens, not just what we hoped would happen.
Opening the doors to internal testers is the first real move from theory to practice. It is messy. It is slower than coding in a vacuum. It also makes every next iteration more grounded.
If you are in a similar phase, somewhere between “this lives in my head” and “people I don’t know are using it”, then this is what I would share from where I am now:
- Show your work earlier than you want to.
- Expect your ego to complain. That’s normal.
- Write down what you believe will happen before tests, then let reality correct you.
- Remember that feedback is about the product, not your worth.
We are still early. The product is not what I want it to be yet. My skills as a CEO are not where I want them either.
But the doors are open now.
People are using Utably, pointing out what does not work, and showing us what actually matters to them.
It is uncomfortable.
It is necessary.
And beneath the anxiety, it is exciting! Because this is where building in the tunnel finally meets the people it was meant to serve.