Continuity of Operations Software: Build or Buy for a COOP Programme?
Multiply your department count by essential functions per department, and let that number decide. Fifteen departments with three functions each is forty five nodes: keep a maintained document, run an honest annual exercise, and spend nothing.
On this page
Multiply your department count by essential functions per department, and let that number decide. Fifteen departments with three functions each is forty five nodes: keep a maintained document, run an honest annual exercise, and spend nothing. Sixty departments averaging five functions is three hundred nodes, each carrying dependencies, a recovery objective, a succession chain and a vital records list, and at that size a document cannot notice its own contradictions. Mid sized private organisations should buy Fusion or Castellan. The build case is large public bodies with statutory succession and vital records obligations.
When is off the shelf genuinely the right call here?
Do not buy anything if you are a single agency with fifteen staff and one alternate site. A maintained document plus an annual tabletop exercise is proportionate and honest, and a platform will not manufacture discipline you do not have. It will instead create currency work that falls on somebody who already has a full job.
Buy if you are a mid sized private organisation. Fusion Risk Management and Castellan are capable business continuity platforms with genuine dependency modelling, and your requirements are close to the ones they were designed around. You gain nothing from owning the code. Riskonnect is a reasonable choice where continuity is one module beside governance and risk in a suite you are already buying, and it is heavy if you are not. Veoci is flexible, and if your emergency managers already run other functions on it, doing the continuity work as configuration inside their environment is a sound path rather than a compromise.
There is also a version of this that no software fixes. If your plan is stale because departments do not respond to review requests, buying a platform gives you the same silence in a different format. The recurring cost that decides whether any of this was worthwhile is staff time: chasing departments, reviewing changes, closing gaps and facilitating exercises. That cost exists whether you build or buy. Software makes it visible and faster. It does not make it optional, and a programme that will not fund it should not fund a platform either.
When does a custom build actually pay off?
The build case in continuity of operations (COOP) is specific rather than general, and it belongs to large public organisations.
The first driver is commercial shape. Continuity touches every department, so a platform priced per user across a forty department county or a multi campus health system becomes a substantial recurring line for software most of those users open twice a year. The seats you decline to buy are the departments whose plans then go stale.
The second is that the constructs which are statutory for you are configuration for a corporate product. Orders of succession set by ordinance, delegations of authority with specific triggers and limits, devolution to a geographically separate site, and vital records defined by a records retention schedule are native to your obligations and are custom fields in a business continuity model. Custom fields do not carry validation, and validation is the point.
The third is binding to systems you already run. A succession chain that names a director who left in March is the failure that discredits a programme, and only a live personnel feed catches it the week it happens rather than at the annual review. The same applies to an application retired by the technology department, an alternate facility reassigned as a records annex, and a vendor whose contract lapsed.
The fourth is audit. If you have failed on plan currency, or if a real activation has already shown you the document was unusable at 3am, the argument is over. What you need is a graph that raises a validation error when an essential function with a four hour recovery objective depends on an application whose own objective is three days, because in a 214 page document those two facts sit ninety pages apart.
How do they compare on the things that matter in this industry?
- Contradiction detection. The plan asserts a dependency graph. Modelled as a graph, a recovery objective shorter than one of its dependencies is an error raised the moment it is created, along with a position with no named successor, an application with no owner and a vital record with no verified offsite copy. Written as narrative, none of those surface at all.
- Statutory constructs. Corporate platforms model business continuity well. Conditional succession written into ordinance, with triggers, limits and expiry, needs legal precision that a configuration field is not designed to hold.
- Live inventories. Personnel, facility, application and vendor feeds are the difference between a plan that decays visibly and one that decays silently. Configuration platforms are happiest when data is entered rather than derived, which is the opposite of what a currency problem needs.
- Per user economics. Read access for every manager across dozens of departments is where packaged pricing bites, and restricting access to a central team is how plans stop reflecting the departments they describe.
- Behaviour when the platform is down. A continuity system that depends on the infrastructure it is meant to help recover has failed at its only job. Ask what an automatically generated, current, offline usable export looks like, and test it the way you test a backup restoration.
- Exercise evidence. Auditors want observed recovery times, corrective actions, owners and closure, not a well written plan. Feeding observed times back into objectives is what turns an aspiration into a number.
What does total cost of ownership look like at your scale?
From Digital Heroes delivery experience, a structured plan of record runs $55,000 to $85,000: essential function register with criticality and recovery time objectives, orders of succession and delegation of authority with their triggers, alternate facility records, vital records inventory, department authoring with review and approval, and generation of the plan document in the format your governing body expects. A first release adding live personnel, application and facility feeds plus a currency dashboard runs $85,000 to $120,000 over ten to fourteen weeks. A full platform adding cross department dependency mapping, exercise design and after action tracking, activation mode, supplier dependency tracking and multi organisation structure runs $140,000 to $320,000 across six to eleven months.
A thirty department county with roughly four essential functions each, personnel and facility integrations and exercise tracking, without activation mode, lands near $115,000. Drop both inventory integrations and keep everything as maintained lists and the same county lands near $87,000, but you have given up the property that makes the plan trustworthy.
Phasing is unusual here. Around ten percent goes to discovery, fifty percent to build, fifteen percent to integration and a full quarter to department onboarding, which means sitting with each department and getting their functions and dependencies actually entered. No project in this category succeeds if that work is left to departments to do alone.
Maintenance runs 10 to 16 percent of build cost a year, and a meaningful share of it is keeping feeds alive through upgrades on the source side rather than adding features. Five years of direct ownership on the county example lands near $210,000 to $230,000, plus at least one significant remap after a reorganisation, which happens far more predictably than the outages the plan exists to survive.
What does the hybrid look like, and when is it the honest answer?
The hybrid here is about how much you bind, not about which vendor you keep, and it is where most of the money is saved or wasted.
Take one personnel integration and leave everything else as maintained lists. The succession chain naming a departed director is the failure that embarrasses a programme in front of elected officials, and one feed prevents it. Facility and application inventories can stay as lists for another year without discrediting anything, and if your application inventory is a spreadsheet last touched in a previous administration, binding to it means running an inventory project inside a continuity project. Better to admit that at the start than discover it in week six.
Defer activation mode. Turning a plan into a live operational checklist with role assignment and status during a real outage is close to a second application, and an organisation that has never activated does not yet know what it needs on that screen. Ship the plan of record and the currency dashboard, then design activation from what your first real outage or full scale exercise actually revealed.
Publish rather than provision. A generated plan document distributed on a schedule covers most of the governance need at a fraction of the cost of interactive access for every manager, and it doubles as the offline copy that has to exist anyway.
Standardise the departmental template before you build. Every variation you allow becomes a branch in the authoring flow, and that argument is political rather than technical, so it costs nothing but resolve and buys a cheaper system.
Which should you choose, by operator size and stage?
Single agencies under about twenty staff, one alternate site, a plan under fifty pages: buy nothing. Maintain the document, run one honest tabletop a year, and put the effort into vital records restoration testing, which is where the real gap usually sits.
Mid sized private organisations: buy Fusion or Castellan. Your requirements match what they were built for, and owning the code buys you nothing you can use.
Organisations already running Veoci for emergency management: configure continuity inside it before considering anything else. Consolidation on a platform your emergency managers already open during an incident is worth more than a better data model nobody has logged into.
Counties, cities and agencies with twenty to forty departments and statutory succession obligations: build the structured plan of record plus one personnel feed. That is the $85,000 to $120,000 band, it ships in ten to fourteen weeks, and it fixes the failure that actually gets programmes criticised.
State agencies, university systems and multi campus health systems above roughly fifty departments: build the full platform, but sequence activation mode last and budget a quarter of the effort for department onboarding. Three hundred functions entered badly is worse than a hundred entered properly.
Anyone who has failed an audit on plan currency, or activated for real and found the document unusable: build, and start by tracing your three most critical essential functions to a live system of record. If any link in those three chains cannot be verified today, that is the project.
If you would rather someone argued with your brief than agreed with it, Digital Heroes starts every engagement with a signed specification covering the data model, permissions and acceptance criteria, which is what keeps a fixed price fixed. Nothing about that commits you to the build.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- SaaS spend averaged $4,830 per employee (up 21.9% year over year), with large enterprises (10,000+ employees) spending roughly $284M annually and running about 660 apps, while organizations wasted an average of $21M annually on unused licenses. Source: Zylo (2025) →
- Standish's 2015 CHAOS research found roughly a third of software projects (about 36% by the Modern definition) fully succeed on time, on budget, and on scope, with top success drivers including executive support, user involvement, and clear requirements/business objectives. Source: Standish Group (CHAOS Report) (2015) →
- Poor software quality cost the US economy an estimated $2.41 trillion in 2022, including roughly $1.52 trillion in accumulated technical debt, driven partly by unsuccessful development projects and low-quality legacy systems. Source: Consortium for Information & Software Quality (CISQ) - Herb Krasner (2022) →
- A later Nucleus Research review of analytics software ROI case studies found customers received $9.01 in benefits for every dollar spent on analytics technology, showing returns vary with deployment factors but remain strongly positive. Source: Nucleus Research (2019) →
Frequently asked questions
If we build, what does it cost to move off a commercial continuity platform?
Less than most migrations, because the valuable content is text and structure rather than transactional history. Essential functions, dependencies, succession chains and vital records lists export reasonably from any competent platform.
What does not migrate is the reason you are leaving: the mapping between their model and your statutory constructs, which currently lives in custom fields and in a continuity manager's head. Plan to re enter those deliberately during department onboarding rather than importing them, because importing a compromise preserves it.
What happens when a continuity platform changes its per user pricing?
Per user pricing is the specific pressure point in this category, because continuity touches every department while most of those users open the system twice a year. A repricing forces a choice between paying for seats you barely use and restricting access to a central team, and the second option is how plans stop reflecting the departments they describe.
Model it against your department count rather than your headcount. A build has no per user economics, which is why the comparison changes at forty departments and again at sixty.
How long does it take to build and populate a continuity platform?
Ten to fourteen weeks for a first release and six to eleven months for a full platform, but the schedule that matters is department onboarding rather than engineering.
Around a quarter of the effort goes to sitting with each department and getting their functions and dependencies entered properly. Projects that hand that work to departments to complete alone produce a populated database of guesses, which is more dangerous than a document because it looks authoritative.
Is Fusion Risk Management enough for a government agency?
It is a capable platform with real dependency modelling and a sound choice for a mid sized private organisation. Public buyers hit two walls rather than a quality problem.
The first is per user pricing across dozens of departments. The second is that orders of succession set by ordinance, delegations of authority with specific triggers and limits, devolution and vital records defined by a retention schedule are configured in as custom fields rather than being native, and custom fields do not validate. If those constructs are statutory for you, that gap does not close.
Are the personnel and facility integrations worth the extra cost?
The personnel feed is, and it is the reason to build rather than maintain a document. A succession chain naming someone who left in March is the failure that discredits a programme, and only a live feed catches it in the week it happens.
Facility and application feeds are worth deferring if budget forces a choice. If your application inventory is a spreadsheet nobody has touched in years, binding to it means running an inventory project inside your continuity project, and it is better to say so at the start than to find out in week six.
What happens if the continuity system itself is down during an outage?
That is the first question to ask any developer or vendor. The answer must be an automatically generated, current, offline usable export of every plan, held somewhere independent of the infrastructure it is meant to help recover.
A platform that depends on the file services it is planning around has failed at its only real job, and the printed copy in a desk drawer from two years ago is not a substitute. Test the export the same way you test a backup restoration, on a schedule, and record the result.
Should activation mode be in the first release?
Usually not. Turning a plan into a live operational checklist with role assignment and status during a real outage is close to a second application, and organisations that have never activated do not yet know what they need on that screen.
Ship the plan of record and the currency dashboard first, then design activation from what your first real outage or full scale exercise actually revealed. Organisations that have been through an activation always add delegation of authority as an operational rule rather than a paragraph, and that is the detail worth waiting to get right.
What are the ongoing costs, and what gets missed?
Maintenance runs 10 to 16 percent of build cost a year, much of it keeping personnel, property and configuration feeds alive through upgrades on the source side. Hosting is modest, in the low thousands.
Two costs get missed. Plan currency work is staff time chasing departments, reviewing changes and closing gaps every year, and it is the largest recurring cost of any continuity programme whether or not you buy software. And a reorganisation invalidates function ownership, succession chains and dependency links across whole branches at once, so budget at least one significant remap across five years.
How many people should be working on my software project?
Three to five for a typical focused build: a project lead, one or two engineers, a designer, and part-time QA, which is the standard shape across 2,000+ Digital Heroes projects. Larger platforms justify 6 to 10, but a ten-person team on a small first version usually signals bill padding rather than horsepower. What predicts success is whether a senior engineer is writing your code daily, not the headcount on the proposal.
Should we build our internal tool in Retool instead of hiring developers?
Retool is the right choice if someone on your team is comfortable with SQL and JavaScript and the audience is a handful of technical users, because a basic CRUD dashboard comes together in days. Hire developers when non-technical staff will use the tool daily, when the logic goes beyond forms sitting on a database, or when per-seat pricing stings, since Retool's Business tier lists at $50 per standard user per month. A pattern Digital Heroes sees often: companies arrive after a year on Retool with a tool nobody can maintain because the one person who built it has left.
We run everything on spreadsheets and Airtable. How do we know it's time for custom software?
The reliable signals are re-typing the same data into multiple tools, one employee acting as human middleware between systems, and errors appearing in handoffs between teams. Hard limits force the issue too: Airtable's Team plan caps at 50,000 records per base, and Business costs $45 per seat per month, so a 20-person team pays about $10,800 a year for a tool it has already outgrown. When workarounds consume more hours than the tools save, the spreadsheet era is over.
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.
What does an internal tool cost for a small business with 20 to 50 employees?
Plan on $5,000 to $15,000 for a focused tool that replaces one painful spreadsheet workflow, such as job scheduling, quoting, or PTO tracking. In Digital Heroes projects at this size, the sweet spot is one core workflow, two or three user roles, and a single integration, usually QuickBooks or Google Workspace. Quotes far below $5,000 usually mean a template with your logo on it rather than software built around your process.
How do I vet a development agency for an internal tools project?
Ask to see two or three internal tools they have shipped and whether those clients still use them daily, because internal tools fail on adoption, not code quality. Good signs: they ask to see your current spreadsheet or process before quoting, they propose a phased build instead of one big launch, and they spell out who handles training and post-launch changes. Walk away from anyone who gives a fixed price before seeing your actual workflow, since internal tools live or die on process details.
Can a custom internal tool connect to QuickBooks, Salesforce, and the other software we already use?
Yes, and integrations are usually the strongest argument for going custom instead of chaining tools together with Zapier. QuickBooks, Salesforce, Shopify, Stripe, Slack, and Google Workspace all have mature APIs, and each integration typically adds $1,500 to $5,000 to a Digital Heroes build depending on how much two-way syncing you need. The honest caveat is legacy industry software without an API, which may need file-based imports instead of a live connection, so list every system in the first conversation.
Will an app built for 10 users survive growing to 500?
Yes, if it is built on standard cloud infrastructure with a sound data model, because moving from 10 to 500 users is a hosting configuration change, not a rebuild. The scaling decisions that actually hurt are made early and invisibly: how the database is structured, how accounts and permissions are modeled, and whether background work is queued properly. Ask your agency how the system would handle ten times the load; the right answer is boring and specific, and a promise to cross that bridge later means you will pay for the bridge twice.
How many developers does it take to build an internal tool?
Two to four people covers nearly every internal tool: one or two developers, a part-time designer, and a project manager who doubles as your single point of contact. Internal tools rarely need consumer-product polish, so a full-time dedicated designer is usually wasted budget. On Digital Heroes projects, a two-person core team handles the typical 4 to 8 week build, with a specialist pulled in briefly for a tricky integration or a security review.
What tech stack should an internal tool be built with?
Boring and popular: a React or Next.js frontend, a Node.js or Python backend, and PostgreSQL covers the vast majority of internal tools and keeps future hiring easy. The stack matters far less than whether a different developer can pick the code up in two years, so require documentation as a deliverable and avoid anything exotic. Treat it as a red flag if an agency pushes a proprietary platform only they maintain, because that quietly converts your tool into a subscription to that agency.
What should I prepare before contacting an agency about an internal tool?
Bring the spreadsheet or document you run the process on today, a list of everyone who touches the workflow and what each person does, and one sentence describing the outcome you want. You do not need wireframes or a technical spec; a 30-minute screen-share of the current process beats a 20-page requirements document. Decide your rough budget band and name a single internal decision-maker, because projects without one take noticeably longer in Digital Heroes experience.
Who can build a custom internal tools system?
Digital Heroes builds custom internal tools 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 internal tools 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 Riley.
Content Strategist · APAC · Sydney · 2 posts on the site
Published · Last updated .
