Skip to content
KYRON Command Center: squads, fighters, incidents and response time over the operational map
KYRON Fighter app home: active incidents and readiness

KYRON

Community First-Responder System

I researched a gap the state itself had documented, designed a system to close it, and took it to the field. The field redrew the problem.

Role
Solo — research, design, front-end
Build
Web + Mobile
Built with
  • Cursor agents
  • Claude Code
  • Claude
  • Figma
Timeline
5 weeks · Aug–Sep 2026

At a glance

Problem
After October 7, community defense squads grew from about 70 to about 1,060. Nobody had one view of who’s ready, who holds which weapon, or whose qualification lapsed.
My role
Solo: research, design, front-end. 5 weeks, Aug–Sep 2026.
What I did
Turned public reports into three bets and six hypotheses, mapped the information model, and built a working prototype on web (Command) and mobile (Fighter) that share one record.
What I found
Three field interviews (two settlement coordinators, one regional security officer) showed a free, state-built app already in use, budgets that arrive per operation, and no one required to report readiness.
Decision
I recommended not to build. What remains: a working prototype and a clear map of who owns the problem.

The problem

After October 7, the squads multiplied.The records didn’t.

State Comptroller and Knesset reports describe the same picture: coordination over non-military channels, no central view of equipment, and readiness data the ministries didn’t provide when parliament asked.

(From my desk, this looked like a product.)

About 70 squads before October 7, about 1,060 after

Police-run community defense squads: about 70 before October 7, about 1,060 after (as reported to the Knesset)

My bet

Three bets, six things to check

I formed them from public reports and a competitor scan, broke them into six hypotheses, and took those to the field.

  1. 01

    Alerting is solved

    Free tools already handle the call-out.

  2. 02

    Accountability is the gap

    Who holds which weapon, whose qualification lapsed, what gets reported up.

  3. 03

    The KABAT is the buyer

    The KABAT, the regional council’s security officer, owns the problem and would pay to fix it.

What I built

Records first, screens second

Nobody types “ready.” Readiness is derived from what each role already records. I mapped the information model first, then built it as a working prototype to test the bet — the fastest way to find out which assumptions would survive contact with the field.

Two apps, one record. Fighter, the phone app for each squad member, is where the data enters; Command, on the web, is where the coordinator sees it arrive. Both share one Supabase project — seven tables, storage and realtime — so a status set on the phone appears on the web roster. It’s a demo sync with open access rules, not a production backend.

Fighter app: setting status to Unavailable, with Sick as the reason

Fighter · mobile

KYRON Command's Live Activity feed: field report received, weapon issued, drill logged, qualification renewed, equipment return overdue

Command · web

A fighter sets a status on the phone; Command’s live activity shows what came in.
Information model: who records what, and which readiness input it feeds
  1. Fighter

    Fighter app · mobile

    • Availability and check-ins

      feeds Check-in

    • Uploads medical approval, weapon permit and training certificates

      Counts once verified

    • Answers call-outs, drills included

      feeds Drills (90d)

  2. Coordinator

    Command · web

    • Verifies documents

      feeds Qualificationsfeeds Medical

    • Schedules and runs drills

      feeds Drills (90d)

    • Issues and returns gear, with a due-back time

      Shows as pending return

  3. Oversight

    Regional officer · web

    • Reads the roll-up across settlements

      Reads only

40 · 30 · 20 · 10 — weights editable per region

Readiness decays. The system notices first.

Qualifications expire on their own schedule. KYRON flags them before they lapse, filters the roster in one click, and carries the change into readiness — the part none of my interviewees described the existing app doing.

Readiness after one click on Quals expiring: the card reads Firearm · 14d left, the roster shows 1 of 1 fighters, with a FIREARM exp 14d qualification
One click on Quals expiring filters the roster to the fighter whose firearm qualification lapses in 14 days.

Then I called the people who run it

Three interviews rewrote the brief

Two settlement security coordinators and one regional security officer. September 2026.

3 interviews · directional evidence · no usability validation

Interviewees took part with consent and are anonymized; operational details are left out.

Alerting is handled elsewhere

All three use the same free, state-built app for call-outs and squad status.

Confirmed

But the incumbent was the state, not a startup.

