Wildfire Mitigation and PSPS Software Problems: The 5 That Cost Real Money, and How to Avoid Them
The most expensive failure mode is a system that stores links to your decision inputs instead of the inputs themselves. Weather forecasts, fuel moisture and consequence model outputs change hourly, so a system that calls a vendor API later returns different data than the room saw. Six months on, when a post-event review or a discovery request lands, your team reconstructs the 3pm state of knowledge by hand from screenshots and call recordings. In our delivery experience that is weeks of senior engineering, meteorology and legal time per event, and it converts a defensible judgement into an undocumented one at exactly the moment documentation is worth the most.
Why does the scope creep from a decision record into a common operating picture so often?
The kickoff starts with the de-energization decision record and ends with a wall-sized map. Someone asks whether the system could also show camera feeds, then crew positions, then the vegetation backlog, then live fire perimeters. Within an hour the project is a common operating picture, which is a different product with a different budget and a different owner, and the artefact that actually carries your regulatory exposure has been demoted to a tab.
This happens more in wildfire than in most categories because the room is full of people who genuinely need situational awareness and are used to being told no. It also happens because the vendors here demo beautifully. Technosylva shows fire behaviour and consequence, camera networks such as Pano AI show an ignition the moment it starts, and a single screen with all of it is compelling in a way that a versioned snapshot of a wind forecast never will be.
The fix is a scope rule written before design starts. The first release captures decisions, executes notification obligations and gates restoration. It consumes situational awareness rather than producing it. Every map layer request is tested against one question: does this layer change a decision or an obligation. If it does not, it goes to phase two. Utilities that hold that line ship a usable first release inside four or five months. The ones that do not are still arguing about basemaps at month seven, with fire season approaching.
What goes wrong with snapshotting feeds and backfilling past events?
Two data problems bite, and quotes usually price neither. The first is snapshot volume. Capturing gridded forecasts, station observations, fuel moisture, your fire potential index and consequence model output at every ingestion, for every circuit in a fire threat area, produces a lot of immutable data with a long retention requirement, because litigation over an ignition can run for years. Teams that treat this as a nightly file drop discover at month four that they cannot query it, and rebuilding a queryable time series store mid-project is expensive.
The second is the connectivity model. Scope computation is only as good as your as-built backlog. If field changes take months to reach the geographic information system, your customer list is wrong at the edges, and the edges are where the medical baseline customer nobody notified lives. No software fixes an as-built backlog, but software can expose it. Flag every service point whose premise data is stale or unverified so the incident commander knows there is uncertainty about a few hundred customers, rather than being confidently wrong about all of them.
On backfill, be selective. Reconstructing every past event is rarely worth it because the source snapshots were never taken. Load the decision documents and notification logs you do have for the last two or three events, mark them clearly as imported rather than captured, and start clean from the next event.
Why do the integrations that matter here break after launch?
Four integrations carry this system and each fails in its own way. Weather and modelling vendors change response schemas, deprecate endpoints and apply rate limits that were generous in testing and tight during an actual wind event, which is when every consumer in your organisation is hitting them at once. The outage management and advanced distribution management systems sit behind a cybersecurity boundary, so the integration is not a connection but a negotiated data path with security review attached, and it breaks whenever either side is patched. The geographic information system changes as your network changes, which is continuous. The notification vendor throttles when you send to tens of thousands of customers, and throttling during a shutoff is a compliance problem, not an inconvenience.
The mistake in most quotes is treating these as one-time build items. They are ongoing obligations. What works is contract testing on every feed, running nightly against the live source, so a schema change is a failed test on a Tuesday rather than a blank field at 3pm during a red flag warning. Add a health board showing last successful ingestion per feed, and a documented degraded mode: if the fuel moisture feed is down, the decision record captures that fact and the room decides with a known gap rather than an unknown one.
What happens when the notification and restoration obligations are not covered?
This is where regulatory exposure concentrates. Regulators require tiered advance notice ahead of de-energization, notice at restoration, and additional care for medical baseline customers and customers with access and functional needs. A system that sends a campaign to an exported list can report what was sent. It cannot answer what was received, which numbers failed, which vulnerable customers were never reached, and who knocked on the door when automated contact failed.
The same gap appears at restoration. Re-energization is gated by patrol of the de-energized sections, because the wind that justified the shutoff may have put branches on conductors. If patrol lives on a spreadsheet and a radio, a missed section either stalls restoration or gets waived informally, and the second option is the one that ends careers.
Cover both properly or do not build. Notification becomes a per-customer obligation with a state machine: required notices derived from segment, attempts logged with channel and result, automatic escalation, and a field welfare check task when contact fails for a medical baseline customer. Restoration becomes span and section level patrol tasks derived from the same scope, with re-energization blocked at the device until every downstream section is cleared or waived by a named person with a recorded reason. Both produce the post-event report as a by-product rather than as a three week assembly job.
Should you build custom or configure what you already own?
Some utilities should configure. If you have no circuits in an elevated or extreme fire threat designation and no filed mitigation plan commitments, spend the money on inspection and vegetation work instead, and run notification through your existing mass notification vendor with a documented manual process. That is the honest answer and we give it regularly.
Even when you do build, buy most of the stack. Technosylva for fire behaviour and consequence modelling is doing science it would be irresponsible to rebuild. Your advanced distribution management system already models switching, so use it for device operations rather than duplicating the network model. Esri already holds your network geography. Your mass notification platform already handles delivery at volume across channels and languages. Keep all of it.
What you build is thin and specific: the decision record with versioned input snapshots, scope computed from the live connectivity model, the per-customer obligation ledger that drives your notification vendor and tracks its results, and the patrol and re-energization gate. If a vendor tells you their platform already does the decision record, ask to see how it stores a forecast and how it reproduces the state of knowledge at a given minute. The answer sorts the field quickly.
How do hidden costs get into the quote?
Five costs routinely arrive after signature. Snapshot retention and the time series storage behind it, which is a running cloud bill sized by feed count and retention period, not a line in the build. Operating in more than one state or country, because notification tiers, reporting formats and plan structures differ per regulator and each variant is its own rule set and test suite. The cybersecurity work around the operational technology boundary, which if any assets fall under North American Electric Reliability Corporation critical infrastructure protection obligations is real engineering with real review cycles.
The fourth is criteria. If your de-energization thresholds currently live as expert judgement rather than written rules, part of this project is helping you write them down. That is genuinely valuable and it is workshop time with your meteorology and operations leads, not development time, and it belongs in the plan.
The fifth is drills. A system used for the first time during a real wind event will fail, because nobody knows the flow under pressure. Budget two tabletop exercises before fire season, with the notification path exercised against a test segment. Ask any prospective developer to quote these five items explicitly. A quote that omits them is not cheaper, it is incomplete.
What separates a build that works from one that fails here?
Three things, consistently. First, the record generates rather than assembles. If any part of the post-event report still requires a person to gather screenshots, that part will be the part that is missing when it matters. Test the design by taking your last post-event report and marking which paragraphs the system would have produced automatically. The unmarked remainder is your real scope.
Second, the gate actually blocks. A system that warns about an uncleared section but lets re-energization proceed is a reporting tool. Operators will keep using radios and paper for the part that carries the risk, and you will have paid for a dashboard.
Third, one owner inside the utility. Wildfire programmes span meteorology, operations, vegetation, customer care, legal and regulatory affairs, and a system with six stakeholders and no owner drifts into the common operating picture problem within a month. Name a single accountable person before kickoff.
One more, which is contractual rather than technical: own the code, the repositories and every decision record and notification log in an open export format, agreed in writing before work starts. At Digital Heroes the client owns the code from the first commit. These records are evidence in proceedings that can run for years after an event, and holding them inside a platform you cannot fully export from is a risk no utility should accept.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Deloitte's research found that digitally advanced small businesses experienced revenue growth nearly 4x as high as the prior year, were about 3x as likely to have exported, were nearly 3x as likely to have created new jobs, and were more than 3x as likely to have seen more sales inquiries in the last year. Source: Deloitte (research summarized by Google) (2017) →
- Large companies globally have captured, on average, only 31% of the expected revenue lift and 25% of the expected cost savings from their digital and AI transformations - a significant gap between expected and realized value. Source: McKinsey & Company (2023) →
- 88% of customers say good customer service makes them more likely to purchase from a brand again in the future, quantifying the direct revenue link between support quality and retention. Source: HubSpot (2024) →
- In an RCT, the no-show rate was 23.5% for patients receiving a text-message reminder versus 38.1% for the control group - a 14.6 percentage-point reduction (p = 0.04). Source: Clinical Pediatrics / PubMed Central (Lin et al.) (2016) →
Eleanor leads client services across the UK and EU, which means she sits between what a client asks for and what the delivery teams can realistically build. She writes about scoping, budget conversations and the questions worth asking before a build starts.
View profile · Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.
Frequently asked questions
How do we store a weather forecast so a decision can be reproduced later?
Store the payload, not a link to it. Capture each feed as an immutable versioned snapshot at the moment of ingestion, with provenance and a timestamp, then have the decision record reference those snapshot identifiers alongside the criteria in effect and the participants. Calling the vendor API six months later returns different data, and a screenshot is partial and hard to authenticate. Budget for the storage and the retention period from day one, because litigation over an ignition can run for years.
Can our existing mass notification vendor handle PSPS obligations on its own?
It can deliver messages at volume across channels and languages, and you should keep it for that. What it cannot do is model a per-customer obligation: which notices this customer is owed given their segment, which attempts were made, which failed, and which medical baseline customers now need a field welfare check. Build that ledger yourself and drive the vendor from it, then write the vendor results back so the post-event report and the live unreached list both come from one place.
What breaks first when this system meets a real wind event?
Rate limits and throttling. Feeds that were generous in testing tighten when every consumer in your organisation hits them at once, and notification platforms throttle when you send to tens of thousands of customers in an hour. Test at event volume before fire season, agree limits with each vendor in writing, and design a documented degraded mode so a missing feed is recorded as a known gap in the decision record rather than silently absent.
How much of our as-built backlog do we need to clear before building?
None of it, and waiting for a clean connectivity model is how these projects never start. What matters is that the system exposes uncertainty instead of hiding it. Flag every service point with stale or unverified premise data so the incident commander knows there is doubt about a specific set of customers. Knowing you are unsure about three hundred customers is operationally useful. Being confidently wrong about all of them is what produces a notification finding.
Should the system compute de-energization scope or should the ADMS?
The advanced distribution management system owns device operations and the network model, and duplicating that is a mistake. Your build should read the live connectivity model and compute which customers fall out of a given device set, so the operational plan and the customer impact list are one artefact rather than two produced by two groups. That also lets the room compare alternative scopes side by side and see what opening a different device saves in customer count.
How long should a patrol and re-energization gate take to build?
It is a smaller piece than most people expect, usually a matter of weeks once the scope model exists, because the tasks derive from the same de-energization scope you already computed. The engineering is unremarkable: span and section tasks, offline capable field capture with photographs, and a hard block at the device until every downstream section is cleared or waived by a named person with a recorded reason. The difficulty is organisational, because the gate has to genuinely block.
Do we need a separate system if we operate in two states?
No, but you need the rules to be data rather than code. Notification tiers, timing, reporting formats and plan structures differ by regulator, so model jurisdiction as a first-class dimension on the obligation ledger and the report generator. Teams that hardcode one regulator and then add a second usually rewrite the notification engine. Expect a second jurisdiction to add meaningful cost and test surface even when the underlying operations are identical.
What should we ask a developer to prove before signing?
Hand them your last post-event report and ask which paragraphs their design would have generated automatically, then ask how they store a forecast and what blocks re-energization in their model. If nothing blocks it, they have built reporting. Also ask who owns the repositories and whether every decision record and notification log exports in an open format. Get ownership in writing before kickoff rather than at handover.
How much should a small business budget for its first custom app or website?
Should we build an MVP first or go straight to the full system?
How do I work out whether custom software will pay for itself?
What happens if I stop paying for maintenance after launch?
If an agency builds my software, who actually owns the code?
How small can the first version of my software be and still be worth building?
How do I make sure custom software is secure and compliant with rules like HIPAA?
How much should a small business expect to pay for custom software?
How do I vet a software development agency before signing a contract?
Will custom software work with the tools we already use, like QuickBooks and Stripe?
Who owns the code when an agency builds my software?
Who can build a custom software system?
Digital Heroes builds custom software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
