Custom Software for Energy and Utilities: A Buying Guide
Choose fix, configure, integrate, buy, or build by mapping the operational task, safety, assets, users, data, OT and IT controls, tests, support, incidents, and exit.
A power or utility team may fix a process, set up a product, link approved tools, or build software. Custom code is not the first choice by default. Keep expert reviews of the system, safety, law, data, and security in charge of their own decisions.
Start With the Operational Task
Name the service, asset, user, choice, record, and owner.
Map daily work, alarms, handoffs, field use, and faults.
List needs for safety, uptime, data, access, logs, and rules.
Keep business IT apart from plant and field control paths.
Find the cause before you select a tool.
Compare Fix, Configure, Integrate, Buy, and Build
Fix a bad rule, form, source, role, or training gap.
Set up a known product where the work can adapt.
Link tools only through a narrow approved path.
Buy a sector product when it meets the key need.
Build only for a lasting gap with a clear owner and budget.
Control OT, IT, Data, and Vendors
Use named roles, strong sign-in, logs, backups, and safe base settings.
Map assets, data classes, flows, sites, vendors, and terms.
Limit links between plant tools and business IT to approved needs.
Plan fixes, keys, events, outages, restore steps, and exit.
Keep a safe manual or local route where the service needs one.
Pilot Away From Unsafe Scope
Start with a small, low-risk path and a fixed term. Test good, bad, late, lost, repeat, and offline cases. Track task success, false alarms, missed alerts, delay, repeat work, access, staff load, help, and full cost. Stop on any breach of safety or control.
For process risk, read Can Software Fix a Broken Process?. For another asset setting, use Custom Software for Manufacturing.
Map the Utility Scope and Control Boundary
Name the utility type, service, asset, sites, users, market, systems, data, and safety impact. Map SCADA or other control systems, outage tools, asset work, advanced metering, customer records and billing, market systems, maps, and reporting when they apply. Keep read-only reporting on a different risk path from live field or plant control.
Draw the OT and IT zones, trust boundaries, data flows, remote links, vendors, and manual fallbacks.
List every command path and block any path the product does not need.
Give operations, engineering, safety, security, legal, data, procurement, and field staff a named review role.
Stop design work until the source system and owner for each key data point are clear.
Map Rules to Testable Requirements
Rules vary by country, state or region, utility type, asset, data, and impact. In the U.S., a bulk-electric-system project may need a NERC CIP review. NIST CSF can support a wider security-risk process. Water, gas, customer data, critical infrastructure, market, safety, and privacy duties may have different owners. Those names do not prove that a given rule applies.
Link each duty to the source, owner, system control, test, proof, review date, and exception path.
Cover identity, least privilege, logging, change control, patching, backup, restore, incident response, and vendor access.
Keep the approval trail with the code and release record.
Have the right safety, legal, and security owners approve the map before coding.
Score Fix, Configure, Integrate, Buy, and Build
Use hard gates first, then a weighted score. Hard gates can cover safety, required rules, offline work, recovery, data ownership, and control boundaries. Score fit, time, full cost, support, scale, data control, and exit only after each hard gate passes.
Ask at least two suitable vendors to prove the same critical use cases.
Inspect APIs, data models, queues, time sync, identity, logs, rate limits, and version support.
Price discovery, licences, code, hosting, integration, test labs, training, support, audits, upgrades, and exit.
Disqualify any route that cannot show a safe fallback and usable data export.
Use a Utility Vendor Evidence Pack
Give each vendor the same map, safe test, data sample, fault cases, and scorecard. A sales demo is not proof for the planned use.
Check hosting, data place, other firms, access, logs, fixes, backup, restore, and event proof.
Check support hours, fault levels, reply and restore targets, field help, and named owners.
Test links, versions, offline work, time, load, export, deletion, and end notice.
Confirm which audits, cover, and client refs fit the exact service and place.
Test a safe failure and an export before contract award.
Build a Five-Year Cost and Exit Model
Compare all routes over the same five years. Count buying, code, cloud or gear, links, data work, labs, safety, review, training, help, updates, faults, and exit. Keep guesses, quotes, and approved funds apart.
Model normal use, growth, high load, a price rise, a failed link, and early exit.
Count on-call work, trips, parallel use, rollback, records, audits, and spare parts.
Name who owns code, settings, data, logs, files, keys, and restore media.
Require a useful export, tested restore, move help, deletion proof, and service bridge.
Reject a route when safe upkeep and exit are not funded.
Rehearse Integration and Failure
Test in a safe lab before live use. Include stale data, lost links, duplicate messages, bad time stamps, wrong roles, high load, power loss, bad updates, vendor outage, and recovery. Never use a live control system as the first test bed.
Keep business reporting apart from field control unless the approved design needs a narrow path.
Use named accounts and short vendor access. Log and review key acts.
Run a shadow phase where the product cannot issue live commands.
Stop for unsafe output, lost state, wrong access, missed alarms, failed rollback, or unowned faults.
Worked Utility Decision
An electric distributor wants outage crews to see customer reports from the customer system beside outage records. A read-only link may meet the need with less risk than replacing either system. The team tests one district with fake and approved old cases. It checks record match, event time, delay, duplicate reports, role access, phone use, outage mode, and restore. All write-back is blocked. The pilot stops for lost events, wrong premises, missed safety notes, weak access, or failed recovery. This is a method example, not a client result.
Track correct records, delay, missing items, support load, staff time, and recovery.
Train dispatch, field, support, safety, security, data, and help-desk roles with real tasks.
Plan the old and new paths, staff notice, local support, cutover, rollback, and adoption checks.
Review capacity, contract, skills, cyber risk, and vendor health before each scale step.
Keep a funded support, patch, test, export, and end-of-life plan.
The Short Answer
Map the work, assets, users, safety, data, plant and IT paths, vendors, and faults. Compare the smallest safe choices and test away from unsafe work. Custom software cannot promise uptime, safety, lower cost, or profit.
Need an energy-software decision brief?
TTGC can map tasks, options, data, OT and IT paths, controls, pilot, cost, support, incidents, owners, and exit. Engineering, safety, legal, privacy, and security approval remain separate.
Sources
- U.S. Department of Energy: Cybersecurity Capability Maturity Model. https://www.energy.gov/ceser/cybersecurity-capability-maturity-model-c2m2
- National Institute of Standards and Technology: Cybersecurity Framework 2.0. https://www.nist.gov/cyberframework
- U.S. Cybersecurity and Infrastructure Security Agency: Secure by Design. https://www.cisa.gov/securebydesign
