The Thing You're Best At Is the Trap

You can build anything. That’s the problem.

Every hour in the editor feels like progress. Tests pass, the thing runs, the diff is clean. It’s the one place you’re certain of your own competence, so that’s where you go.

And while you’re there, the company is dying somewhere else.

Not from a bug. From the work you’re not doing because it isn’t code: talking to people who might pay, putting the thing in front of strangers, asking for money before you feel ready. That work is uncomfortable for exactly one reason: you’re not sure you’re good at it. So your mind quietly reroutes you back to the editor, where you are.

This is the first piece in a series about that gap. Not the gap in your skills, but the gap between what you’re good at and what the company actually needs from you this week. For a technical founder those are rarely the same thing, and the distance between them is where most good products quietly fail.

It matters more now, not less. Building used to be the moat. In 2026 it’s close to free. You can stand up in a weekend what took a team a quarter not long ago. Every technical founder half-suspects their core skill just got commoditised. They’re right. And when building is cheap, the work that isn’t building becomes the entire game. The one thing you’re best at is the one thing the market has stopped paying a premium for.

Competence is a bad compass

When you don’t know what to do next, you do what you’re best at. It feels responsible. You’re being productive. You’re shipping.

But “what I’m best at” and “what moves the company” are different signals, and early on they point in nearly opposite directions. The company needs you to find out whether anyone wants this; you give it another refactor. It needs ten honest conversations with strangers; you give it a cleaner deploy pipeline.

None of that is laziness. It’s the opposite, which is what makes it so hard to see. You’re not procrastinating on Twitter. You’re improving the codebase. You’re paying down tech debt. You’re setting things up properly so they’ll scale. Every one of those is defensible on its own, and that’s the trick: each individual hour has a good reason, and the sum of them is a company that has learned nothing about whether it should exist.

Effort in the wrong place looks identical to effort, right up until you run out of runway and realise you built a beautiful answer to a question nobody asked. The market has never once cared how clean your architecture is. It cares whether the thing solves a problem someone will pay to stop having, and the editor is the one room that reliably tells you you’re doing fine while you avoid finding out.

The tell is comfort. The work that grows a company early is almost always the work that makes you feel exposed: charging money, being ignored, being told no by someone you respected. If your week was hard but never uncomfortable, you probably spent it hiding in the part you’re good at.

The weekly test

So here’s the lens. Use it every Friday.

Ask one question: did I learn anything this week that the market told me, or only things my own code told me?

Market signal is anything that came from outside your own head. Someone tried it and got stuck at a particular step. A stranger paid, or didn’t. Someone you cold-messaged replied, or ignored you. A price made someone flinch. Those are facts about the real world, and they’re the only facts that compound.

Code signal is everything your own work told you. The tests pass. The bug is fixed. The thing is faster. All true, all real, and all worthless as evidence that you’re building something people want.

If your week was all code signal, you didn’t have a hard week. You had a comfortable one that felt hard. That’s not a failure. It’s information. It means next week the first move is to go get one piece of market signal before you let yourself open the editor at all.

Here’s the shape it takes. A strong engineer leaves a senior role and spends eight months building a compliance tool for Australian aged-care providers. By month eight there’s audit logging, role-based access, a clean multi-tenant architecture you could talk about for an hour. What there isn’t is a single provider who has agreed to pay, because selling into that sector means slow, awkward conversations with operations managers who don’t return calls, and the codebase always has one more thing that genuinely needs doing first. Eight months of real work. Zero weeks of market signal. That founder isn’t behind on the product. They never started the company.

You don’t have to fix this all at once. You just have to stop lying to yourself about which kind of week you’re having.

What this series is

Each piece that follows takes one part of the non-code work and gives you the whole lens for it: validation, scope, pricing, distribution, hiring, money, your own head. No withholding, no “the real secret is in the course.” If you can run it yourself after reading it, good. That was the point.

The throughline never changes: you can build anything, and that’s the trap. The skill that got you here, making the machine do what you want, is real, and it is not the skill that keeps a company alive. The sooner you stop reaching for it every time you’re unsure, the sooner you’ll find out whether you’ve got something.

I work with a small number of founders and teams on exactly this kind of judgement; there’s more on the about page if that’s useful. Otherwise just read on. The rest of the series is the actual work.

Next: why you’re not short on ideas. You’re short on evidence.