loading note metadata
field notes
Loading field notes.
filter by tag
allsystemsagentsoperations
loading note metadata
loading note metadata
I can ship a clean app to an audience of, generously, me. Building is one skill. Getting the right people to care is another — and the one I need to learn.
I have shipped just enough apps to be excellent at the part nobody asked about.
The code is clean. The deploy is green. The landing page even has a tasteful gradient.
The number of people using it? Generously, me.
If that sounds familiar, here is the good news and the bad news. The bad news: for a well-built app, that is now the default outcome. The good news: it is a solved problem, and the fix is a skill you can learn on purpose.
It is called distribution. This is a working guide to it.
Here is the shift that quietly broke the old playbook.
Building used to be the hard part, which meant being able to build was the advantage. A working product was, by itself, somewhat rare. Shipping one meant you had cleared a bar most people never got over.
That bar is on the floor now. A weekend and a few good tools will produce what used to take a small team a quarter. Wonderful — except for one detail.
The number of people who can find your app did not move at all.
So the asymmetry flipped. The supply of decent software went vertical. Attention stayed exactly as scarce as it has always been. When everyone can build the thing, building the thing stops being the moat.
The new bar is not "can you make it." It is "can anyone find it, understand it, and care." That is distribution, and it is now the part that decides whether your work exists in any way that counts.
The trap is treating the deploy as the finish line.
The app works. The database is connected. The build passes. The domain resolves. Something now exists in the world, so it feels done.
It is not done. Existing is not the same as being found, understood, trusted, or used. An app can be technically perfect and commercially invisible, and the internet is a graveyard of exactly those.
There is also a quieter reason builders stop here, and it is worth naming because it will come for you specifically. The code is comfortable. There is always one more bug to chase, one more edge to sand, one more bit of debt to clean up. That list never runs out, which makes it a wonderful place to hide. Polishing feels like progress, and it never once forces you to risk hearing "not for me."
Recognize the move. Then ship past it.
Most builders dodge this work by deciding it belongs to a different kind of person.
The loud one. The always-posting one. The one who enjoys sales calls, launch threads, funnels, and analytics dashboards.
Convenient, because it reframes a skill gap as a personality, and nobody can be blamed for a personality. I ran on this excuse for years. It is an extremely comfortable excuse.
But distribution is not a temperament. It is a set of moves:
None of that requires charisma. It requires doing it. The discomfort you feel is not evidence you are the wrong person — it is evidence the skill is undertrained, which is the most fixable problem there is.
One thing to internalize: distribution is a separate discipline, not a downstream feature of engineering. It sits closer to product, writing, and sales than to code. Being a strong builder makes you good at it about as much as it makes you good at the cello. Treat it as its own craft and it becomes learnable. Treat it as something a real app should not need, and you stay fluent in one thing and illiterate in the other.
Here is the system in one move: before you let yourself believe an app is finished, answer eight questions about it. If you cannot, you are not done shipping. You are done building, which is a smaller and lonelier claim.
Notice that none of these are about code. That is the point. This is the part you have been skipping, and it is the part that does the work.
Knowing the questions is not the same as building the habit, so here is a concrete loop. Run it per app, or per productized idea. It is more structure than the old plan — which, if we are honest, was "post once and hope" — and that is exactly the point.
For each thing you ship, produce:
Then track the only numbers that teach you anything:
Most of these will be small, and some will be zero. Fine. A zero is data. Silence you refused to measure is not. Every honest rep teaches you more than another evening of polishing did.
This blog is not separate from the plan. It is part of it.
Documenting the reps does two jobs at once: it makes the work repeatable, and it is itself a channel.
The trick is what you write. Skip the polished case study where everything worked. Write the actual reps:
That is more useful than a victory lap, and — conveniently — more interesting to read. Authority does not come from pretending to have mastered the thing. It comes from showing the work honestly enough that the next person's reps get better, yours included.
Here is the standard, and it is the whole post compressed.
An app is not done when it works locally. It is not done when it deploys. It is not done when the landing page exists.
It is done when you have made a serious attempt to put it in front of the right people, explain why it matters, and learn from what came back.
Building is the part you already know how to do. Distribution is the part that decides whether any of it mattered. And the good news, one more time: it is a skill, not a personality. You can start the next time you are tempted to add dark mode instead of telling someone what you built.
Tell someone what you built.
What's the difference between building and distribution? Building is making the product real — framework, data models, auth, UI, deployment, production hardening. Distribution is getting the right people to know about it, understand it, trust it, and use it. They're separate disciplines; being fluent in one doesn't make you fluent in the other, and treating them as one skill is how builders end up shipping to an audience of nobody.
When is an app actually "shipped"? Not when it works locally, deploys, or has a landing page. It's shipped when you've made a serious attempt to put it in front of the right people, explain why it matters, and learn from what happens next. Existing in the world is not the same as being found, understood, trusted, or used.
Is distribution a personality trait? No. It's a set of learnable behaviors: naming who the product is for, describing the painful moment it helps with, showing it in use, asking real people if the problem matters, putting the work where the audience already is, following up, and measuring what happened. Discomfort with it means the skill is undertrained, not that you're the wrong kind of person.
What should a distribution plan include? For each app, answer: who exactly it's for, what moment makes them need it, the one sentence that explains the value, where those people already spend attention, what proof would earn their trust, the smallest useful demo, the action you want them to take, and how you'll know whether the message worked. If you can't answer those, you're ready to keep building — not to call it shipped.
Building things nobody sees yet? That last-mile gap — from "it works" to "people use it" — is the work Stride Techworks does with small teams. Start with a Systems Documentation or tell us what you're shipping on the contact page.