KYRON
Community First-Responder System
Cursor agents
Claude CodeClaude
Figma
The problem
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
I formed them from public reports and a competitor scan — then took them to the field.
Free tools already handle the call-out.
Who holds which weapon, whose qualification lapsed, what gets reported up.
The regional security officer owns the problem and would pay to fix it.
What I built
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.
Fighter and Command 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 · 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)
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
Regional officer · web
Reads the roll-up across settlements
Reads only
Readiness40 · 30 · 20 · 10 — weights editable per region
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.
Then I called the people who run it
Two settlement security coordinators and one regional security officer. September 2026.
3 interviews · directional evidence · no usability validation
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, or on a police system. Where there’s a local armory, deposits are arranged by WhatsApp.
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.
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 decision came down to three conditions: a buyer with a steady budget, a mandate, and a gap the existing system doesn’t cover. None held: budgets arrive per operation, nobody mandates readiness data, and the existing app already covers the call-out.
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
Public reports showed the gap. Three conversations showed the tool already in use, who actually owns what, and problems no report listed.
The field showed readiness decays and nobody tracks it — which is why it’s the demo here. Nobody asks for it either, which is why it’s a product without a buyer.
Devices, fences, resource priority and reporting habits. A good interface fixes none of them.
AI made building cheap.It didn’t make knowing what to build any cheaper.
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.
Appendix
Available, Busy or Unavailable, with a reason. The status syncs to the web roster, where Busy reads as On call. Fighter is a full surface: Home, call-out, live map, Standby (availability & documents), issued gear, events & drills, field report and declare. It's where the data enters the system.
Declare, mobilize, stand down. Responses and positions simulated; AI templated — no model.
See KYRON AI →No one could see who held what. Every item has a holder, a due-back time and a custody history. A weapon can only go to a fighter with a valid qualification, and one still out with an unavailable fighter shows as pending return on Readiness.
Two apps in five weeks drift apart fast. One token set: one teal accent, borders instead of shadows, and red kept for incidents.
Records gate each other: a fighter shows “Pending clearance” until a document is verified, and a weapon can only be issued to someone with a valid qualification — with a custody history behind every item.
How I built it
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. Working this way let one designer build a working front-end prototype on two surfaces, on demo data with a demo sync, in five weeks (the mobile app in ten days), and 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
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.
