From Data Chaos to Real Impact: Why We Built Our Own ESG Solution

Let’s be honest: you can’t escape ESG (Environmental, Social, and Governance) talk these days. The pressure for transparency is coming from everywhere: regulators (like the CSRD) demanding strict reports, investors using it to measure risk, and customers wanting to see real accountability. 

But here’s the catch: there’s a huge gap between wanting to be sustainable and actually proving it with data that can be audited. This is where most companies get stuck. Moving from good intentions to real-world action, especially on CO2 emissions, is an incredibly complex data, process, and tech challenge. 

Our multidisciplinary team of Business Analysts (BAs) and Developers (Devs) was recently thrown right into the middle of this exact challenge for a client.

Almost immediately, we faced the first critical decision, a classic tech dilemma: do we go for the “safe” off-the-shelf solution, like Salesforce Net Zero Cloud, which promises fast results? Or do we roll up our sleeves and build something custom, something that could handle the messy, unique reality of our client’s systems? 

We took the hard road. We chose to build. 

It wasn’t a decision we made lightly. The chosen approach considered the costs of a Salesforce license to address sustainability requirements. Given the initially high price, we decided to develop a solution tailored to the client’s needs. Following a careful analysis and comparison between the Net Zero Cloud data model and the existing environment, we opted to create a streamlined solution designed to allow for future scalability. 

But those “headaches” and “pains” are precisely what became our greatest asset. This article isn’t just a success story; it’s a transparent, human account of the lessons we learned building an ESG solution from the ground up. It’s about why a standard solution doesn’t always work, and how the challenges of a custom project gave us the expertise we now know is critical for helping others succeed. 

The ESG Landscape: The Business Analyst’s View

As BAs, our first job was to unpack the “E” in ESG. The goal wasn’t just to spit out an emissions report. The real goal was to build a “Single Source of Truth” that would let the client make smart business decisions. 

We quickly identified that the primary challenge was data fragmentation rather than a lack of organisational commitment. The data required to calculate Scope 1, 2—defined in the subsequent chapter—and the complex Scope 3 emissions were dispersed across multiple systems. Data was split between dynamic Salesforce records and a legacy Excel tool. This reliance on external spreadsheets caused inefficient context switching and prevented the team from leveraging real-time data. 

A standard, out-of-the-box solution comes with a rigid data model.  Our client’s reality, like most companies, was that their business processes were unique and their source systems weren’t about to be easily changed. Our analysis was clear: we needed a solution that would adapt to the business, not the other way around. 

A Deeper Dive: The Technical Challenge of the “Scopes”

From a technical and data perspective, not all “scopes” are created equal. This is why it’s such a hard problem to solve with a one-size-fits-all tool. 

• Scope 1: Direct Emissions (The “You” Problem) 
  • What it is: These are the emissions you directly control and own. Think: the fuel burned by your company’s own vehicle fleet, or natural gas used in your own buildings. 
  • The Tech Challenge: This is the most straightforward. The data is (usually) internal and structured. Our job was to build connectors to tap into fleet telematics and asset management systems. 
• Scope 2: Indirect Emissions (The “Energy You Buy” Problem) 
  • What it is: Emissions from energy you purchase. The classic example is electricity. You didn’t burn the coal, but you used the power. 
  • The Tech Challenge: A bit harder. The data is external (from utility providers), though it’s typically standardised. We needed a flexible ingestion process to handle this usage data reliably. 
• Scope 3: Indirect Emissions (The “Everyone Else” Problem) 
  • What it is: This is the big one, the one that causes the most pain. It’s all the other indirect emissions in your entire value chain. It’s so massive, it’s split into two key areas: 
  • Upstream: This is your supply chain—the “cradle-to-gate” impact. It includes emissions from purchased goods and services, business travel, employee commuting, and transportation of your materials. 
  • Downstream: This is the impact of what you sell—the “gate-to-grave” impact. It includes the transportation and distribution of your services, the energy used by your active services, and the end-of-life treatment of your products. 
  • The Tech Challenge: This is where standard tools often fail. The data is completely outside your control, fragmented, and often based on estimations (e.g., supplier reports, expense files). This, more than anything, is why a flexible, custom data model and a powerful, configurable calculation engine were non-negotiable for us. 

The Tech Decision: Why We Chose to “Build” vs. “Buy” 

This is where our Dev team’s perspective was crucial. The initial push to “build” was partly driven by the high licensing cost of a “buy” solution. But when we looked deeper, we found critical technical gaps that confirmed our direction: 

