Cloud optimisation vs Development velocity

As a startup, or fast growing MSP, you want to go fast and deliver value to your customer as soon as possible. This speed drives your revenue, supports marketing and sales activities ... velocity becomes your informal or formal KPI metric. You often have a runway in to handle.

On the other side, by delivering fast, you're often breaking things by cutting corners. While it is said that with proper processes like CI/CD with speed you're actually gaining quality, it is often not the case on early days or years of your growth ... instead you're taking on debt, technical debt. And some of this debt is visible in a form of cloud infrastructure and its maintenance costs.

There is a potential problem brewing here which we're often employed to resolve. If you allow to take on too much debt in a form of temporary infra cost by throwing $$ on problems, instead of fixing problematic architecture, then you're shortening your runway. If you slow down the delivery you may get the longer runway but it may be still not enough to fuel your sales, and win with the competition. Its a conundrum many funders and tech leaders need to solve.

With my team we often work in trenches with these founders and we're trying deliver stable infrastructure with the architecture fit for purpose. We're delivering optimisations and savings in places where it is possible and where it doesn't hurt the development velocity, or at least we're trying to do so. But this often means we're just barely balancing the debt which is being taken in other corners ... temporary solutions, quick fixes and hacks.

All this is all right if you know that this is how it works, that its a calculated risk and we're riding the same boat. But this is not always the case, hence I'm writing this rant ...

Comment or DM me if you would like to hear more rants on the topic!