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. It may set up a product, link approved tools, or build software. Custom code is not the first choice by default. Expert reviews of the system, safety, law, data, and security stay in charge of their own calls.
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, and missed alerts. Track 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, and users. Name the market, systems, data, and safety impact. Map SCADA or other control systems. Map outage tools, asset work, and advanced metering. Map customer records and billing, market systems, maps, and reporting when they apply. Keep read-only reporting on a risk path apart from live field or plant control.
- Draw the OT and IT zones and the trust boundaries. Draw data flows, remote links, vendors, and manual fallbacks.
List every command path and block any path the product does not need.
- Give a named review role to operations, engineering, safety, and security. Do the same for legal, data, buying, and field staff.
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, and utility type. They also vary by 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, and test. Link it to the proof, review date, and exception path.
- Cover identity and least privilege. Cover logging, change control, and patching. Cover backup, restore, and incident response. Cover vendor access too.
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, and offline work. They can also cover recovery, data ownership, and control lines. Score fit, time, full cost, and support. Then score scale, data control, and exit. Do this 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, and links. Price test labs and training. Price 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, and logs. Check 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, and labs. Count 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, and bad time stamps. Include 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. Allow a narrow path only if the approved design needs one.
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 beside outage records. Those reports come from the customer system. A read-only link may meet the need with less risk. Replacing either system would cost more risk. The team tests one district with fake and approved old cases. It checks record match, event time, delay, and duplicate reports. It also checks role access, phone use, outage mode, and restore. All write-back is blocked. The pilot stops for lost events, wrong premises, or missed safety notes. It also stops for 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, and safety roles with real tasks. Train security, data, and help-desk roles the same way.
- Plan the old and new paths, staff notice, and local support. Plan 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, and data. Map the plant and IT paths, the vendors, and the 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
