Skip to content

Instantly share code, notes, and snippets.

@kevinmichaelchen

kevinmichaelchen/firehouse-saas-research-and-architecture.md Secret

Last active July 31, 2026 02:05
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save kevinmichaelchen/824b8d790e35fca4816dbc27b448f0d6 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save kevinmichaelchen/824b8d790e35fca4816dbc27b448f0d6 to your computer and use it in GitHub Desktop.
Download ZIP
Firehouse SaaS market research and Cloudflare architecture proposal
Raw
firehouse-saas-research-and-architecture.md

Firehouse SaaS: Market Research and Architecture Proposal

Research date: July 30, 2026
Status: Working research and product architecture—not a finished essay

Executive assessment

The fire-department software market presents a compelling public-interest problem and a credible narrow software opportunity. It is not an attractive market for a startup attempting to replace CAD, RMS, ePCR, inspections, scheduling, and asset management at once.

The strongest opening is a vendor-neutral NERIS migration, data-quality, interoperability, and portability layer for small, volunteer, and combination departments.

The 2026 NFIRS-to-NERIS transition created a synchronized migration event. At the same time, prominent fire/EMS software suppliers have attracted private-equity or growth-equity investment and expanded through acquisitions. The resulting problem is not simply private equity: it is the combination of mandatory reporting, proprietary integrations, long-lived public records, fragmented procurement, and weak exit rights.

Problem statement

Small and midsize fire departments must submit compliant incident data while preserving historical records and connecting heterogeneous CAD, RMS, EMS, and municipal systems.

They frequently have:

  • limited IT staff and implementation capacity;
  • decades of incident, training, inspection, equipment, and personnel data;
  • vendor-specific exports and integration fees;
  • public procurement and records-retention obligations;
  • low individual software budgets despite enterprise-grade reliability needs;
  • new NERIS mappings and validation requirements.

The failure modes include duplicate entry, rejected or incomplete submissions, opaque migration costs, inaccessible historical records, and costly dependency on a single suite vendor.

Market shape

  • The USFA registered 27,166 departments in January 2024 and estimated that registry coverage represented about 92% of U.S. departments.
  • The market is heavily fragmented at the department level and includes many small and volunteer organizations.
  • Procurement may occur at the department, district, county, regional, or state level.
  • Prominent vendors include ESO, ImageTrend, First Due, CentralSquare, Tyler, Motorola, Hexagon, and Versaterm.
  • ESO acquired Emergency Reporting in 2021; the target reported serving 7,500 North American fire/EMS agencies and 170 military installations.
  • ImageTrend reported nearly 3,000 customers across more than 40 states when announcing its Welsh Carson investment.
  • First Due reported growth from hundreds of agencies in 2021 to more than 3,000 customers by its 2025 investment announcement.

Customer counts are not directly additive: they include overlapping fire, EMS, hospital, state, and other public-safety customers.

Why now

  • Only NERIS accepts calendar-year 2026 incident data.
  • NFIRS became unavailable after January 31, 2026.
  • Departments have been forced to revisit schemas, exports, historical archives, and submission workflows.
  • Suite-vendor consolidation can turn mandatory migration into a bundling or upsell event.
  • Modern APIs and standardized reporting may make a neutral adapter layer more feasible.
  • Public concern about data access, renewal pricing, and emergency-services consolidation creates a stronger portability narrative.

By mid-2026, the opportunity is no longer merely “prepare for the deadline.” It is remediation, validation quality, interoperability, historical continuity, and future exit safety.

Recommended product wedge

NERIS readiness and data-quality gateway

Inputs:

  • CAD and RMS exports;
  • legacy NFIRS archives;
  • spreadsheets and local databases;
  • vendor APIs where contractually available.

Outputs:

  • normalized incident records;
  • NERIS field mapping;
  • validation and completeness reports;
  • rejection diagnosis and repair workflow;
  • human-approved submission;
  • durable audit history;
  • open export and offboarding bundle.

Initial non-goals:

  • no CAD replacement;
  • no ePCR or patient-care records;
  • no claim to be the operational system of record;
  • no autonomous final incident submission;
  • no all-in-one firehouse suite.

Defensibility

The durable assets would be:

  • a cross-vendor connector library;
  • accumulated mapping and validation rules;
  • state and local implementation knowledge;
  • a corpus of common rejection and migration failures;
  • repeatable migration playbooks;
  • trusted export, provenance, and audit tooling;
  • procurement language guaranteeing machine-readable exit.

A successful point feature can be bundled by incumbents. Cross-vendor portability and accumulated implementation knowledge are harder to reproduce.

Buyer and go-to-market

Potential economic buyers:

  • fire chief or district chief;
  • county fire coordinator;
  • city/county CIO;
  • state fire marshal or reporting office.

Likely users and stakeholders:

  • records officers;
  • fire marshals;
  • training officers;
  • dispatch authorities;
  • procurement and finance;
  • municipal IT;
  • volunteers and line personnel.

