Build vs Buy

The hard part isn't building it

Engineering has never been more accessible. But just because you can build your own carbon accounting system doesn't mean you should carry the product decisions and data architecture it requires.

How technical is your team? Adjust this content accordingly.

Executivedashboards, no code

Operationsindustry terms, no code

Technicaldatabases, APIs, queries

DeveloperPrisma, Next.js, Postgres

ArchitectOLTP, OLAP, CDC, temporal joins

The vibecoding era

It has never been easier to build internal tools

The last eighteen months have permanently changed what one person can build in a weekend. Cursor, Claude Code, Lovable, v0. The tools are extraordinary. A competent developer (or a resourceful non-developer) can stand up a working internal application in hours, not months. We think that's great. For many categories of software, "build it yourself" is the right call.

Simple dashboards, internal admin panels, workflow tools that sit on top of an existing database: these are what vibecoding was made for. If the data already exists somewhere and you just need a better interface, go build it. You'll learn something. It might be the right long-term answer.

The question isn't whether you can build a carbon accounting app. You can. The question is whether you want to operate one.

Carbon accounting is not a dashboard on top of an existing database. It is the database. It is the data layer, the methodology layer, the compliance layer, and the audit layer, all at once. And the hard part of building software has never been getting the first version running. It is making the hundreds of quiet decisions over months and years that keep the system coherent, correct, and useful.

The two layers

Application layer vs. data layer

Every serious software system has two distinct layers, and the difficulty of building each one is very different.

Application layer: UI, forms, dashboards Easier than ever

Data layer: storage, schemas, calculations, audit Inherently Complex

Operations layer: methodology, factors, compliance Requires expertise

If a database already exists, it has never been easier to spin up a front end on top of it. That's the application layer, and AI coding tools have made it almost trivially fast.

But carbon accounting means building the database itself. You're storing millions of records in a way that must be backwards-compatible, auditable, and queryable across both transactional and analytical patterns. There is no shortcut around that complexity.

Serious carbon accounting systems need two kinds of database performance simultaneously: fast writes for ingesting individual bills and activity records (transactional), and fast reads for rolling up total emissions across sites, scopes, and years (analytical). These workloads require different data structures. At scale, that means replication, columnar stores, or hybrid architectures. Getting this wrong doesn't break your app immediately. It breaks it at the worst possible time: when an auditor asks for a query you can't run fast enough.

The timeline problem

Day 1 vs. Month 6

The thing about internal tools is that building them means taking on a product role. Engineering complexity may have gone down, but product complexity hasn't. You still need someone making hundreds of decisions over months and years. Those decisions must cohere with each other and produce a system that's easy to use.

Day 1

Everything works

A working form for entering bills
A dashboard showing total emissions
Basic Scope 1 and 2 calculations
The team is excited
The CFO is impressed

Month 6

Everything is harder

Emission factors are out of date
No one owns methodology updates
Auditor can't trace a number to its source
Multi-currency bills are entered incorrectly
Dashboard times out with a year of data
The sustainability lead spends 40% of their time maintaining the tool

Questions to ask before you build

Seven questions for your internal build proposal

Before committing to building your own carbon accounting system, make sure your team can answer these questions. The answers reveal whether you're building a dashboard or signing up to operate a data platform.

Who will source and maintain emission and conversion factors?

DIY The climate team manually sources factors from EPA, DEFRA, IEA, and ecoinvent. They maintain a spreadsheet, update it annually, and hope no one uses the wrong version between updates.

Smarter You subscribe to a factor database or open-source library. Updates arrive periodically, but your team still has to map them to your schema, handle version transitions, and validate that historical calculations remain correct after each import.

Platform The platform ships a version-controlled emission factor library, updated automatically when agencies publish new factors. Historical versions are preserved so past calculations stay auditable.

How will you verify and scan bills for accuracy?

DIY You can build OCR using a large language model. But the sustainability team still has to read every extracted bill to verify the numbers are correct. One misread decimal can throw off a site's entire footprint.

Smarter You integrate a third-party OCR service with confidence scoring. Low-confidence extractions get flagged for review. Quality improves, but your team still owns the review queue, the edge-case handling, and the final sign-off.

Platform The platform trains college-educated data specialists who do white-glove QA on every scanned document: pixel-level duplicate detection, cross-referencing against utility provider formats, flagging anomalies before data enters the system.

How will you handle transactional and analytical query patterns on the same data?

