Went skiing this week. Turns out that being a blue slope skier pushed on to the red slopes gives you approximately 1,000 times less time to think about AI. The priority becomes thoughts like “How am I going to make the next turn?” and “Please god let that snowboarder run further away from me.” Maybe I should prioritize extreme movement in my day to buffer this quarter-life crisis? Or… maybe that’s just yet another layer of the crisis.
When I take a break from my more doomsday-focused AI thoughts, I tend to obsess about renovating our typical Copenhagen three-square-meter bathroom. It is probably my longest ongoing ChatGPT thread. We keep debating the complexity of demolishing it ourselves and having professionals rebuild it. On paper, it doesn’t sound that complicated. Millions of people have done it before. But what if there is asbestos? You know where that conversation goes.
I would rather have professionals handle it and pay a higher price to make sure it is done properly and meets my expectations and quality standards. Even though I can watch all the YouTube tutorials in the world, my time is better spent on other things.
This thought process often leads me back to the shifts we are seeing, and will continue to see, in software engineering hiring trends. After the pandemic hiring boom in the software sector and the subsequent correction, long-term demand for developers remains strong. Software engineering roles are projected to grow roughly 17% over the next decade. What is changing is not the need for engineers, but how companies deploy that capability. Organizations are becoming far more deliberate about when to hire internally and when to rely on external expertise.
In my earlier article, “Rethinking Software Development,” I argued that it is getting cheaper to code and build software. But ownership, deployment, and value realization remain difficult to establish. During an era of “vibe coding” and increasingly accessible tools that can inflate perceived expertise, it becomes even more important to be critical about when you should build and when you should buy. AI speeds up development, but it also accelerates knowledge decay.
Returning to the bathroom renovation analogy, there is plenty of great content online explaining how to replace shower plumbing, reroute pipes, and lay tiles. My partner and I could probably figure it out. But is it something I would confidently stand behind years from now, when the apartment has new owners, and I might still be liable for the plumbing work?
Access to knowledge has never been cheaper. That does not mean the cost of mistakes has changed. Cheap knowledge does not mean cheap consequences. Let this be the force that guides your decision when choosing whether to build or buy software solutions. It may feel appealing to build everything yourself when information and tools are so easily accessible. But unrealized knowledge gaps are slow killers. Building solutions that are easy to create but difficult to own will eventually derail your focus from what drives your value. Being a builder at heart, I can easily burn time and money deciding to build and own something that is better bought. Where is the sweet spot between building and buying? From my experience working with engineers who can quickly absorb cross-domain knowledge and are very capable builders, the decision of whether to build or buy often comes down to a few signals.
When to Build
- Iteration speed matters – When you are looking at a project with high adaptation needs and an establishment threshold of domain R&D, this is where you opt to build. Internal ownership will become an advantage as it allows your team to move without external coordination, or even worse, permission or debate. The faster you develop and learn from the system, the more valuable the ownership will become.
- Knowledge compounds internally – As a side quest of the first point, if building a solution grows your targeted expertise, go for it. As Michael Scott would say, it’s a win-win-win. Knowledge built through these projects compounds internally. This is a long-term investment for you and your individual employees. Outsourcing would compromise the opportunity of developing expertise that could later grow into your competitive advantage.
- Low risk of failure – Last but definitely not least, try to assess what the cost of being wrong might become. If mistakes are easily reversible and don’t create long-term consequences, the learning gained from building may outweigh the cost of buying. In these situations, the experimentation becomes a successful investment rather than a liability.
When to Buy
- Hidden complexity – Infrastructure, security, compliance, and distributed systems hide layers of complexity that aren’t revealed until a mistake occurs. External domain specialists bring experience that helps avoid expensive trial-and-error costs.
- Liability or security risk – Cost of failure is not always technical; higher costs of failure include legal and financial consequences. When security, compliance, and safety are affected, tread lightly. Mistakes in these areas create lasting consequences far beyond implementation. This is where the specialist price tag is worth your peace of mind, and where we are seeing most vibe-coded solutions fail. You don’t easily restore credibility lost in these areas.
- Non-core capability – It all comes down to enhancing your value proposition as an operation. If the sought-after capability doesn’t strengthen your value proposition, building it in-house can drain resources and divert attention from what builds your competitive edge. Buying aspects that fall outside this range will allow your team to focus on areas where ownership creates value.
Thinking back to the bathroom renovation dilemma, the real question was never whether we could renovate it ourselves. With enough time, tutorials, and patience, we probably could. And let’s be real… a lot of involvement from our dads, haha. The real question was whether we wanted to own the consequences of that decision years down the line.
Software decisions are not that different. AI has lowered the barrier to building almost anything, but the responsibility of owning what you build remains unchanged. Systems need to be maintained, secured, supported, and trusted long after the initial excitement of building them has passed. Just because you can build something does not mean you should. In an era where building is easier than ever, knowing when not to build may become the more valuable skill.
For now, easier knowledge acquisition raises the threshold of what kinds of software we choose to invest in. But the true cost of building countless small internal solutions has not yet been fully revealed. We will likely only understand that cost once some of those systems start failing. In the end, many of these decisions come down to economics, which is something I’ve been thinking about a lot. How does this AI revolution and the upcoming agentic era change the pricing of software solutions? I’m going to explore that in my next post.
In the meantime, explore building opportunities with an open mind and experiment with AI solutions that speed up delivery, but remain critical of their long-term cost.
This blog was originally published by the author at Just Because You Can Build It Doesn’t Mean You Should.
