In This Article
Choose sustainability software by comparing buy, configure, custom-build and no-build options. Use a decision matrix to test fit, ownership and ongoing work.
Photo: Tidal marshland in Olhão, Portugal — Pexels
Last updated
How to choose sustainability software: buy, configure or build?
Choose sustainability software by the decision your team needs to make, then compare four routes: buy a standard product, configure tools you already use, commission a narrow custom system, or improve the process without new software. Keep all four on the shortlist until you can name the user, the decision and the person responsible for running the work.
A reporting deadline might justify a reporting platform. A missing approval step might need a change to the process. Neither tells you, on its own, to build an application.
The matrix and worksheet below are Council Fire's editorial recommendations for making that choice. They are not a vendor ranking, a compliance assessment or a claim that custom development costs less.
What decision must your sustainability software support?
Start with a sentence: "This person needs this information to make this decision at this interval." Replace "improve ESG" with something a team can demonstrate. Environmental, social and governance (ESG) reporting is a broad label; a buyer still needs to specify the work.
Use these four decision categories to narrow the brief:
- Disclose: assemble a report with traceable source records, review steps and the required output format. Ask the reporting owner and advisers to confirm which obligations apply before treating a framework template as a purchasing requirement.
- Reduce: compare emissions sources or interventions and decide what to change. Evaluate the accounting method separately from the project decision. The GHG Protocol Corporate Standard addresses corporate emissions inventories; it does not supply a standard for conducting verification.
- Source: decide which supplier needs follow-up, what evidence to request and who can resolve missing information. Test the supplier's experience as well as the buyer's dashboard.
- Manage risk: decide which issue or project needs investigation, escalation or action. Require a record of the evidence and the person accepting the decision.
A team may need several of these jobs. Separate the urgent job from the ones that can wait rather than making every possible module a launch requirement.
Council Fire Labs describes its starting point as finding the bottleneck and defining the smallest system that removes it. Apply that discipline before choosing a product category: if the bottleneck is an unresolved definition or an absent approver, address that first. Council Fire's ESG Data Management Guide is useful for working through ownership and source records before a demo.
Should you buy, configure, build or make no new purchase?
Buying means adopting an existing product and its operating model. Configuring means using supported settings, forms, permissions or automation in an existing stack. Building means commissioning software for a specific gap. No-build means improving the workflow with the tools already available, without commissioning or buying another system.
These routes can be combined. For example, a buyer could retain a standard accounting product and commission a small connection to an internal project register. That is an illustrative design option, not a Council Fire client case.
Use this matrix as a first comparison. The responsibilities and costs are items to resolve, not assumptions about a particular supplier's contract.
Route | Best fit | Reason to reject or pause | Integration responsibility | Operating owner | Costs to include |
|---|---|---|---|---|---|
Buy a standard product | An available product demonstrates the required workflow with acceptable changes to your process. | A critical requirement depends on an uncommitted roadmap item or an inaccessible paid tier. | Agree who maps, imports, reconciles and repairs each feed; check connector limits. | A named product administrator and business decision owner. | License, setup, migration, connectors, staff review, training, support and exit. |
Configure the existing stack | Current tools can support the workflow through maintained configuration. | The solution depends on fragile workarounds, unsuitable permissions or an administrator nobody can replace. | Assign ownership of forms, rules and connections; test changes against existing uses. | A stack administrator with time to maintain the configuration. | Added licenses, configuration, integration work, testing, staff time and maintenance. |
Commission a narrow custom build | A consequential, stable workflow gap remains after testing existing options. | Nobody can own the system, the process is still disputed, or the gap does not justify ongoing development. | Specify boundaries between builder, IT and source-system owners; include failure handling. | A business owner plus an agreed technical operator, internal or contracted. | Discovery, build, migration, hosting, monitoring, support, training, changes and handover. |
Improve the process; no new software | Clearer definitions, a simpler request or an approval change can resolve the problem. | Existing tools cannot safely handle required access, volume or evidence retention. | Name who transfers and reconciles records manually and how exceptions are logged. | The process owner, with a backup for recurring work. | Staff time, training, manual controls and a later review of whether the approach still fits. |
Do not treat the last row as doing nothing. Give a process-only change an owner and a review date. Conversely, a custom build should earn its place by addressing a documented gap, not by offering a more attractive interface.
This approach is consistent with the UK government's Technology Code of Practice, which covers user needs, reuse, integration, accessibility, privacy and purchasing strategy. That is UK government guidance, not a procurement rule imposed on every reader or an endorsement of this matrix.
What should a vendor demonstrate before you decide?
Ask each shortlisted provider to work through the same representative task using approved, non-sensitive records. Keep the expected output constant so you can compare the routes rather than the presentation skills of the sales team.
Request a demonstration that includes an incomplete input, a correction and an export. Then ask:
- Which requirements work today, which need configuration, and which need development? Record the difference between a released feature and a roadmap promise.
- Can a reviewer follow a reported value back to its source and see what changed? Ask how the system preserves earlier approved outputs.
- Who can enter, view, correct and approve information? Include the people supplying data, not only the staff consuming it.
- What would the lower-priced tier fail to do? Compare required capabilities before accepting an upgrade.
- What happens when a feed fails or a responsible staff member leaves? Name the person who sees the problem and the person who fixes it.
- Can your team retrieve a usable export, including the context needed to understand the records?
For a dashboard, specify the decision's timetable before asking for faster updates. A board review and an operational alert need different refresh and escalation arrangements. Council Fire's guide to ESG reporting with live-data dashboards examines source tracking and review states; use those topics to sharpen the demonstration, not to assume every measure needs a live feed.
Who owns integration, ongoing work and the exit?
Put responsibility in writing for each source-to-output connection. Assign who supplies access, approves the field mapping, checks migrated records and maintains the connection. The buyer, software vendor, implementation partner and custom builder may divide that work differently. A connector on a feature list does not settle the contract.
Agree on a comparison period and a stopping condition for every option. Include internal staff effort alongside supplier charges. Ask what changes the quote: another source system, more users, extra review roles, historical records or support outside the agreed scope. Compare the same required work; avoid treating a license price and a build quote as equivalent totals.
Exit deserves its own demonstration. Request a sample export, its field definitions, the cost of extracting attachments and history, and the time allowed to retrieve records after termination. For a custom system, resolve code and intellectual-property rights, hosting access, documentation and the skills needed to operate it.
The UK government's guidance on technical lock-in distinguishes commercial from technical dependency and recommends balancing portability against value. The practical question is how much dependence your team can accept, with what exit arrangements. "Custom" alone does not answer it.
Labs' published Scope, Build, Run and Evolve process describes weekly demos on the client's data, hosting or handover, documentation, training and individual releases. Those are useful topics for a scoping conversation. Confirm the actual responsibilities, access arrangements and support terms for the engagement; the public process is not a project-specific service agreement.
Does the workflow need AI?
Evaluate AI at the task level. Ask what it reads, what it proposes, what evidence it shows and who approves the result. Compare that task with a simpler rule, calculation or manual review before adding AI to the purchase requirements.
For a document-reading or drafting task, include ambiguous records and conflicting sources in the demonstration. Check whether reviewers can identify unsupported statements and correct them without losing the evidence trail. Record the review effort as part of the work, not as free labor outside the comparison.
The National Institute of Standards and Technology's AI Risk Management Framework is voluntary guidance for incorporating trustworthiness into AI design, development, use and evaluation. NIST's current page notes that version 1.0 is being revised. It is a risk-management reference, not a certificate that a product is safe or suitable.
Council Fire's AI sustainability reporting pilot acceptance checklist provides a separate next step for testing source support and permissions. Use that once you have a candidate task; do not let an AI demo decide the scope of the whole platform.
What does Council Fire's current software work demonstrate?
The Labs page distinguishes three examples with different statuses:
- Aptation is in service. Council Fire says the Resilience Authority of Annapolis & Anne Arundel County runs its portfolio, Resilient & Ready Anne Arundel, on Aptation. The page describes project ranking, climate and funding data, and readiness to adapt it for other jurisdictions.
- Trovance is Council Fire's own live product. Labs describes AI-answer monitoring and a ranked queue of work. It is an example of the team's product development, not a client sustainability outcome.
- Stakeholder Engagement Manager is in development. The page describes reading engagement materials and ranking methodology gaps, with review before import. It should not be evaluated as an already available client deployment.
These are first-party descriptions of capability and use. The Annapolis case study provides project context, but the program's reported results do not establish software-caused returns or a delivery forecast for another buyer.
For a prospective build, ask which existing capability can be adapted and which requirement needs new work. Carry the same scrutiny into access and participation: who must contribute information, who can challenge a recommendation and who needs a simpler way to use the system? Those questions connect the technology decision to the people affected by the program.
Which route will you test first?
Complete this short decision worksheet with the business owner and IT or procurement. It is a comparison aid, not a commissioning brief or a budget model. Leave uncertainty visible rather than filling the blanks with a vendor's assumptions.
- Decision, user and decision frequency: ____________________
- Current bottleneck and evidence that it matters: ____________________
- Must-have output and unacceptable failure: ____________________
- Existing tools, source records and access constraints: ____________________
- Route to test first, and the strongest alternative: ____________________
- Business owner and technical or process operator: ____________________
- Evidence that would change the choice; next review date: ____________________
If you cannot fill the first or sixth line, pause the software commitment and resolve the missing decision or ownership. If you can, compare the preferred route with its strongest alternative on the same task. Keep the scope small enough to see whether the choice works.
Explore Council Fire Labs for custom software, dashboards and data infrastructure. To scope your build, bring the decision, the existing stack and a named owner. Use the contact form to arrange the discussion; agree on a suitable sharing method before sending confidential documents.
Frequently asked questions
01Is buying sustainability software better than building it?
Neither route wins by default. Buy when an existing product demonstrates the required workflow with acceptable trade-offs. Consider a narrow build when a consequential gap remains and your team can support its operation. The Technology Code of Practice is a useful reference for testing reuse and integration before commissioning something new.
02Can we configure existing tools instead of buying an ESG platform?
Keep configuration on the shortlist if your existing tools can support the necessary records, permissions and review steps. Test that workflow with the administrator who will maintain it. Council Fire's ESG Data Management Guide can help identify the data-governance work to settle before choosing the tool.
03Does a reporting platform make us compliant or assurance-ready?
Do not treat a template or product label as that evidence. Confirm applicable requirements with the responsible advisers and test the supporting records and controls. The GHG Protocol Corporate Standard, for example, distinguishes developing a verifiable inventory from specifying how verification is conducted.
04How should we compare subscription costs with a custom-build quote?
Use the same workflow, scope and comparison period. Include implementation, integrations, staff effort, operation, changes and exit, then ask each provider to identify exclusions. The government guidance on lock-in is a useful reminder that portability and switching effort belong in the decision too. This article does not supply price bands or a predicted payback.
05When should we decide not to buy new software?
Test a process-only change first when the unresolved problem is a missing owner, disputed definition or unnecessary request. Keep a review date and check whether existing tools can handle the required access and evidence. The decision worksheet above is an editorial recommendation; it is not a claim that Labs has diagnosed your organization.
Related Resources
- ESG Data Management Guide: work through data ownership, quality and the records a tool must preserve.
- ESG reporting with live-data dashboards: examine source tracking and approval states before specifying a dashboard.
- AI sustainability reporting: a pilot acceptance checklist: test a bounded AI task after choosing what to evaluate.
- Smart-community data privacy: key questions: consider governance and access when a system includes community information.
Additional Resources
- GHG Protocol Corporate Standard: authoritative accounting and reporting guidance for corporate emissions inventories.
- UK Technology Code of Practice: a government reference covering technology needs, reuse, integration and purchasing.
- NIST AI Risk Management Framework: voluntary guidance for assessing AI risks, with current revision information.
About the author
Zach Chmael is Council Fire's Marketing Manager. Explore Council Fire Labs for the software and AI work discussed in this guide.
FAQ