Efficiency means doing the same thing with fewer resources. In software, efficient code is faster, because that uses less compute. If some other software is waiting on yours to return, then your speed is saving upstream compute. Efficient data uses less space, which means less network bandwidth to move it around.

All this is very good, but getting that speed or compactness took effort. Someone got that process to work, and then someone wrote telemetry or tests to measure it, and then someone optimized code to get it there. Efficiency is expensive.

Therefore, efficient software is not the same as an efficient company–unless the software efficiency is important to the company’s business model.

Cat Swetel clarified this in her talk at Agile 2025: understand why your company cares about efficiency.

• Is it part of the business model?
• Trying to ride out hard times?
• or something else?

“Efficiency can be about hoarding or efficiency can be about access.” – Cat Swetel

Cat works at Nubank. Nubank serves millions of people who aren’t profitable for older banks, so older banks won’t (can’t) serve them. These are people with high transaction volumes and low balances. Nubank can only do this with super efficient transaction processing. It’s part of their business model.

Nubank is entirely on AWS, so they’re really good at optimizing cloud costs. For instance, they use a lot of Spot instances: cheaper than regular instances, but that computer can be taken away with 2 minutes’ notice.

With Spot, you pay less, but your infrastructure is less stable. The software has to compensate: services are quick to start up and shut down, and every part of the system handles ephemerality. Optimize for fault tolerance, not the happy path.

For Spot instances, Nubank does the upfront and ongoing work to cope with the instability and saved money on infrastructure. In another case, paying more for infrastructure saved money.

Their database, Datomic, has a local cache and an external cache. When transaction volumes shot up, the local cache ran out of space. Fetches from the external cache increased latency, slowing down all the services depending on this. Some of their spot instances happened to have an SSD, and they noticed that using that SSD to expand the local cache saved time (and therefore money) across the entire transaction flow. Numbers like: Spending $1 for SSD saved $3500 across the whole flow!

If each team minimized cost, then the database nodes wouldn’t add that SSD. Efficiency in the system is bigger than efficiency in the components. Nubank measures the cost of a flow, not a service. (They use honeycomb.io for this!)

Nubank learned: the Cost <-> Stability tradeoff isn’t. Instability is expensive! When fluctuations lead to scale-up, scale-down thrashing, efficiency is defeated. Building stable software on unstable infrastructure is expensive in development work, but the benefits of stability scale with their expanding demand.

Investing in software efficiency lets Nubank profit from customers that cost other banks money. They continually drive down cost per customer served, so they can serve more people. This is efficiency as business model.

If compute efficiency is not part of your business model, then it’s likely the investment in stability that it takes to work with spot instances won’t pay off. Instead, it could be a distraction from your core business. Does your product excel in user experience? In the complex legal knowledge built in? In traceability? in charm? Focus on these, until cost becomes a limiting factor. When you focus on efficiency, know why.