We Built a PWA for SWAT Teams. Here's What That Demanded.
Command Post started from a specific frustration: SWAT teams were doing mission planning in group texts, Word documents, and whatever the department's existing software happened to support. After-action reports sat in email threads. Training records lived in spreadsheets no one updated consistently. The tools weren't built for the job.
We built Command Post to fix that. It's a PWA at getcommandpost.org: multi-tenant, Next.js and Supabase, live with paying teams. Here's what made it different from a typical dashboard build.
Domain Knowledge First
The hardest part of building software for a specialized field is knowing what matters when the situation is real. A mission planning form that asks for the wrong fields isn't just incomplete, it creates friction at the worst time. An after-action report template that misses standard categories means reports that can't be compared across incidents.
We have an unusual position here: Twenty1 Media is run by an active SWAT operator. That's not a selling point we lead with, but it shaped every decision in Command Post. The mission planning flow asks for the right questions in the right order because we've run them live. The training tracker surfaces the data a team lead actually wants, not a generic list of checkboxes.
This is the real value of domain-specific software built by someone inside the domain. You don't have to explain the workflow from scratch. You don't have to correct a developer who builds the obvious thing instead of the right thing.
Why a PWA
Tactical teams don't carry laptops in the field. They carry phones, often in situations where network reliability is uncertain and fumbling through a browser navigation bar isn't an option.
PWA was the right call for a few reasons. First, it installs to the home screen on any device without an app store. Teams can push it to department-issued phones without a deployment process. Second, service workers give us offline capability for the data that matters in the field: current mission details, team member information, assigned roles. Third, we get one codebase instead of separate native builds, which matters for a team of one.
The tradeoff is that PWAs have limits: push notifications on iOS are still rougher than native, and some advanced device APIs aren't accessible. For Command Post's actual use cases, those limits don't bite. The work that needs to happen in the field is read-heavy. The write-heavy work (after-action reports, training logs) happens back at the station.
Multi-Tenant Architecture
Different teams, different data, complete separation. This is table stakes for any platform serving multiple paying organizations.
The Supabase row-level security policies carry most of the weight here. Every query is scoped to the authenticated user's team by default, at the database layer, not the application layer. A misconfigured UI component or a forgotten where clause can't leak one team's mission data to another. The RLS policies are the source of truth.
Team management lets an administrator provision accounts, assign roles, and manage who has access to what within their organization. We built this as a first-class feature, not an afterthought, because teams turn over. New operators join, people leave, roles change. If the platform can't handle that cleanly, an administrator is doing manual database work every time.
What It Tracks
Four core modules: mission planning, after-action reports, training, and team management.
Mission planning lets a team lead build out an operation before it runs: objectives, assignments, timeline, role assignments by operator. It's structured enough to be consistent across incidents, flexible enough to cover the range of situations teams actually respond to.
After-action reports close the loop. When the mission is done, the report links back to the plan, captures what happened against what was planned, and documents outcomes. That linked history matters for legal records, department review, and training analysis.
Training tracking is where teams often have the most existing pain. Hours logged, qualifications maintained, certifications current or expired. Command Post surfaces this per operator and per team so a team lead can see at a glance who's current and who needs a recertification before they're cleared for certain operations.
What's Next
The platform is live and generating revenue. Current focus is adding features that paying teams have asked for: reporting exports for department records, calendar integrations for training scheduling, and API endpoints for departments that want to connect Command Post to their existing RMS.
If your department or team is running operations out of a group chat and a spreadsheet, Command Post was built for exactly that situation.