Welcome
A public learning log on architecture, product thinking, and engineering leadership
“Architecture decisions are business decisions encoded in schema.”
If you’re reading this, you probably think about systems the way I do.
Not just how they work, but why they’re built that way. Not just what code to write, but what problems are worth solving.
This Substack is where I document those thoughts.
Why I Write
After 10+ years in engineering — from writing features to architecting multi-country fintech platforms — I’ve noticed a pattern:
The hardest problems aren’t technical. They’re contextual.
When should you abstract, and when should you keep it simple?
How do you design a system that serves business strategy, not just technical elegance?
What does it mean to transition from “person who builds” to “person who enables others to build”?
I don’t have perfect answers. But I have experience, trade-offs, and lessons learned — often the hard way.
This Substack is my public learning log. Not as a guru. As a practitioner still figuring things out.
Who I Am
I’m Chung Ho — a Tech Lead in Vietnam building multi-country fintech platforms, and a product experimenter behind open-source projects like stdout and cbash.
I write about the intersection of architecture, product strategy, and engineering leadership. Not as a guru with answers, but as a practitioner sharing trade-offs, lessons, and open questions from 10+ years of building systems at scale.
Welcome to my public learning log.
What to Expect
You won’t find “How to build X in 10 minutes” tutorials here.
Instead, I’ll be writing about:
Architecture: Merchant-centric vs. loan-centric, capability layering, event-driven trade-offs.
Product Experiments: Building stdout, local-first design, free → paid transitions.
Leadership: Tech Lead → EM, org design, mentorship at scale.
Writing Principles
I will:
✅ Share honest trade-offs, not just success stories.
✅ Focus on principles over implementation.
✅ Admit uncertainty when I don’t have clean answers.
✅ Connect technical decisions to business strategy.
I won’t:
❌ Use buzzwords without substance.
❌ Brag about achievements or metrics.
❌ Share confidential information from my company.
❌ Pretend I have all the answers.
Who This Is For
You might find value here if you’re:
A senior engineer thinking about architecture beyond code.
A tech lead navigating the transition to leadership.
A product manager working with complex technical systems.
Someone who prefers trade-offs over hype.
You probably won’t if you’re:
Looking for step-by-step tutorials.
Interested in hype-driven tech without substance.
Expecting perfect answers instead of honest exploration.
Frequency
I aim to publish every 2 weeks. But I prioritize quality over consistency.
If I’m deep in a build phase, I might go quiet. When I surface, I’ll share what I learned.
Join the Conversation
If this resonates, consider subscribing. It’s free, and you can unsubscribe anytime.
More importantly: reply to any post. I read every email. Your perspective challenges my thinking and makes this log better.
Welcome aboard.
— Chung Ho
P.S. Want to see my product thinking in action? Check out stdout.tools — a local-first developer workspace I built as a product experiment.