我一年推出 12 個應用程式,只有一個真正重要——而它不是做得最好的那個
I Shipped 12 Apps in a Year. Only One Mattered — and It Wasn't the Good One.
作者一年推出 12 個應用程式,真正改變其職業生涯的不是最自豪的作品,而是有真實用戶、需要修復故障的排程工具。只有真實用戶的使用和回饋,才能帶來實際學習;與其反覆打磨無人使用的作品,不如更快推出更多應用程式,讓真實用戶試用。Xenition 是一個 AI 工作空間,可按自然語言描述建構及部署應用程式。
I shipped twelve apps last year. I can tell you, instantly, which one I'm proudest of — clean architecture, actual tests, a Lighthouse score I'd put on a business card. And I can tell you which one actually changed my career. They are not the same app. They're not even in the same postcode.
The good one did nothing for me. The one that mattered had a bug in production on day two. For a long time I had that exactly backwards, and it cost me most of a year.
Quality is something you control. Mattering is something a user does to you.
Here's the thing nobody tells you when you're grinding through your "build projects" phase: those are two completely different variables, and you can max out the first one while scoring zero on the second.
The app I was proudest of was a project management tool. I architected it properly. I wrote the tests first. The commit history reads like a textbook. And it was used by exactly one person — me — who already knew exactly how it worked and would never, ever do anything it didn't expect. It was a beautiful, sealed terrarium. Nothing could get in to break it, which is another way of saying nothing real ever touched it.
The app that mattered was a scheduling tool I threw together for a friend who runs a small studio. It was ugly. No tests. I'm fairly sure the state management was a crime. But a real person opened it every morning, did things I never planned for, and when it fell over — and it did — I was the one who had to fix it before her day started.
The rule: a polished app with no users is a demo. A rough app with one real user is a product. The gap between those two words is the entire thing employers, clients, and your own skills are actually measuring — and you cannot cross it by polishing harder.
The "good one" was good because I controlled all the variables
That's the trap, and it's a comfortable one. When you build the thing only you use, you are both the developer and the entire user base, so of course it never breaks. You've quietly removed the one force that produces learning: a stranger doing something you didn't imagine.
I thought I was leveling up by making cleaner and cleaner versions of apps nobody used. I was really just getting better at building terrariums. More tests, more structure, more polish — all of it defending against a reality I had carefully kept out of the room.
The rule: if you're the only user, you're not testing your code — you're testing your own assumptions, and they always pass. Real usage is the only thing that disagrees with you, and disagreement is where every real skill comes from.
I couldn't tell in advance which one would matter
Here's the part that stings, because it kills the clean narrative. I did not ship the scheduling tool because I knew it would be the one. I shipped it because it was Tuesday and my friend needed it. If you'd lined up all twelve in advance and asked me to bet on which would change my career, I'd have pointed at the pretty one. I'd have been wrong.
You cannot predict the app that matters. The factors that make it matter — a real person, a real need, a real failure — live entirely outside your editor. All you can control is how many times reality gets to take a shot.
The rule: you don't find the app that matters by thinking harder about which one to build. You find it by shipping more of them, faster, and letting real users pick. Throughput beats prediction, because the thing that makes an app matter isn't in your hands — it's in theirs.
That reframes the whole game. The goal in year one isn't one perfect app. It's twelve live apps and one real user each, so reality has twelve chances to hand you the thing you can't manufacture: a war story, a client, a reference, a bug that taught you more than any course.
So the only real bottleneck is the gap between idea and live URL
If throughput is the strategy, then the thing slowing you down isn't your code quality — it's everything between "I have an idea for a tool" and "a real person can open it." The scaffolding. The auth. The database. The deploy. The hours of plumbing you've written fifty times that stand between you and the only part that teaches you anything: a stranger using it and breaking it.
That gap is exactly why I started building with Xenition — our AI workspace, a Flutter app on iOS and Android. I describe the tool I want in plain language — "a booking tool for a studio, owner can see the day, clients can request a slot" — and it builds and deploys the working app, real database and a real URL, in the time it used to take me to set up the repo. The learning is still all mine: the stranger still breaks it, and I'm still the one who gets up and fixes it. But the week I used to lose to plumbing before anyone could even touch it is gone. More shots on goal, same me.
The rule: the faster you can turn an idea into a thing a real person can break, the faster reality can hand you the one app that matters. Shorten that gap and you're not a better coder yet — but you're giving yourself far more chances to become one.
If you're shipping your terrariums right now
Stop optimizing the apps nobody uses. One more test on a project with zero users is a rounding error.
- Ship for one real person, not for your portfolio. Your friend's bookings, your own invoices, the spreadsheet your team is drowning in. One real user outranks a hundred GitHub stars.
- Get it live embarrassingly early. A rough live URL beats a flawless local repo, because only the live one can break on a stranger.
- Ship more of them than feels reasonable. You can't pick the winner, so buy more tickets. Twelve live apps, one user each, beats one perfect app with none.
- Keep what breaks. Every "it fell over and I fixed it" is worth more than your entire skills list — and you only get those from the ugly one that mattered.
The app I was proudest of is still the best code I wrote that year. It also did nothing for me. The one that changed everything had a race condition and a single user who kept showing up. If I'd known that in January, I'd have shipped the ugly ones faster.
What's the roughest thing you ever shipped that ended up mattering more than your polished stuff? I'll go first in the comments. 👇
來源:DEV Community · dev.to