Wildfire Mitigation Management Software: Build vs Buy for a Utility
Buy the science and build the record. Technosylva, Pano AI, AiDash and Overstory are doing modelling and detection work no utility should attempt in-house, and your build should consume them.
On this page
Buy the science and build the record. Technosylva, Pano AI, AiDash and Overstory are doing modelling and detection work no utility should attempt in-house, and your build should consume them. What no vendor ships is the decision record, the per-customer notification obligation and the re-energization gate, because those are shaped by your filed mitigation plan and your regulator.
What the off-the-shelf products actually do well
The first thing to say is that the vendor landscape in this category is genuinely strong, and a utility with no circuits in an elevated or extreme fire threat designation and no filed plan commitments should buy nothing at all. Some utilities in low risk geographies are pushed toward wildfire tooling by vendors and by board anxiety. Spend it on inspection and vegetation instead.
Where the risk is real, the specialists earn their money. Technosylva models fire behaviour and consequence at a level no utility should try to reproduce, and it is embedded in operational decision making at several large operators for good reason. Pano AI detects ignitions from camera networks and shortens the interval between a start and a confirmed location. AiDash and Overstory score vegetation risk from remote sensing across a service territory faster than any patrol programme. Esri ArcGIS holds your network geometry. Notification platforms deliver messages at volume with carrier relationships you would not want to negotiate.
Each of those is a feed or a channel, and each is worth what it costs. There is no honest argument for rebuilding fire behaviour modelling, camera detection or message delivery. If a firm offers to, walk.
What none of them is, and none of them can be, is the decision record, the notification obligation, the patrol evidence chain or the re-energization gate. Those are shaped by your filed plan and your regulator's rules, and they change when the plan is revised.
Where they stop: the decision is judged twice and the second time is harder
Three in the afternoon, one day out. Gusts forecast over threshold across a set of circuits in an extreme fire threat area, fuel moisture low. Operations, meteorology, vegetation and the incident commander are on a call. Somebody shares a model output. Somebody else has a spreadsheet of circuit segments and customer counts. A decision is made, and it is usually a defensible one, because the people in that room are good at this.
Then the second judgement starts. De-energize and you have taken power from thousands of customers, some on medical equipment, and you will explain that to a regulator and possibly a legislature. Do not de-energize and if a fire starts you will explain it to a court. Both ask the same question: what did you know at the time, what did your own criteria say, and can you show it.
The answer at most utilities is a folder of screenshots, a call recording and the memory of the people on the call. The inputs were a dozen data sets that all change hourly, and the snapshot they were judged against evaporated. Reconstruct it six months later from a vendor's current interface and you are looking at the wrong data.
The second stopping point is notification. Under the tiered advance notice expectations set by the California Public Utilities Commission in Decision 19-05-042, and under equivalent rules elsewhere, you owe notice ahead of de-energization and again at restoration, with additional care for medical baseline customers and customers with access and functional needs. The usual architecture is a notification vendor driven from a list exported under time pressure. That cannot close the loop. It reports what was sent. Regulators increasingly want to know what was received, and what happened when it was not.
The third is the restoration gate. Re-energizing requires patrolling de-energized circuits, which takes daylight and crews, and in most utilities it is coordinated over radio and a spreadsheet. That is the least systematised part of the whole event and the one where a missed section ends careers.
The arithmetic: per-customer licences against the cost to build
There are two ways to run this and you should run both.
The licence view first. Add your notification platform, your event management tool, any wildfire dashboard and the reporting add-ons, then divide by customers in Tier 2 and Tier 3 areas. A first release at $160,000, plus year two at 18 percent, is roughly $189,000 across two years, or about $7,875 a month. At $1.20 per customer record per year for notification and event management together, that breaks even near 79,000 customers in scope. Most utilities carrying real fire risk are below that, so licences alone will not decide it.
The event view is the one that does. Time the last post-event report honestly, across every department that contributed. In the utilities we have looked at, assembling one runs into several hundred staff hours spread over weeks, and the regulator's window for that submission is short, commonly ten business days in California. Two events a year at that cost is a recurring six figure line that nobody has ever booked as software spend, because it is paid in overtime and delayed work elsewhere.
Then add the exposure you cannot price and should not pretend to. We will not put a number on litigation. What we will say is that a documented decision with versioned inputs is a different position from a defensible judgement nobody can reconstruct, and your legal group already knows which one you have.
What a custom build actually costs
Bands from Digital Heroes delivery experience for a utility with a filed mitigation plan.
- First release. The decision record with versioned input snapshots, scope computation from the connectivity model, and notification execution with per-customer obligation tracking. $100,000 to $220,000 in 14 to 20 weeks.
- Full platform. Adds patrol assignment and re-energization gating, medical baseline escalation to field welfare checks, mitigation plan metric tracking and post-event reporting in your regulator's format. $250,000 to $600,000 phased over 9 to 15 months.
Data migration runs 10 to 25 percent of the build, and here it is mostly reconciliation rather than movement. Customer premise attributes, medical baseline flags, access and functional needs designations and language preferences have to be joined to service points that the connectivity model can actually resolve. Where your as-built backlog is months deep, the customer list is wrong at the edges, and the edges are where the customer you failed to notify lives. Flagging that uncertainty is part of the work.
Year two and after runs 15 to 20 percent of build cost annually. Plan revisions change your metrics. External feeds change formats. Regulator report layouts change more often than the underlying rules. Each is small and each is unavoidable.
The four situations where building wins
In this category, unusually, one of these is enough.
- Regulatory fit. You have filed a wildfire mitigation plan under Public Utilities Code section 8386 with the Office of Energy Infrastructure Safety, or an equivalent plan in another state, committing you to targets on covered conductor miles, structures hardened, inspections completed under General Order 165 cycles and protection settings by risk tier. Those metrics are negotiated in your plan, so no product ships them and they change at each revision.
- Scale economics. You are past the customer crossover above, or you run two or more events a year and pay for each post-event report in overtime.
- A workflow that is your competitive advantage. For a regulated utility read that as the thing you are judged on: scoping precision. Better segmentation is a capital programme, but better use of the segmentation you already own is a software problem, and de-energizing 4,000 more customers than necessary is a political cost paid every event.
- Integration sprawl across three or more systems. Weather and fire modelling feeds, a camera detection network, vegetation scoring, the outage management system, supervisory control and your customer information system. Five sources inform one decision and none of them holds the record of that decision.
How to decide in a week, then buy a written specification
One week, and it is really one exercise.
Take the post-event report from your last event and hand it to your own team with a single question: which parts of this could have been generated automatically from records that existed at the time. Then work backwards through it. Monday, try to reproduce the 3pm forecast and fuel moisture that informed the decision. Tuesday, produce the list of medical baseline customers in scope who received nothing. Wednesday, produce the patrol sign-off chain by section. Thursday, produce plan metric progress with the individual work records attached. Friday, add the licence figures.
If all four come back inside a day with source records, you have a mature programme and should spend on inspection instead. That outcome is rare and it is worth knowing.
If the week says build, the next step is a paid discovery phase rather than a proposal. Digital Heroes runs discovery to a signed product requirements document covering the snapshot model, the notification state machine, the re-energization gate and acceptance criteria, and you keep that document whichever firm builds from it. We contract through an India LLP, a US LLC or a UK LTD so intellectual property assigns under your own law, we run our own products including Section Vault, and you meet the named engineers before signing. Clutch, Trustpilot, Fiverr Vetted Pro and D-U-N-S are all checkable.
We are the wrong firm if you want a control path through an application. Anything built against your operational network is read only, and the escalation rules for no water, discoloured water or a suspected ignition get written down and signed before any code is written.
Book a 30-minute call with Digital Heroes and get a written plan and a fixed quote within 48 hours.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- The average developer spends more than 17 hours a week dealing with maintenance issues such as debugging and refactoring, and about four of those hours on 'bad code' - waste that equates to nearly $85 billion annually worldwide in opportunity cost. Source: Stripe (2018) →
- Per the Standish Group CHAOS 2020 report (reviewed at this URL), across tens of thousands of software projects roughly 31% end successfully, about 50% are 'challenged', and roughly 19% fail outright; small projects succeed far more often than large ones, and Agile approaches succeed at markedly higher rates than Waterfall. Source: The Standish Group (2020) →
- The average number of formal learning hours used per employee fell to 13.7 in 2024, down from 17.4 in 2023, a decline the report attributes partly to a shift toward informal and on-the-job learning not captured in the formal-hours metric. Source: Association for Talent Development (ATD) (2025) →
- Gartner estimates RPA can eliminate up to 25,000 hours of avoidable rework caused by human errors in the finance function each year, equating to savings of roughly $878,000 for an organization with 40 full-time accounting staff (based on interviews with more than 150 corporate controllers and chief accounting officers). Source: Gartner (2019) →
Frequently asked questions
How long before a decision record is usable in a live event?
Fourteen to twenty weeks for a first release covering versioned input snapshots, scope computation and per-customer notification tracking. Aim to have it running before your next elevated fire season rather than during one. The snapshot capture can go live earlier than the rest, because storing feeds as dated observations is independent of the decision workflow that consumes them and starts building history immediately.
Who owns the decision records and notification logs if an agency builds this?
You do, and it belongs in the contract at signing, including export of every decision record and notification log in an open format. These records may be produced in litigation or in a regulatory review years later, and a record you cannot reach without a vendor's cooperation is not a record you control. Digital Heroes assigns ownership at the first commit under an India LLP, US LLC or UK LTD contract.
How should a weather forecast used in a decision be stored?
As a snapshot at the moment of ingestion, with provenance, not as a link to the source. If reconstructing a past decision means calling a vendor interface again, you will retrieve the current data rather than what your team saw at three in the afternoon. This is the sharpest test to put to any candidate developer, because the value is the snapshot rather than the data itself.
What is the difference between fire modelling and a decision record?
Fire modelling estimates behaviour and consequence if an ignition occurs, and specialists do it better than any utility could. A decision record captures which model output, which forecast, which criteria and which participants produced a specific choice on a specific afternoon, along with the resulting scope and any dissent. One is an input. The other is the artefact a regulator and a court will actually examine.
Can we tell which customers never received a notification?
Only if notification is modelled as a per-customer obligation with a state machine rather than as a broadcast to a list. Each customer in scope has a required notice set derived from their segment, attempts logged with channel and result, automatic escalation to the next channel and then to a field welfare check where contact failed. That also produces a live ranked list of unreached vulnerable customers during the event.
How much does a wildfire platform cost to maintain each year?
Fifteen to twenty percent of build cost annually. Plan revisions change the metrics you track, external feeds change formats, and regulator report layouts change more often than the rules behind them. None of those items is large on its own. Skipping the budget means the metric definitions drift away from your current filing, which is the specific failure that makes the whole system untrustworthy at review time.
Should a utility with little wildfire risk build any of this?
No. If you have no circuits in an elevated or extreme fire threat designation and no filed plan commitments, put the money into inspection cycles and vegetation work, which reduce risk directly. Revisit only if your regulator extends plan requirements to your territory or if your risk map is redrawn. Board anxiety is a real pressure and it is not the same as a regulatory obligation.
How do we track plan commitments that span six departments?
Define them as configurable measures over operational data you already generate, so progress is continuous and drills down to individual work records. Tracking them as a quarterly spreadsheet assembled from six sources means you learn your position a quarter in arrears, which is exactly when correction is no longer possible. When the plan is revised the measures get reconfigured rather than rebuilt from scratch.
What should block re-energization in a well designed system?
The patrol result, at the device. Derive a span and section level task set from the same de-energization scope, assign it to crews on devices, capture findings with photographs in the field, and block the device until every downstream section is cleared or explicitly waived by a named person with a recorded reason. If nothing blocks re-energization, you have built a reporting tool and crews will keep using radios.
What should we ask a developer before signing a wildfire contract?
Hand them the post-event report from your last event and ask which parts their system would have generated automatically. The gap between their answer and the whole document is the size of the project, and it is a far better test than any feature discussion. Then ask what blocks re-energization in their design, and treat an answer of nothing as disqualifying.
Can we migrate years of data out of our current system into new custom software?
Almost always yes, through CSV exports or the vendor's API, and migration should be scoped as its own workstream with field mapping, a dry run, and a planned cutover window rather than an afterthought. The real time sink is rarely moving the data; it is cleaning it, since years of duplicates, free-text fields, and inconsistent formats surface all at once. Pull a full export from your current vendor before committing to anything new, because some SaaS plans restrict exports on lower tiers.
We run everything on Airtable and spreadsheets. When is it time to go custom?
The switch usually makes sense when you hit one of two walls: Airtable's record caps (125,000 records per base on the Business plan) or logic the tool cannot express, like multi-step approvals with conditional pricing. There is also a simple cost signal: 25 people on Business at roughly $45 per seat per month is about $13,500 a year, forever, for a tool you are already fighting. Custom is worth it when the workflow is core to how you make money; for peripheral processes, staying on Airtable is the right call.
How long does it take from first call to software my team can actually use?
Plan for four to six months: two to three weeks of discovery, two to four weeks of design, then a 10 to 16 week build with testing. In Digital Heroes delivery experience the schedule killer is not engineering speed but decision lag; a client who takes two weeks to approve wireframes adds two weeks to launch. Book a weekly 30-minute decision slot before kickoff and most of that risk disappears.
Can custom software connect to the tools we already use, like QuickBooks, Stripe, and Google Workspace?
Yes, and connecting your existing tools is one of the main reasons to build custom: mainstream platforms like QuickBooks, Stripe, Shopify, and Google Workspace all publish documented APIs. Budget 1 to 3 weeks of work per integration depending on API quality and how much data flows in both directions. Ask any vendor whether they have integrated with your specific tools before, because quirks like QuickBooks' OAuth token handling and API rate limits get learned on someone's project, and it should not be yours.
How many SaaS seats do we need before building custom becomes cheaper?
The crossover usually shows up between 20 and 50 seats on premium tiers. Salesforce Enterprise lists at $165 per user per month, so 40 users cost about $79,000 a year in subscriptions, which is real money against a custom system you would own outright. Run the comparison over three years: if subscription spend beats the build cost plus 15-20% annual maintenance, custom wins on price before you even count workflow fit.
Will custom software work with the tools we already use, like QuickBooks and Stripe?
Yes, and this is one of custom software's genuine advantages: QuickBooks, Stripe, Shopify, and most mainstream business tools publish documented APIs built for exactly this. Expect each standard integration to add one to two weeks of build time, and be suspicious of any quote that lists five integrations without asking what data flows in which direction. The hard cases are legacy systems with no API, which is a question to raise in discovery, not in week nine.
How much should a small business expect to pay for custom software?
Across 2,000+ Digital Heroes projects, a small business system that replaces spreadsheets or one core workflow typically lands between $40,000 and $80,000, with more complex first versions running up to $150,000. The two levers that move the number most are integrations and user roles, not the team's hourly rate. Any quote under $15,000 for a full production system means the vendor has not understood your scope yet.
How do I calculate whether custom software will pay for itself?
Divide the build cost by the monthly benefit, where benefit is hours saved times loaded hourly cost, plus subscription fees replaced, plus any revenue the software unlocks. Three staff saving 10 hours a week each at a $40 loaded rate is about $62,000 a year, which pays back a $60,000 build in roughly 12 months. Across Digital Heroes internal-tool projects, 12 to 24 months is the normal payback range, and anything projecting under 6 months usually means the spreadsheet is hiding costs.
Does the tech stack matter, and which one should I ask for?
It matters less than agencies imply, provided it is boring. A mainstream stack, something like React or Next.js on the front end, Node.js or Python behind it, and PostgreSQL for data, means thousands of developers can maintain your system if you ever change vendors. Apply one test: ask how hard it would be to hire a replacement developer for the proposed stack, and walk away from anything built on an agency's in-house framework.
How do I work out whether custom software will pay for itself?
Do the arithmetic on hours before anything else: if the system saves three staff eight hours a week at a $35 loaded hourly cost, that is about $43,700 a year against, say, a $70,000 build plus 15 to 20% annual maintenance, a payback around two years. Add revenue effects only if you can name them specifically, like faster quotes or fewer abandoned orders, not as vague growth. In our delivery experience the businesses that see payback inside 24 months are the ones automating a process they already measure.
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.
Related guides
More from Theo.
UX Researcher · UK · London · 2 posts on the site
Published · Last updated .
