Build or Buy? When We Replaced a Third-Party Service With Our Own Engine

We shipped our carbon calculator with a third-party emissions API. It worked. Users could calculate their carbon footprint, get real numbers, and start making decisions. For a while, that was enough.

Then it wasn't.

We moved from a bought solution to a purpose-built engine, and we used a decision framework along the way that any founder can apply. If you are weighing up build vs buy for a core part of your product, this is the story of how we made that call and what we learned from it.

The service that worked until it didn't

When we started building stepzero.eco's carbon calculator, we integrated a well-known carbon emissions service. It was the right call at the time. We needed to ship, we needed real data, and the service gave us both. Spending months building our own calculation engine before we even knew whether users wanted a carbon calculator would have been a poor use of time and money.

But as we iterated with real users and real data, three categories of problems showed up, and they were the kind of problems that get worse with time rather than better.

• Speed. Every calculation required a round trip to the external service. For a calculator that chains multiple categories together (electricity, vehicles, waste, flights, water), the delay compounded fast. Users were waiting seconds for something that should feel instant, and in a tool designed around quick calculations and iterative exploration, that latency was changing how people used the feature.
• Cost. Per-request pricing was fine at early-stage volumes. But we could see the trajectory. As user numbers grew, costs would scale with every interaction, especially for a feature users come back to as they update their data. The economics of a per-request pricing model become increasingly punishing as your product succeeds, which is exactly the wrong incentive structure.
• Accuracy and control. The service returned a single flat number for flight emissions, with no distinction between short-haul and long-haul, economy and business class. Waste was treated as one category, with no separation between landfill, recycling, and food waste. And the emission factors were not specifically aligned with UK government data, which matters enormously for businesses that need compliance-grade reporting.

We could not fix any of these issues. The data model was someone else's. The update cycle was someone else's. The priorities were someone else's. And that is the fundamental tension with third-party services that sit inside your core product experience: their limitations become your limitations, but their roadmap is not yours to influence.

The decision framework

Before we committed to building, we worked through four questions. We have since used this framework for every build vs buy decision, and it has proven useful enough that we would recommend it to any founder facing the same choice.

1. Is the third party a commodity or a core part of your product? If you are using a payment processor, that is a commodity. Everyone needs payments, and the market leaders do it better than you ever will. Do not build your own. But if the third party sits inside your core product experience, and its limitations become your limitations, that changes the calculation entirely. Our carbon calculations are central to what stepzero.eco does. They are the feature, not a supporting service.
2. Will you outgrow its limitations? Some limitations are temporary. Others are structural. A flat emissions number for flights is not a bug that will get fixed on someone else's roadmap. A single waste category is not a missing feature coming next quarter. These were design decisions made for a general-purpose service, not for a UK-focused small business carbon calculator.
3. What is the switching cost now vs later? Every month you stay on an external dependency, you build more code around its quirks. Your data formats align with its data formats. Your error handling accommodates its error patterns. Switching costs compound, and the longer you wait, the more expensive the migration becomes. We caught this early enough that the migration was measured in weeks, not months.
4. Does accuracy matter more than speed-to-market? For our first version, speed-to-market won. We needed to learn whether users even wanted a carbon calculator. They did. Once we knew that, accuracy became the priority. Government-grade emission factors were not a nice-to-have anymore. They were table stakes for the kind of product we were building.

What we built

We built an in-house calculation engine using the UK Government's official greenhouse gas conversion factors (the DESNZ/DEFRA dataset). This is the same data that large enterprises and public sector bodies use for official carbon reporting.

In practice, that means electricity and gas use UK-specific factors updated annually with each government data release. Vehicles are broken down across 16 types by fuel and size, so a diesel van and a hybrid company car get different factors rather than being lumped together. Waste is separated into landfill, closed-loop recycling, open-loop recycling, composting, and food waste. Flights are calculated by distance band multiplied by cabin class. Water covers supply and treatment separately. Hotel stays use country-specific factors for business travel. And there is a homeworking factor, which matters more than ever for distributed teams.

The engine runs entirely on our own infrastructure. No external calls. No third-party dependencies. When a user asks where the numbers come from, we point them to a published government dataset with a clear methodology, which gives the entire feature a level of credibility that a black-box third-party API simply cannot match.

The results

• Speed: calculations that used to take seconds now happen instantly. The entire carbon footprint for a business calculates faster than a single old API request used to take, which fundamentally changes how people use the calculator. They experiment more, try different scenarios, and engage with their data in ways the old latency made impractical.
• Cost: no per-request charges. The engine runs on existing infrastructure with no incremental cost per calculation, regardless of how many users we have. Our economics improve as we grow rather than deteriorating.
• Reliability: no external dependency means no third-party outages, no usage limits, no surprise API changes that force us into emergency maintenance at someone else's convenience.
• Accuracy: government-official emission factors, specific to the UK, updated on an annual release cycle. The kind of data that stands up to scrutiny from auditors, certification bodies, and stakeholders who want to know that the numbers are real.

The sequence matters more than the philosophy

If there is one lesson from this, it is that "buy first, build when you know what you need" is the right sequence. Not "always buy" and not "always build." Both of those positions are ideological rather than practical, and they both lead to bad decisions in different ways.

We bought first. That let us ship quickly, test our assumptions, and learn what actually mattered to users. We discovered that accuracy, speed, and UK-specific factors were non-negotiable. We could not have known that on day one, and building our own engine before we had that clarity would have been premature optimisation at its worst.

The mistake most teams make is treating build vs buy as a permanent decision rather than a sequence. You buy to learn. You build when you know enough to build well.

The moment to switch is when you can clearly articulate the structural limitations of what you bought and you have evidence that those limitations are holding the product back rather than just being theoretically suboptimal. If you never outgrow the bought solution, that is fine. It means the third party was the right call all along. But if you find yourself working around its constraints more often than working with its capabilities, and those constraints sit inside your core product experience, the calculus has shifted.

This is part 5 of the Building StepZero.eco series. Next: why we built a design system in Phase 1 instead of treating it as a later luxury. If you are weighing up a build-vs-buy decision and want to think it through out loud, we are always up for that conversation. Get in touch.