Building software products doesn't just end at launch
Published 5 days ago • 4 min read
12 MAR '26
Building software products doesn't just end at launch
This article will be published on my website & DULA’s blog in a few days, and I want you to read it first and let me know your thoughts.
It’s been inspired by recent experiences in my day-to-day life and conversations with people I work with. Hope you enjoy reading it even if you’re not exactly in the software space.
Hi Reader,
I’ve seen a lot of software product outsourcing go sideways. And when I dig into why, it almost always comes back to the same thing: nobody thought past launch day.
Every time someone reaches out to me about building a product, I ask them one question early in the conversation: “What’s your plan after you launch?”
You’d be surprised how many people go quiet. (Like they’ve genuinely never thought about it.)
The vision is clear, the idea is electric, and in our heads it goes something like: build the app → launch → make moneeeyyy 🤑. CHA CHING!! 💰
Totally totally valid, but here’s the thing nobody tells you upfront: “shipping is not the finish line. It’s the starting point.”
And I get it. The launch is the sexy part. It’s the milestone you’ve been building towards, the thing you post about, the thing that makes it feel real. So it makes sense that most of the planning, the energy, the budget, the conversations etc. all get poured into getting to that moment.
But after you’ve launched, and the “high” has died down, you realize that the work isn’t done (I mean, it’s never really done, but nobody really wants to hear this). Users sign up and find bugs you didn’t catch in testing. Someone on Twitter (sorry, X) posts about a broken flow. Your hosting bill comes in higher than expected because you didn’t anticipate the traffic spike. A feature that seemed simple in the brief turns out to need three other things built first. Welcome to software development (Oh, you thought it was just about writing code? Cute!!! “Let’s Vibe code away! Get me some Claude Code or Cursor, and we’re golden!” 💀 We’ve all been humbled by it. 😂)
And that’s just week one!
The reality is that software is never really done. It’s a living thing. It needs to be fed (it gets hungry) with fixes, with improvements, with the occasional full rethink when the market tells you something you weren’t expecting to hear. The products that win long-term aren’t just the ones that launched well. They’re the ones that had a plan for what comes next.
The dangerous assumption isn’t “my product will fail.” Most founders are optimistic enough to believe in the upside. The dangerous assumption is “once it’s built, it mostly runs itself.” It won’t. And if you’ve handed a codebase to an agency with no plan for what happens after, you’re one team change, one key engineer departure, or one bad handoff away from a very expensive problem.
So before we talk about solutions, I want you to sit with the question for a second: do you actually have a plan for after launch?
Not a vague “we’ll figure it out” plan. A real one.
If the answer is no.. or “sort of”.. keep reading.
The models that can work (and what they really involve)
1. Build with an agency → hire a team → keep building
You bring in an agency to get to launch. Once you’ve validated the product and have some revenue or funding to work with, you hire an in-house team and hand over the codebase.
Works well when: You have a clear growth trajectory and the budget to hire. The agency did clean work (documentation, proper architecture, not a spaghetti codebase held together by prayers and vibes).
Watch out for: Bad handoffs. A messy codebase that a new team inherits is a nightmare and an expensive one. (This is why I always say: the quality of the build determines the cost of what comes after.)
2. Build with an agency → stay on a maintenance retainer with them
You build with an agency and just… keep working with them. They handle ongoing maintenance, bug fixes, smaller feature releases. You focus on the business.
Works well when: You don’t want to manage an engineering team and the agency has proven themselves. It’s clean, lean, and lets you stay focused.
Watch out for: Agencies that deprioritise retainer clients in favour of shiny new projects. Make sure the relationship and the SLAs are clearly defined.
3. Start with your own team → grow with your own team
You hire engineers from day one. Full control, full ownership, full cost.
Works well when: Engineering is core to your product’s competitive advantage and you have the capital (and honestly, the patience) to build and manage a team.
Watch out for: The early days are expensive and slow. You’ll need a strong technical leader; a CTO or at minimum a fractional CTO/CPO to make sure you’re not just accumulating technical debt from the jump.
4. Get a technical co-founder → build a team together
You find someone who believes in the vision enough to co-own it with you. They lead product and engineering while you lead everything else.
Works well when: You’re pre-revenue, pre-funding, and need to move fast without a big budget. Equity is the currency here.
Watch out for: Finding the right co-founder is genuinely hard. A bad co-founder relationship can sink a company faster than bad code. (Take your time with this one. Seriously.)
So which model is right for you?
Honestly? It depends on three things:
Your context: Where are you in the journey? Pre-idea, pre-revenue, post-funding? The stage you’re in changes everything.
Your budget: Be honest about what you can sustain, not just what you can afford right now. Some models are cheap to start and expensive to maintain. Others cost more upfront but save you later.
Your scenario: Are you a solo founder? Do you have a business co-founder? Are you trying to raise? Are you bootstrapping? Your personal situation shapes which model is actually viable.
There’s no universal answer, which I know is a bit annoying to hear. (Trust me, I wish I could hand you a formula.) But the first step is simply acknowledging that the work continues after launch and building that into your plan from the very beginning.
If you’re not sure which model fits your situation, reply to this email. I’m happy to help you think it through.
If you made it this far, thank you sooo much for reading through. Feel free to hit me up if you have any questions.
19 FEB '26 So... I turned 30, and I still don't know what I am - (Part. 2) These are the introspections of a newly realized 30-year-old boy. Hi again Reader, Last week, I wrote to you about how I gave up on my dream of trying out every single tech career path because I realized how unsustainable it is to maintain too many interests. There are always trade-offs. For example, if I’m trying to get deep into motion design, my frontend engineering skills suffer and vice versa. Something has to...
12 FEB '26 So... I turned 30, and I still don't know what I am - (Part. 1) These are the introspections of a newly realized 30-year-old boy. Hi Reader, When I was 18, I had this grand dream to try out every career path in tech at least once. I was already a good enough designer, and I got an internship at a Ghanaian tech company where I had the opportunity to sink my teeth into… well, everything. I got access to one of Ghana's best engineering teams, and I just soaked it all in. For the next...
