Compute that served requests
$6,600a month
Capacity that was busy answering someone. 33% of the invoice.
Sustainable software engineering
Software That Costs Less To Run
We measure what your system costs to run, cut it, and price the work before you commit to any of it.
Your run-cost audit, scoped and priced
A software engineer reads it and replies within one business day with the audit scope and what it costs. No sales sequence.
You are answering for a cloud invoice finance keeps questioning and for an efficiency number nobody has traced back to your architecture.
How we know
From optimization and consolidation work across engagements with 50+ companies in 7 countries since 2015.
Two mandates, one architecture, and no line between them
Finance wants the invoice defended and the board wants a number for the report. Both answers live in the same system, and nobody owns both.
The invoice grew and nothing shipped.
Finance asks what changed, and the honest answer is that nothing did.
The efficiency number is due next quarter.
The person writing it has never opened your own architecture diagram.
Your platform lead suspects waste.
They cannot say which layer holds it without a week off the roadmap.
You have sat through the decks.
They open on global emissions and never touch a line of your own bill.
None of that is answerable until you know which layer of the bill holds the waste.
The four layers
Where the money actually goes
A cloud invoice is not one number. It is four layers stacked on each other, and usually only one of them holds the waste. The split below is a worked example on a 20,000 dollar monthly bill, and the ledger further down replaces it with yours.
Show data table
| Segment | Value (%) | Share |
|---|---|---|
| Serving compute | 33 | 33% |
| Storage and rest | 30 | 30% |
| Idle capacity | 22 | 22% |
| Egress | 15 | 15% |
Idle capacity and egress carry 37 percent of this bill, and idle capacity is the share that served nothing at all.
What we do at each layer
Every layer gets the same treatment: measure it first, change one thing, then hold to what the change bought.
| Layer | MeasureHow we find the number | ChangeWhat we actually do | What it risksThe cost of the change | CommitWhat we hold to |
|---|---|---|---|---|
| Serving compute | MeasureTrace the requests that actually burn CPU, on the traffic you really get. | ChangeMove work to the edge or to build time so fewer requests reach a server at all. | What it risksMoving work to build time trades a run cost for a freshness one. If your data changes faster than you rebuild, the page goes stale before it goes cheap. | CommitFewer served requests, with the response the user sees no slower. |
| Idle capacity | MeasureRead utilisation against what is provisioned, hour by hour, never on an average. | ChangeRight-size the instances and let the platform scale to zero where the traffic allows it. | What it risksScale-to-zero buys a cold start on the first request after a quiet spell. Fine on an internal tool, not on a checkout path. | CommitYou stop paying for capacity that served nothing. |
| Egress | MeasureCount the bytes leaving each service and price them at your provider's published rate. | ChangeCache at the edge, shrink the payloads, and move objects to storage that bills no egress. | What it risksCaching turns a cost problem into a staleness one, and storage that bills no egress usually bills more per operation. Both hurt when access is chatty. | CommitEvery byte that leaves is a byte a user asked for. |
| Storage and the rest | MeasureList every line item and match it to a service somebody still uses. | ChangeTier the cold data, retire orphaned resources, and consolidate duplicated infrastructure. | What it risksCold tiers charge to read and often set a minimum storage duration. Tiering data somebody still opens quarterly can cost more than leaving it alone. | CommitNothing on the invoice is left unaccounted for. |
Several of these layers have a deeper engagement of their own: performance optimization, infrastructure and DevOps, Cloudflare edge delivery, discovery workshops, and ongoing support. Larger programmes usually start at enterprise-grade delivery, and the full service catalogue lists the rest. We work primarily in TypeScript and JavaScript across the browser, Node and the edge, and the stack we build on is published in full.
The measurement
Measured against ISO/IEC 21031
We do not invent a scoring system. We use the Green Software Foundation's Software Carbon Intensity specification, published as ISO/IEC 21031, state the boundary we measured inside, and show you the arithmetic that produced the figure.
SCIEIMR
E is the energy your system consumes. I is the carbon intensity of the electricity where it runs. M is the embodied emissions of the hardware behind it. R is the functional unit you divide by, such as one page view or one API call. Change any one of the four and the score moves, which is what makes the figure something you can act on rather than something you file.
What the measurement counts, and what it leaves out
in the order a request meets them
The edge and the delivery path are counted.
Every request that leaves your origin and every byte that reaches a browser is measured where it is billed, so the figure reconciles against the invoice rather than a model of it.
Priced against your provider's own published request and egress rates.
Application compute is counted, idle capacity included.
The energy term covers capacity that is running, not only capacity that is serving, which is why provisioned but idle instances appear in the number instead of disappearing from it.
The energy term of the Software Carbon Intensity specification, applied to provisioned capacity.
Hardware you never see is counted as embodied emissions.
The machines behind a managed service were manufactured long before you rented them, and the specification amortises that cost into the score rather than pretending the cloud has no hardware.
The embodied emissions term of the same specification.
Third-party scripts are deliberately left out.
Analytics, chat widgets and ad tags run in your visitors’ browsers on somebody else’s instructions. Counting them would flatter a before-and-after, so they sit outside the boundary and the report names them.
Recorded as a stated exclusion in the audit, not omitted quietly.
The visitor's own device is deliberately left out.
We do not control the phone at the other end, so counting it would claim credit for a change we never made. It sits outside the boundary and the report says so.
Recorded as a stated exclusion in the audit, not omitted quietly.
10+ YearsLongest continuously active engagement
Measured from engagement start date, client register.
50+Enterprise engagements
Counted from enterprise engagements across 7 countries, 2015 onward.
7Countries we deliver into
Counted from billing jurisdictions on active and closed engagements.
That is our arithmetic on our worked example. The useful version is the same arithmetic on your invoice, which takes about a minute to set up.
Put your own numbers inYour numbers
Put your own numbers in
The example above is ours. Move the four controls to match your own bill and the ledger recomputes what each layer costs you, in the currency you are already paying.
Run-cost ledger
Set your own bill, then read which layer holds the money
Storage and the rest
$6,000a month
Everything the first three layers do not cover. 30% of the invoice.
Idle capacity
$4,400a month
Provisioned, running, and serving nothing. 22% of the invoice.
Egress
$3,000a month
Bytes billed on the way out of the platform. 15% of the invoice.
Compute that served requests is the largest layer of this bill
Start with the code pathOn these numbers, idle capacity and egress account for $7,400 a month, which is 37% of the bill. An audit opens those two layers first, because they are the ones where the spend and the work done by it have already come apart. What the audit finds is not knowable before it reads your bill, so no saving is quoted here.
Compute, total$11,000
Of that, idle$4,400
Egress$3,000
Idle plus egress, the two layers opened first$7,400
| Layer | Share of bill | Per month | Per year |
|---|---|---|---|
| Compute that served requests | 33% | $6,600 | $79,200 |
| Storage and the rest | 30% | $6,000 | $72,000 |
| Idle capacity | 22% | $4,400 | $52,800 |
| Egress | 15% | $3,000 | $36,000 |
Turn the ledger into a scoped audit
Send the numbers you just set and a software engineer replies within one business day with the audit scope and its price.
Whether this audit fits
Where we fit
Your cloud bill is large enough that a percentage of it is real money.
Someone is asking you for an efficiency number and you have nowhere honest to get it.
You would rather see the arithmetic than sit through another sustainability narrative.
Where we are the wrong call
You have not shipped yet, so there is no bill for anyone to read.
Your product is falling over under load, which is a reliability problem before it is a cost one.
You want the whole catalogue of engagements in front of you before you choose one.
Questions before the audit
The answers you and your finance owner both want before booking anything.
Will this just tell us to move everything to the edge?
No. The audit reads your bill first and reports where the money actually sits. Sometimes the answer is a cache rule and a retention policy, and no part of the architecture moves at all.
How is this different from our provider's own cost advisor?
A cost advisor sees resources. It cannot see which code path produced them. We trace the spend back to the request and the function behind it, then say what changing that code would cost you in software engineering time.
Can you give us a number for our sustainability report?
We give you a figure computed with the Green Software Foundation's Software Carbon Intensity specification, with the boundary we measured inside stated in the report. We do not certify it, and we name what sits outside the boundary rather than quietly leaving it out.
How much will the audit actually save us?
We do not know until we read the bill, and any figure quoted before that is a guess. The audit is scoped and priced before you commit, and it tells you what each change is worth so you can decide whether it is worth making.
Do we talk to a software engineer, or is this a sales call?
A software engineer, not a salesperson, replies within one business day. You describe the platform and the invoice, and you get a technical answer about your system rather than a pitch.
Do we have to move to a particular cloud provider for this?
No. We work inside the accounts and the infrastructure you already have. Edge delivery on a provider like Cloudflare is one lever among several, and it gets recommended only when your own numbers support it.
Still not sure the bill is worth reading?
Send the invoice line you cannot explain and a software engineer will tell you honestly whether an audit would find anything.
A software engineer replies within one business day.
Send us the invoice you cannot explain
Describe your platform and your monthly bill. A software engineer, not a salesperson, replies within one business day with the audit scope and what it costs.
You have seen the layers, the standard we measure against, and the boundary we draw around it. The next step is that arithmetic run on your own system rather than on a worked example.
Tell us what the platform runs on and roughly what it costs a month, and a software engineer reads it and replies.
Tirth BodawalaChief Technology Officer, Atyantik Technologies
- A software engineer replies, not a salesperson
- Everything you share stays private
- No obligation and no sales sequence