1. Ingesting Unstructured and Varied Data: The standard tools struggle with the sheer variety of sources we found. We needed a robust, flexible ETL (data ingestion) engine that could actually pull data from an active service database and cross-reference it with an Excel file of business travel. 
2. A Custom, Multi-Source Calculation Engine: Emission calculations depend on “emission factors.” A standard tool gives you standard factors. We needed an engine that could integrate both free, public-good sources (like the UK’s DEFRA) and, at the same time tempo, be ready to consume data from highly specific, proprietary (and costly) paid sources. This was a critical design point. 
3. A Flexible Data Model (Built for “What If”): The client didn’t just want to measure the past; they wanted to simulate the future. (e.g., “What’s the CO2 impact if we switch our fleet to EVs?”). This required a data model that didn’t just store the final number (“X tons of CO2”) but also the entire journey of the calculation—the source data, the emission factors used, and the date. 
4. A tool that is easy to use. Complex generic out-of-the-box solutions may require adequate training to be properly used, while a tailored solution is designed to be efficient and simple to operate. Furthermore, the “build” approach offers a “fit-for-purpose” application, that meets your current priorities without excess baggage and can evolve as business needs grow. 
5. For these reasons, we decided to design a custom architecture, leveraging the power of the core Salesforce platform but focusing on flexibility and integration. 

The Lessons We Learned (Our “Pains” and “Gains”)

This path was not easy. The challenges we faced (and trust us, there were pains) became our most valuable lessons. 

Lesson 1 (BA): Data Discovery is 80% of the Project.

• The Pain: Massively underestimating the time it would take to just find, validate, and clean the source data. Scope 3 is a special kind of nightmare, relying on data from suppliers you don’t control. 
• The Lesson: An ESG project is, first and foremost, a data governance project. Our job as BAs became mapping every single data source and defining, with the client, what was “good enough” for an MVP. 

Lesson 2 (BA/Team): The “True Cost of Custom” is in the Data, Not the Code.

• The Pain: We went the custom route, and while we focused on the development cost, we failed to identify the high, recurring cost of proprietary emission factors as a major project risk from day one. This financial weight only became clear later, limiting the tool’s potential for more granular calculations. 
• The Lesson: The total cost of custom development extends beyond developer hours to encompass the entire data ecosystem. This must be identified as a critical financial risk during the initial scoping phase. Experience has demonstrated that a sustainability expert must be involved from the outset to validate data acquisition costs, rather than being consulted retrospectively. Consequently, a modular design utilizing free DEFRA data became a strategic necessity to mitigate this unforeseen risk. 

Lesson 3 (Dev/Arch): The Architecture Must Be Built for Change.

• The Pain: Trying to hard-code business rules that were constantly changing as regulations (like CSRD) were clarified or as the client understood their own processes better. 
• The Lesson: The technical solution can’t be a monolithic “black box.” We built using micro-services and configuration objects (Metadata) that allow the client to tweak emission factors or add new data sources without needing a new code release. Architectural flexibility is more important than day-one features. 

Lesson 4 (Team): The Tool is a Means, Not an End.

• The Pain: The initial temptation to focus on building impressive-looking dashboards before we even had reliable data to feed them. 
• The Lesson: The real value isn’t in the pretty chart; it’s in the trust you have in the data behind it. We focused relentlessly on traceability (auditability) for every single number. The dashboard was the last thing we built, not the first. 

What Does it Take for an ESG Project to Succeed?

Looking back, the success (and survival) of this project boils down to a few critical factors: 

1. Executive Sponsorship: ESG is not an IT project. It’s not a sustainability project. It is a business transformation project. Without someone at the top unlocking doors and forcing different departments to share their data, the project will fail. 

1. A Truly Multidisciplinary Team: You need more than just BAs and Devs. We needed the client’s sustainability experts and our own data science specialists in the room. The BAs acted as the vital “translators” between these different worlds. 

1. Start Small, Then Iterate (MVP): Our biggest win was convincing the client not to “boil the ocean.” We started by getting Scope 1 and 2 (the things they control) calculated in a fully auditable way. Only then did we move on to the complexity of Scope 3. 

Conclusion: We’re Ready for the Custom Challenge

Our journey proved to us that while tools like Salesforce Net Zero Cloud are valuable, they are not a silver bullet. The messy reality of the real world—legacy systems, unique business processes—often demands a custom approach. 

The “pains” we felt in building our solution gave us an expertise you just can’t get from a manual. We know where the data breaks down, we know how new regulations impact software architecture, and we know how to build a calculation engine that is both robust and flexible. 

If your ESG reality doesn’t fit in a standard box, you might just need a partner who knows how to build for the real world. We know how, because we’ve been there and we learned from the pain.