AUGUST 8, 2026
Nine Lessons That Changed How I Think About Building Products
A few days ago, I read Matthew Ao's reflection on Kortex and the mistakes that eventually pushed him toward Eden. I expected a clean list of startup lessons. What stayed with me was something less comfortable: most of the decisions he regretted didn't sound reckless when he made them. They sounded reasonable.
That made me think about Kizuna Hub and Dramabox. I've spent a lot of time trying to make both products cleaner, faster, and more complete. Some of that work matters. But I'm starting to notice how easy it is to get better at building while still being unsure about what should be built. These are the nine ideas I keep coming back to now.
1. I kept confusing engineering clarity with product clarity
When a product feels messy, my first instinct is usually to organize it. I think about the frontend, the data model, the flow between screens, and where each piece of logic should live. With Kizuna Hub, I spent a lot of time making the founder workspace and mentor-matching flow easier to understand. The system was getting clearer, but that still didn't answer the harder question: was this the problem founders, mentors, and universities cared about most?
A clean architecture can reduce engineering uncertainty. It can't tell me whether the product assumption underneath it is right. I'm trying to get better at asking which kind of uncertainty I'm actually reducing before I start polishing the system around it.
2. I was designing for demand we hadn't earned yet
Dramabox made this one obvious. It was easy to jump ahead to the problems a serious streaming product might eventually have: signed playback, backend entitlements, storage strategy, media delivery, and all the infrastructure around them. Those are real problems, but they weren't all my problems yet.
The first useful question was much smaller: can one series feel good to watch on a phone? If I can't answer that, designing for thousands of videos is mostly me borrowing complexity from a future that hasn't happened. I still care about scale. I just don't want to pay for it before the product earns it.
3. Rebuilding something that works can still be the wrong work
Rewriting code is tempting because the new version always looks cleaner in my head. The old version has awkward names, edge cases, and decisions I'd make differently now. Starting over feels like a chance to finally do it properly.
The question I'm trying to ask instead is simple: what does the rewrite let me learn or do that I can't do now? Working code carries knowledge, even when it isn't pretty. If a rewrite doesn't unlock something important, I may just be trading known problems for a fresh set of unknown ones.
4. Professional architecture is not always the right architecture
This is slightly different from avoiding rewrites. I used to look at architecture almost as a sign of maturity: more separation, more services, more protection for future cases. Dramabox changed that for me. A version with authentication, server-side entitlements, signed playback, and several cloud services would look much more complete on a diagram than the local-first version I was building.
But if the current goal is to prove the viewing loop, the smaller system can be the more responsible one. Good architecture isn't the architecture with the most pieces. It's the one that fits the question the product is trying to answer right now without making the next change unnecessarily painful.
5. Ownership begins when the original plan stops working
I used to think ownership mostly meant finishing the task you were given. That works until the task turns out to be based on a bad assumption, the implementation hits a constraint nobody expected, or the user problem changes halfway through.
For a small team, I think ownership has to stay attached to the outcome rather than the original spec. The plan can change. The feature can disappear. What shouldn't disappear is the person asking whether the actual problem got solved.
6. Commitment has very little to do with hours
Hours are easy to see, which makes them easy to overvalue. A long day, a busy chat, or a lot of commits can all look like commitment from the outside. But the part that matters more usually shows up when the work gets annoying: when an idea you liked fails, when a bug keeps coming back, or when the problem no longer fits neatly inside your role.
The people I want to build with aren't just close to the work. They care about where it ends up. That's harder to measure than time, but on a small team it matters a lot more.
7. Shipping slowly can quietly lower what a team accepts
I used to think moving slowly was mostly a speed problem. Now I think it can become a quality problem too. When every change feels expensive, fixing something mediocre starts to feel like a luxury. The team learns to live with rough edges because touching them again costs too much.
Fast iteration matters to me for a different reason now. It keeps decisions reversible. If a flow is confusing or an assumption turns out to be wrong, I want changing it to feel normal, not like reopening a six-week project.
8. A good argument should be easy for reality to destroy
With Kizuna, it's easy to build a convincing story around mentor matching, founder context, and university visibility. The danger is getting so good at explaining the idea that the explanation starts protecting the assumption underneath it.
I'm trying to do the opposite now. If I believe universities would pay for better visibility into founder progress, I should be able to say what evidence would make me stop believing that. A product argument becomes more useful when reality has a clear way to prove it wrong.
9. Conviction helps me move; certainty has to be earned
I still think conviction is necessary. If every new opinion can change the roadmap, nothing stays alive long enough to be tested. But conviction is different from acting like I already know the answer. I can believe a direction is worth pursuing and still leave room for the evidence to disagree with me.
That's probably the biggest thing I took from Matthew's story. I don't want to build with less ambition; I want to make the risky assumption visible sooner. The rule I'm keeping is simple: build the least amount necessary to learn the most important thing you don't know yet.