Ok, maybe I understated that.
Inflation is rampant. Stock markets are in a nosedive. It’s been rough out there! Companies are responding the way they respond to every recession…with layoffs, slashed budgets, and meticulous expense reviews.
Maybe you’re in one of those organizations. Maybe you’ve already lost some engineering staff. If so, you’re likely wondering “what do we do next?”
You don’t have the luxury to simply decide to “not deliver.” If your company is going to survive the recession, you’ll have to put in work to right the ship! Your team’s workload isn’t decreasing even if the size of your team does, which might seem a bit ominous. What’s more, those urgent new initiatives aren’t going away– assignments that need to be completed to increase revenue for your company and make (or keep) the company profitable despite leaner times.
You’ll have to do more… with less. Uh oh, this sounds like a recipe for burnout, doesn’t it?
Don’t stress too much. In this blog, we will explore the tradeoffs between building the software yourself versus purchasing it from a third party and what to keep in mind as you decide.
The economy’s impact on building versus buying
Organizations with engineering capabilities are always evaluating “Build versus Buy.” If your team evaluated a Customer Data Platform recently, you might have decided (after much research and analysis) to build your own.
But the fundamental assumptions have changed in the last few months, haven’t they? When the economy is strong and things are flowing freely, it’s easy to “grow to fill the space”. That growth doesn’t have to be super-efficient because it’s growth; we hear that common refrain, “we’ll optimize it later”. But as society approaches an economic inflection point, the priorities around us shift dramatically. We can’t afford to “just grow and sort it out later”, we have to be more strategic in our approach.
You’re likely to find the heaviest spending associated with a homegrown solution in the “system maintenance” column: supporting those integration points, finding and squashing the bugs, keeping the dependencies up-to-date… all the usual topics of concern for software engineers.
Let’s think about this from a long-term perspective: the ability to reduce that maintenance budget would be a game-changer, wouldn’t it? The scary part of trying to reduce a maintenance budget by simple cutting is that it doesn’t work: neglected maintenance results in system instability, and in the long run increases your cost. If we’re going to reduce our maintenance costs safely, we have to change the system implementation. It’s time to revisit Build versus Buy.
Nothing’s more expensive than "free" stuff
Engineers can rarely resist the siren’s call of building their own solution. It’s fun to build solutions, which is why you got into engineering, and you’re up for the challenge. Might as well double down on your company’s investment in you. When your marketing team asks you to evaluate a CDP, you might think, “We don’t need to spend the money. We just need a bus to get Customer events out of the source applications and into a database! I could code it up over the weekend with a pizza and a couple of beers.”
But how easy is that, really?
Let’s assume just for the moment that you actually could do that. And that you could even make it bug-free (and while we’re off in fantasy land maybe we can ride our fluffy unicorns to Valinor to have tea with Gandalf!). Now some questions arise:
-
Who’s going to maintain this code you’ve written?
-
How much work is it going to be to add a new data field, or to remove stale information?
-
What will it take to add/remove integrations to other tools, or to migrate to a new database/data warehouse?
-
Where does it run, and who’s maintaining that hardware?
-
What’s the roadmap for this code and its infrastructure?
-
What if you add a new source application whose events you want to merge with the existing sources?
-
How are you going to pass the next privacy audit?
-
What happens if an open-source library you used in the coding finds a critical security flaw and needs to be patched?
There is clearly a lot to consider. The homegrown solution might have seemed cost-efficient to implement, but it was most likely the perfect solution for that moment in time. If anything needs to change, it’ll take some work, and that work will require time and money. Look around at your business and repeat after me: “Change is inevitable.”
Further, the capacity to do that work is exactly the commodity in short supply now that your team has gotten smaller! You can certainly still build the solution, but you’ve been in this business for a while. You know what you’ll hear next, don’t you?