A direct nationwide SMB sales motion may be uneconomic. Better distribution paths include:

  • county or regional deployments;
  • state fire associations;
  • cooperative purchasing;
  • implementation partners;
  • state reporting offices;
  • grants or risk-pool programs.

Primary risks and falsification tests

  • NERIS may provide enough free migration and validation tooling.
  • Dominant vendors may include acceptable migration support.
  • Departments may lack contractual permission to expose data to a neutral service.
  • Connector maintenance may cost more than attainable subscription revenue.
  • Agencies may prefer bundled operational simplicity.
  • State aggregators, rather than departments, may control the relevant workflow.
  • Procurement and security review may make customer acquisition too slow.

Before building broadly, verify NERIS third-party API access, current agency migration status, vendor export terms, willingness to pay, and support hours per connector.

Recommended Cloudflare architecture

Architecture thesis

Use Cloudflare as a secure ingestion and orchestration plane. Keep a mature external Postgres database as the single relational source of truth. Optimize for auditability, recoverability, data portability, and controlled failure—not novelty.

flowchart LR
    Agency["Department users"] --> Edge["WAF + application Worker"]
    Systems["CAD / RMS exports"] --> Connector["Upload or optional Cloudflare Tunnel"]
    Connector --> Ingest["Ingestion Worker"]
    Ingest --> Raw["R2 raw archive"]
    Ingest --> Q["Queue"]
    Q --> Validate["Normalization and validation Worker"]
    Validate --> PG["Postgres through Hyperdrive"]
    Validate --> WF["Submission Workflow"]
    WF --> Review["Human review"]
    Review --> NERIS["NERIS / vendor APIs"]
    PG --> Export["Portability service"]
    Raw --> Export
    Export --> Package["Open export + signed manifest"]
    Access["Cloudflare Access"] --> Ops["Internal operator console"]
Loading

Components

  • Workers: public API, upload boundary, authorization, orchestration, and export service.
  • Postgres through Hyperdrive: tenants, users, normalized records, mappings, validation results, submission state, row-level security, and audit metadata.
  • R2: original source exports, checksums, normalized export packages, validation artifacts, and offboarding bundles.
  • Queues: durable buffer between ingestion and parsing; all consumers must be idempotent because delivery is at least once.
  • Workflows: long-running validation, repair, human-review, submission, and retry sequences.
  • Cloudflare Access: company operator and support console.
  • Cloudflare Tunnel: optional outbound-only connector for agency networks that cannot push exports directly.
  • API Shield: later-stage mTLS, JWT, schema, and API-abuse controls for enterprise integrations.

Do not introduce D1 alongside Postgres in the initial product; two relational sources create unnecessary ambiguity. Do not add Durable Objects unless per-agency ordering or atomic concurrent coordination becomes a demonstrated requirement.

Ingestion invariant

Persist the raw source object to R2 before normalization. Record:

  • tenant and source-system identity;
  • content hash;
  • import timestamp;
  • source schema version;
  • parser version;
  • processing status;
  • validation report;
  • submission and export provenance.

This makes parser failures recoverable and proves preservation of the original agency data.

Security posture

  • Enforce tenant isolation in both the Worker and Postgres row-level security.
  • Use per-agency, revocable connector credentials.
  • Sign incoming webhooks and validate content type and size.
  • Store secrets in Cloudflare-managed bindings or Secrets Store.
  • Use application-level immutable audit events and export them with customer data.
  • Keep ePCR and PHI out of the first product.
  • Treat HIPAA, CJIS, data residency, and records retention as separately verified obligations; product names do not confer compliance.
  • Require human approval for final NERIS submission.

Failure modes

  • Vendor outage: Queue buffers work; Workflow retries with backoff; dead-letter and manual resume paths.
  • Corrupt export: preserve and quarantine in R2; emit a validation report rather than partially importing.
  • Duplicate delivery: content hashes, external IDs, and tenant-scoped unique constraints.
  • Postgres outage: stop mutation, retain queued jobs, and provide a clearly degraded UI.
  • Connector compromise: revoke only the affected agency credential; prevent cross-tenant access.
  • Customer departure: produce a documented open export plus checksums and manifest.

Delivery phases

  1. Bring a file: upload a legacy NFIRS/RMS export, receive validation, and download a normalized archive.
  2. Named connectors: support selected CAD/RMS sources and durable remediation workflows.
  3. Submission: human-approved NERIS submission and rejection repair.
  4. Regional deployment: county/state aggregation, enterprise SSO, Tunnel connectors, API Shield, and jurisdiction-specific controls.

Essay directions

Possible central claim:

Private equity did not privatize the fire department; it acquired parts of the administrative layer required to operate it.

Stronger causal framing:

  • consolidation is an accelerant;
  • interoperability debt and weak exit rights are the underlying disease;
  • mandatory modernization converted technical debt into a buying event;
  • the public-interest intervention is portability, not merely a cheaper bundle.

Important counterargument:

Legacy vendors may have been structurally underpriced. Consolidation capital can fund security, support, cloud modernization, and integration breadth. The defensible policy response is therefore measurable service quality and enforceable exit rights—not an assumption that every price increase is extraction.

Selected references

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment