Sustainable Software: How to Cut Your App’s Energy Use and Cloud Bill Together

For a software product, sustainability mostly means using less computing power: fewer servers sitting idle, fewer AI calls, fewer bytes sent to each visitor, less data stored that nobody needs, and work placed in regions with cleaner power. Nearly every one of those changes also cuts your cloud bill, so a founder can often pay for the work out of the savings.

What you control and what your cloud provider controls

AWS describes this as a shared responsibility in its Well-Architected sustainability guidance. The provider is responsible for sustainability of the cloud: efficient shared data centers, water use and buying renewable power. You are responsible for sustainability in the cloud: how much of that infrastructure your product keeps busy, and for how long.

Moving to the cloud doesn’t settle the question. A product that keeps ten oversized servers running all night uses ten servers’ worth of power, wherever they stand.

Where an app wastes energy and money

Where	What the waste looks like	What to change
Servers	Sized for the busiest hour and idle the rest of the day	Scale with demand, and switch off test environments outside working hours
AI features	A model call for every request, even repeated ones	Cache repeated answers, remember decisions and use AI only where it helps
Pages and apps	Large images, unused scripts, heavy libraries	Compress images, remove unused code, measure page weight
Data	Logs, backups and raw uploads kept forever	Set how long each kind of data is kept, then delete or archive it
Background jobs	Reports and batch jobs that run whenever	Schedule them, and run them where and when power is cleaner
Region	A data center chosen by habit	Choose by distance to users, data rules and the carbon of the local grid

The AWS guidance groups the same ideas into six areas: region selection, alignment to demand, software and architecture, data management, hardware and services, and process and culture. It makes a good checklist for a yearly review.

Pick the region on purpose

The same workload can run on very different electricity. Google Cloud publishes carbon data for each of its regions. For 2025, its Stockholm region ran on carbon-free energy 100% of the time with a grid intensity of 19 grams of CO2 per kWh. Belgium was at 79% and 126 grams, Northern Virginia at 57% and 343 grams, and Hong Kong at 2% and 489 grams.

Google’s own advice on that page is to pick a cleaner region for new applications and to run batch jobs in the cleanest region available to you. Two limits apply. Users far from the region will wait longer for each page, and data rules may fix the location for you. Subflare, a lead scoring product we built for EU businesses, stores all its data on AWS in Europe.

AI calls: pay for each answer once

Each AI call costs money and computing power. The fewer calls a feature needs, the cheaper and lighter it runs.

IPOPBOOKS, a bookkeeping platform we built for US small businesses, uses AI to suggest a category for each bank transaction. Once a bookkeeper approves a merchant, the next charge from that merchant is sorted from memory, with no AI call. Over time, the platform pays for fewer AI calls per client. The IPOPBOOKS case study shows the rest of the build.

Two more habits help. Cache answers to questions people ask again and again. And use the smallest model that passes your tests, since a bigger model costs more on every call.

Lighter pages, fewer bytes

Every image, font and script travels to every visitor, every visit. Pages keep getting heavier: in HTTP Archive’s July 2025 crawl, the median home page weighed 2.6 MB on mobile and 2.9 MB on desktop, up from 2.4 MB and 2.7 MB a year earlier (Web Almanac 2025). Lighter pages load faster on slow phones and move less data through networks and devices. The IPOPBOOKS marketing website scored 95 to 100 for desktop speed in Lighthouse when we measured it in September 2026.

Build decisions that lock in waste

Some waste is cheap to avoid while the product is being built and expensive to remove once it is live.

• Always-on servers for spiky traffic. If your product is busy for two hours a day, choose hosting that scales down, or to zero, when nobody is using it.
• Polling instead of events. An app that asks the server every few seconds whether anything changed sends a stream of empty requests. Push updates and webhooks send data only when something happens.
• Real time where a nightly run would do. Reports, exports and syncs that nobody reads until the morning can run once a night, in one batch.
• Screens that load everything. Load the data a screen shows, and fetch the rest when the user asks for it.
• Nobody owns the bill. Someone on the team should read the cloud bill every month and ask about any line that grows faster than the number of users.