DIY Most internal builds use a single Postgres database. That works fine for entering data. But when you need to sum environmental data across 40 sites, 3 years, and 15 Scope 3 categories (with filters), a single row-oriented database starts to struggle. You'll hit this wall right when you need the data most: during reporting season.

Smarter You add a read replica or materialized views to offload reporting queries. This buys time, but as data grows you're managing replication lag, cache invalidation, and the tradeoff between real-time accuracy and query speed yourself.

Platform Serious platforms maintain separate transactional and analytical data stores: fast writes for ingestion, columnar storage for roll-ups, with automated replication between them. The application layer doesn't need to know which store it's querying.

How will you handle currency conversion and foreign exchange rates?

DIY Multi-national operations submit bills in different currencies. You need to convert them for consolidated reporting. But which rate? The spot rate on the bill date? The monthly average? The rate your finance team uses? And when a rate changes retroactively, do your historical calculations update? Most internal builds hard-code one rate and discover the problem during audit.

Smarter You integrate an FX rate API and store conversion metadata alongside each record. But your team still decides which rate policy applies per entity, handles retroactive corrections when rates are restated, and builds the reconciliation logic for audit.

Platform A platform stores the original currency alongside the conversion rate used, supports multiple conversion policies, and preserves the full conversion trail so auditors can verify every number in its original denomination.

Who is the methodology expert advising your team on GHG Protocol, SBTi 2.0, CSRD, and evolving disclosure frameworks?

DIY Someone on the sustainability team reads the GHG Protocol guidance, interprets it, and translates it into application logic. When SBTi releases a new methodology version or CSRD disclosure requirements change, that same person has to understand the changes, figure out how they affect calculations and reports, and update the code, all while doing their actual job.

Smarter You hire a consultant or subscribe to a methodology advisory service. They provide guidance on standards changes, but your team still translates that guidance into application logic, runs the data migrations, and verifies correctness across historical periods.

Platform The platform employs dedicated methodology experts who track every standard and disclosure framework update, translate changes into system logic, and ship them as product updates. Your team uses the methodology. They don't have to build it.

How will you store an audit trail alongside the source data?

DIY Most internal builds store the final number. But auditors want to see the underlying calculation: which emission factor was used, when it was applied, what the source value was, who approved it, and whether it was adjusted. Retrofitting audit trails onto an existing database is one of the hardest migrations in software engineering.

Smarter You adopt an event-sourcing pattern or append-only tables from the start. The data model is sounder, but you still own the query layer for traversing lineage, the UI for displaying it, and the integration between audit records and source documents.

Platform A platform designed for audit stores the complete data lineage from day one: source document, extracted values, factor applied, calculation method, approval chain, and every change made along the way. The audit trail isn't bolted on. It's the foundation.

How will auditors, regulators, and verifiers access source files, methodology notes, and calculations?

DIY When an auditor or verifier arrives, you export spreadsheets, gather PDFs of source documents, write up a methodology note in a Google Doc, and hope they can follow the thread. Every audit or disclosure cycle is a fire drill because the evidence lives in different places.

Smarter You build a document management layer with role-based access, linking source files to calculation records. It works, but every audit or disclosure cycle reveals another view they need, and you're maintaining the access control system yourself.

Platform A purpose-built platform provides a dedicated view for auditors, regulators, and verifiers with read-only access to every source file, the calculation chain, methodology notes, and approval history. They click on a number and see exactly how it was derived, including factor version and the original uploaded document.

If your team can answer all seven of these questions confidently, and has the capacity to maintain those answers over time, building internally may be the right choice. For most organizations, these questions reveal why dedicated platforms exist.

The product role

Building software means owning a product

Building an application, even with the best tools, means taking on a product role. Someone has to decide how emission factors are versioned. Someone has to decide how Scope 3 Category 1 differs from Category 11 in the data model. Someone has to decide what happens when a site changes its reporting methodology mid-year.

These are not engineering decisions. They are product decisions. And they compound. Every decision you make constrains the next one. After hundreds of decisions, you have either a coherent system or a pile of special cases held together by workarounds.

Engineering accessibility does not remove product complexity. It just makes it possible for more people to encounter it.

The teams that build the best carbon accounting platforms have made these decisions thousands of times across hundreds of customers. They've seen the edge cases, built the abstractions, evolved the data model through multiple methodology changes. That institutional knowledge is the product, not the code.

See why teams choose to buy

Bring your hardest data challenge: a messy bill, a Scope 3 question, a multi-site rollup. We'll show you how Gravity handles it.

Talk to an expert Read the buying guide