Weapon custody is untracked

Signed out through the owning force (the IDF or police unit that issues the weapon), or on a police system.

Revised

The owning force records custody. Nobody described it as a problem.

Training records are missing

“I log it internally, in Excel, on my computer. Upward I send only a drill summary.” · Training through the owning force is “documented and organized.” · Local drills draw “three or four out of 18.”

Partly

Records exist. The real issue is attendance, which software doesn’t fix.

Availability is informal

“Personal WhatsApp, to me.”

Confirmed

For one coordinator.

Someone wants a readiness report

“No one asks. Not the police, not the Interior Ministry.” · One coordinator sends a weekend status by WhatsApp.

Revised

Status is asked for informally. Readiness isn’t asked for at all.

The KABAT is the buyer

“I’m not subordinate to the KABAT at all. I answer to a different chain of command.” · Security budgets arrive per operation.

Revised

The owner depends on the command chain, and budgets aren’t steady.

KYRON Armory: an overdue banner for M4-A106 held by Noam Levi, 14 days overdue, over the asset table with each item's status and holder
Built for the custody hypothesis: the overdue item and who holds it, flagged above the asset table.

What they raised without being asked

  • Too many comms devices, and hours of in-person meetings.
  • Being last in line for resources — with a decades-old fence.
  • Squads that don’t update the regional officer during a live incident.
  • No way to reach residents. Only fighters.
None of it was on the feature list.

The moment that changed the thesis

In a real incident, a squad that had drilled on the existing app responded well — but reported through none of the formal channels.

The tool was there. The habit wasn’t.

The gap wasn’t software.It was ownership.

The decision

The right next step was not to build

The decision came down to three conditions: a buyer with a steady budget (Owner, Budget), a mandate (Mandate), and a gap the existing system doesn’t cover (Pain, Incumbent). None held.

Pain
Real, but mostly procedural, infrastructural or institutional
Owner
Split across security forces, police, council and settlement
Budget
Arrives per operation, not steady
Mandate
No one is required to report readiness, so no one asks for it
Incumbent
State-built, free to settlements, already in use

I chose not to run usability tests: once the incumbent was clear, the more useful question was “should this exist,” not “can they use it.” What could reopen it is a readiness-reporting requirement — and even then, the likeliest home is a module in the existing app.

What I learned

  1. 01

    Reports frame the problem. People define it.

    Public reports showed the gap. Three conversations showed the tool already in use, who actually owns what, and problems no report listed.

  2. 02

    Let the evidence pick the hero feature.

    The field showed readiness decays and nobody reports it — which is why it’s the demo here. Nobody asks for it either, which is why it’s a product without a buyer.

  3. 03

    The loudest problems weren’t software.

    Devices, fences, resource priority and reporting habits. A good interface fixes none of them.

Deliberately not launched. What came out of it: a working front-end prototype on two surfaces, running on demo data, and a clear map of who owns this problem — and who doesn’t.

AI made building cheap.It didn’t make knowing what to build any cheaper.

Appendix

Also in the build

  • Incident flow

    Declare, mobilize, stand down. Responses and positions are simulated; the AI text is templated, with no model yet.

    See KYRON AI →
  • One system, two surfaces

    Two apps in five weeks drift apart fast. One token set: one teal accent, borders instead of shadows, and red kept for incidents.

How I built it

Specs in, working prototype out

Figma set the visual language. For each Command screen I wrote a spec — route, states, edge cases — and AI agents (Cursor, Claude Code) implemented it in React and React Native, with 485 passing unit tests as the guardrail.

That’s how one designer built a working front-end prototype on two surfaces — on demo data, with a demo sync — in five weeks (the mobile app in ten days). Using the real product fed back into the system: rules like “every KPI filters or links, never decorates” came from use, not from Figma.

Epilogue · Beyond Israel

A system born in Israel.A question that isn’t.

KYRON was designed around Israeli community defense squads, but the question is broader: how do Jewish communities coordinate security, preparedness and response across people, institutions and local authorities? Organizations like the Secure Community Network already do this at scale in North America (2024 Annual Report).

A hypothesis, not a validated market. Whether it transfers depends on the same three conditions — buyer, mandate, gap — and none has been tested there.