Each of these is a line in the scope or the architecture, and each is easier to get right before the first release than after it.

Sometimes the product itself replaces something physical

Daisy’s Guide started as a printed guide for new parents. It sold in the low thousands of copies, but each copy cost money to print and ship, margins were thin and selling outside the US was hard. We rebuilt it as a web app that couples add to their phone home screen. Every sale now skips printing and shipping. The Daisy’s Guide case study has the details.

How to measure it

The Green Software Foundation’s Software Carbon Intensity specification gives a simple formula: the energy your software uses multiplied by the carbon intensity of that electricity, plus a share of the emissions from making the hardware, divided by a unit that matters to your business, such as one user or one API call.

You don’t need the full formula on day one. Start with a number you already have: cloud cost per active user, or per order, each month. Waste shows up there first. Add an emissions estimate once your provider’s reports or your own measurements make it reliable.

Those reports are getting better. Since October 2025, AWS’s carbon estimates for each account include emissions from making hardware and buildings, not only electricity. From December 2025, each month’s data arrives by the 21st of the next month. In June 2026, AWS replaced its Customer Carbon Footprint Tool with a new AWS Sustainability service (AWS release notes).

Pick the unit to fit the business. Cost per active user suits a SaaS, cost per order suits a shop, and cost per processed document suits an automation tool. Watch the trend from month to month: a unit cost that keeps rising while usage stays flat points straight at new waste.

How we would estimate the work

1. Our project estimate turns your brief into user stories. Each fix above, such as scaling servers with demand, caching AI answers or setting how long data is kept, becomes a story with its own hours. You confirm what is in scope, and every hour in the budget traces back to a story you kept.
2. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. It is a planning range, not a fixed quote.
3. If the work is part of a new product, the estimate suggests customer groups and gives each a TAM, SAM and SOM with a note on what the number covers. Treat them as hypotheses to test, not verified demand.
4. The unit economics show how many customers pay for the build and in which month it is paid back. A lower cloud bill per user shows up in the margin you enter. You can change any starting number and the math updates.

To get a free project estimate, describe the product or workflow in a few sentences.

What we would do

1. Export last quarter’s cloud bill by service and find the three biggest lines.
2. Switch off test and staging environments outside working hours.
3. Resize servers to real use, and let them scale with demand.
4. Cache repeated AI answers, remember approved decisions and test whether a smaller model does the job.
5. Set how long you keep logs, backups and raw uploads.
6. For new workloads, compare regions by distance to users, data rules and grid carbon before you choose.
7. Track cost per active user every month, and add emissions when you can measure them.

If a workflow in your business still runs on manual steps or tools that do more than it needs, our custom software development work starts with a pilot on that one workflow: $5,000-15,000 in 2-4 weeks, with AI used only where it helps the task. Other work is $39-55 an hour.

FAQ

What is technological sustainability for a software business?

Using less energy and hardware to deliver the same product: fewer idle servers, fewer AI calls, lighter pages, less stored data and cleaner regions. For a product team, the part you control is mostly the cloud resources your product keeps busy.

Does sustainable software cost more?

Usually it costs less to run. Most of the changes in this guide remove waste, such as idle servers, repeated AI calls and data nobody needs, so they lower the cloud bill as well as the energy use.

How do I measure my app’s carbon footprint?

Use the Software Carbon Intensity specification from the Green Software Foundation: energy used times the carbon intensity of the electricity, plus a share of hardware emissions, per user or per API call. Until you have those numbers, track cloud cost per active user each month.

Does the cloud region matter?

Yes. Google Cloud’s 2025 data shows its Stockholm region at 19 grams of CO2 per kWh of grid electricity and its Hong Kong region at 489. Distance to users and data rules still come first, but where you have a choice, pick the cleaner region.