Google Cloud cost reduction for a music technology startup

A fast-growing music technology business was on a Google Cloud trajectory projected to reach €1 million a year. For a startup, that isn’t a cost problem. It’s a runway problem. Investors generally expect cloud to sit somewhere between 15 and 25% of revenue in the early stages, tightening towards single digits at scale; a seven-figure infrastructure bill would have consumed a substantial share of the company’s funding and shortened the distance to its next milestone with every passing month.

The problem

The issue wasn’t waste at the margins: idle instances, forgotten environments, the usual tidy-up list. It was architecture. The platform’s costs were dominated by unoptimised BigQuery usage and storage patterns, and BigQuery is a service where the architecture is the bill.

BigQuery’s on-demand model charges for the data each query scans, currently $6.25 per terabyte, and it scans every row of every column a query touches unless the table’s design tells it not to. The same question, asked of the same data, can cost pennies or hundreds of euros depending on how the tables are organised and how the query is written. Partitioning and clustering, which structure tables so the engine can skip data that can’t contain the answer, routinely cut the volume scanned by well over half, often far more. None of this is exotic knowledge, but it is exactly the kind of knowledge a small product team racing to ship features has no reason to have met yet. The platform worked beautifully; every query simply cost more than it needed to, and the queries were multiplying with the user base.

What we did

Cloudreason worked directly with the development team for roughly an hour a week: a standing session inside their normal development rhythm, not a parallel consulting exercise producing reports nobody had time to read.

We identified the core cost drivers, then guided a re-architecture of the platform around them: how data was stored, how it was queried, and how it moved through the system. Table design was reworked so queries scanned what they needed rather than everything they touched. Storage patterns were restructured so data sat in the tier its access pattern justified. And, as importantly, the team learned to see cost as a property of design, asking what a feature would cost at ten times the usage before building it rather than after.

The cadence mattered as much as the analysis. An hour a week, early, with the people writing the code, meant cost-efficient patterns were designed in as the platform was built, not discovered in an invoice afterwards, when re-architecting would have meant unpicking a live product.

The results

The projected €1 million annual spend was cut to less than a tenth of the projected run rate.

The company kept a seven-figure sum inside its runway, and its engineers now design with cost in view as naturally as they design for performance. The cheapest cloud spend is the spend that never happens.