Hello Fellows
Let’s talk today about a story. My story.
I want to share some real experiences with you—why I became a software developer in the first place, what it’s like to be responsible for multiple products over 15 years, and what it really feels like to be in that position.
Most of the people I talk to are employed. They work at some company, on some product that isn’t really theirs—but it should be, at least in some way. We often discuss ownership in those contexts, but it’s not quite the same.
I also mentor numerous founders, working closely with them through fellowships and coaching. They come with so many questions:
How do I start right?
What should I invest time and money into early on?
What’s the mindset I need at the beginning?
But what rarely gets asked is: Do I even want to become self-employed?
Sure, maybe someone has done some freelance work or taken on contracts. That’s a form of self-employment—but it's not the same as owning a company, being a founder, or being fully accountable for a product’s entire lifecycle.
And it’s a bit like going from a hobbyist to a professional in anything. Once you go pro, everything changes.
It’s the same when a good developer becomes a founder. You realize the thing you loved doing for years—building stuff—slowly fades into the background. You're no longer building every day. You're leading, strategizing, and selling. You become a mentor, a puzzle solver, not the one writing the code line by line.
Yes, in smaller companies, CTOs and tech leads often still write code. But it’s different. It's higher-level work, usually less of the fun stuff. You’re not bootstrapping your own little app at midnight just for fun anymore.
You're in client meetings with investors, trying to translate ideas into a sustainable strategy. You go from operational to strategic, stopping to be just a developer. You need to want and understand that shift deeply.
And that’s a hard truth. Many developers I see try to build a product they love but then struggle to sell it.
Because, let’s be honest:
It’s easy to build something. It’s hard as hell to sell it.
This is the turning point for many. You either learn to sell or your idea dies a slow death. You either figure out market fit or drown in features nobody asked for. You either grow as a businessperson or get stuck in the developer mindset, hoping someone else will rescue your product.
And then there’s the pressure.
Building a product and selling it simultaneously is brutal. For a while, you’ll work insane hours. You’ll do support and bugs, strategy and sales calls, all in one day. But you can’t sustain that forever.
👉 You need a plan.
Because if you don’t, burnout won’t knock gently—it’ll kick the door in.
It hit me more than once, always at moments I wasn’t prepared for. Always suddenly. And when it hits, it breaks you. You need to be aware of that. You need to ask yourself early on: Am I really ready for this?
For me, this all became real about 15 years ago. I stepped into responsibility for products and teams—and I’ll be honest with you: I wasn’t prepared.
I thought I could foresee everything.
I trusted my gut way too often.
I skipped the hard work of really understanding the foundation.
And because of that, I made many mistakes. I didn’t think things through in the beginning. I made fast decisions because I lacked experience, lacked context—and lacked someone to tell me: slow down and think like a business owner.
So here’s one core lesson:
You need to go feedback-first. Learn early what works and what doesn’t. Don’t just guess—observe, test, reflect.
Back then, we bought a software product, a packaged solution, and started building on top of it. As time passed, requirements became more complex, and we hit the limits of what it could do. The original vendor didn’t want to evolve it, so we did it ourselves. We layered our stuff on top, and we ended up with a Frankenstein product that became increasingly difficult to manage.
I wasn’t the only one responsible, but I was in charge. In hindsight, I would have done it differently today. That decision cost us years of effort trying to fix what we hadn’t designed with enough foresight.
It took nearly a decade to course-correct. But eventually we did. We shifted the architecture. We bridged the gap between business and development. We learned that everything starts with the “why.”
Why are we building this?
Who is it for?
How do we make it sustainable?
And most importantly
How does this product support people, customers, employees, and ourselves?
These days, I often see developers wanting to go solo, build their own startup, and raise money. And I get it. The dream is intense. But here’s another truth: Most of the happiest entrepreneurs I know are bootstrapped. They built slowly, smartly, and realistically.
But they also carried every single burden. Alone.
And it’s hard. Really hard!
I don’t say this to discourage you, but to prepare you.
This journey can be incredibly painful. It will test you. You will doubt yourself. And when you have to pay salaries, and your product isn’t selling, and you’re working 14-hour days, you’ll wonder what the hell you signed up for.
That’s why I say: before you start your own company, consider joining someone else’s journey. Join a company with a real mission. Learn the ropes. Understand leadership from the inside. Work with a good tech lead, one who mentors you. See the entire lifecycle before attempting to own it yourself.
My own story took that long route.
Ten years of struggle.
Ten years of fixing early mistakes.
And only then did we really start building the kind of systems and teams that felt aligned. We tried MACH architecture. We tried gluing together Auth0, CMSs, shop systems, CRM tools—you name it. And while that works in theory, it didn’t work for our context. So eventually, we started making more things ourselves.
Yes, we reinvented the wheel. But this time, the wheel actually fit. And that’s something I want you to remember:
Context matters.
Your use case matters.
And sometimes the shiny solution isn’t your solution.
So when you read all the evergreen content online, when you see posts about microservices vs monoliths, which language to use, or which tools scale best, remember: those debates often don’t touch the real business issues.
What really matters is:
Can you lead people well?
Can you create a culture of trust and responsibility?
Can you build something people actually want to buy?
Ultimately, it wasn’t perfect code or trendy tech that kept our company alive.
The key factor was that the product worked.
It made money.
It paid salaries.
And we made better decisions when it counted.
That’s what I wanted to share with you today.
If this kind of storytelling resonates with you, let me know. I want to keep it real, less evergreen and more real-life. I'm just starting the camera (or writing here), when something hits me.
Thanks for reading. I wish you a focused, successful week.
By the way, since you have read this far in the article, you are likely an aspiring person 🍀. I am teaching you to become a better software engineer and a leader worth following.
You can find me on MentorCruise.com
Share this post