The Depth of Other Jobs

When I started building BetterKey, I quietly believed a familiar engineering myth.

If I built something genuinely useful, people would find it.

Not instantly, of course. But eventually. Good software had a way of surfacing. My job was to make the product better. Everything else could come later.

That belief survived exactly until I had something worth showing people.

Then I learned an uncomfortable truth: code does not sell itself.

The world responds to evidence, not intention. It does not know how much thought went into the product, how many hours are behind it, or how serious I am about making it work. It can only respond to what I make legible.

As a solo founder, there is no one waiting in the wings to pick up the work I do not want to do. If I do not write the marketing copy, there is no marketing copy. If I do not improve the onboarding flow, no one else is going to rethink it. If I do not make the screenshots, run the ads, edit the video, or rewrite the landing page, those jobs simply do not happen.

The bottleneck is no longer only engineering.

It is my own limits, gaps, and avoided work.

That realization has changed the way I think about a lot of work I used to see mostly from an engineering seat. I worked with marketers, designers, and product managers for years. I knew their work mattered. But knowing that from beside the work is different from trying to carry even the beginner version yourself.

I came into this with depth in engineering. Working solo has forced me to work in a more T-shaped way: keeping engineering as my deepest skill while building enough breadth across marketing, product, design, support, finance, legal, and everything else a company needs. The humbling part is that every direction I add breadth has its own depth.

A job looks different when you are accountable for its outcome.

A few days ago I had to fix what looked like a tiny marketing problem.

I had already published and shared a video with a QR code at the end so people watching on another device could install BetterKey immediately. It was the kind of small detail that should have stayed invisible.

Then the QR code stopped working unless I paid the company a yearly subscription. I thought that was ridiculous, so instead of paying to keep my own install path alive, I built an open source replacement, regenerated the QR code, updated the video, re-exported it, uploaded a new version to YouTube, updated the campaign links, and moved forward.

None of those tasks were especially difficult on their own.

Together they were an entire day.

From the outside, it probably looked like I “fixed a QR code.”

From the inside, it was a chain of interconnected work that only existed because I kept pulling on one loose thread.

I started noticing that pattern everywhere.

The same thing has happened with product and design.

As an engineer, it is easy to think building the interface is the hard part. Once the buttons work and the API responds correctly, you are done.

Except you are not.

Making software understandable is a completely different problem.

The best interfaces remove decisions instead of adding flexibility. They make the obvious path feel inevitable. They reduce the amount of thinking required from the user. I try to make BetterKey feel like Little Tikes: no sharp edges, dirt simple to pick up and use. Every unnecessary choice is work I have asked the person holding the phone to do instead of doing myself.

That turns out to be incredibly difficult.

I have rewritten onboarding screens dozens of times. Removed features I thought were important. Changed button labels that technically made sense but confused people. Rearranged screens that were perfectly logical to me because I already knew how everything worked.

The engineering was often finished long before the product felt finished.

My view of product management has changed in a similar way.

Earlier in my career, I sometimes found myself frustrated when product conversations drifted too far into how something should be implemented. There are real reasons to protect implementation judgment. The implementation details matter.

But building BetterKey has made me more aware of something I did not fully understand then.

Figuring out what should exist is its own difficult discipline.

Choosing what not to build. Deciding which user problem actually matters. Sequencing work. Simplifying instead of accumulating. These are not administrative tasks. They are hard decisions with real consequences.

I still think implementation ownership matters.

I just have a much deeper appreciation for the difficulty of deciding where implementation effort should be spent in the first place.

None of this has made me love engineering any less. I still lose track of time writing code. But I have stopped believing that engineering is somehow the “real work” while everything else exists to support it.

That has become clearest to me in the activation funnel.

I have been building out analytics to understand where people first experience value in BetterKey, and where they leave before they get there. Some of the dropoff has been humbling because the things that felt obvious to me were not obvious to new users.

One example was the settings gear.

To me, tapping a gear icon to enable features felt natural. Of course the settings lived there. Of course a user who wanted to configure the product would know to go there. But the funnel said something different. A huge number of users were not getting that far. They were opening the app, missing the real value, and leaving before BetterKey had a chance to become useful.

That insight led me to move from a single screen to a tab bar. It was a simple product change. It was also not the change I had realized I needed to make.

That is the curse of knowledge. Once you know how the product works, you can stop seeing all the places where a new person gets lost.

Instead of seeing engineering, marketing, product, and design as separate jobs, I have started thinking of them as a loop. Marketing brings someone to BetterKey. Product design helps them understand it. Analytics shows me where they get stuck. Engineering helps me improve it and try again.

Quality cannot live only in my head. A product has to become understandable to other people. That understanding is created through execution, through the product itself, the words around it, and the countless small decisions that help someone recognize why it matters.

Every discipline has invisible complexity that becomes harder to miss when you are responsible for the outcome.

That is probably the biggest lesson solo founding keeps teaching me.

Not mastery of every discipline. Just enough experience to be more careful, more humble, and more aware of what I still do not know.

I started this company thinking I was an engineer who happened to be running a business.

I am slowly becoming someone who builds products.

Engineering is still part of that identity. It probably always will be.

But I have learned that the work is not becoming less technical.

It is learning not to hide inside the technical parts simply because they are the ones that come naturally.