Designing an emergency tool you hopefully never use.
A CPR training session exposed an access problem under pressure—and turned an obvious app idea into an offline-first exploration of the phone someone already owns.
Important: StartCPR does not replace certified CPR training, professional medical guidance, emergency services, or AED instructions.
CPR
Where it started
Victory Mandaue Cebu · Emergency Response Team training
There is a lot to remember when pressure arrives.
Part of the training covered CPR: the compression rhythm, the sequence of actions, contacting emergency services, getting an AED when one is available, and continuing compressions while keeping track of what happens next.
That is why we train. We hope we never need any of it. But if that moment comes, preparation matters.
The reasoning
The path from training to architecture.
- ERT TRAINING
CPR requires action, sequencing, pace, and coordination.
- PRESSURE
A responder may be alone and carrying the whole cognitive load.
- OBVIOUS IDEA
Build a mobile app that provides guidance.
- CONFLICT
A rarely used app may be archived, offloaded, deleted, or forgotten.
- REFRAME
Make the phone already in someone’s hand more useful.
- DIRECTION
Explore local system automation and offline capabilities.
The pivotal decision
The most important product decision so far
Why StartCPR isn’t an app.
“What happens if the first time you need the product in years is also the moment you discover it isn’t available anymore?”
Conventional CPR app
- Install the app
- Rarely open it
- It may be archived, offloaded, deleted, or forgotten
- A dependency may fail at the moment of need
That is a reasonable operating-system behavior—but an uncomfortable failure mode for this product.
StartCPR approach
- Prepare once
- Use system automation
- Keep the essential workflow local
- Design for offline availability
The product becomes a prepared capability, not another destination competing for engagement.
The public artifact
A website that is not the product
The website helps someone prepare. It should become unnecessary during an emergency.
- Explain what StartCPR does
- Set clear limitations
- Guide supported setup
- Show where to place quick access
- Help someone verify their preparation
The website stays outside the critical path →
Intended architecture
Separate preparation from response
The emergency workflow lives beyond the website.
The website helps prepare the phone. The website should not be required during the emergency.
AIRPLANE MODE TEST
This is a test requirement, not a completed certification claim. If something critical breaks in Airplane Mode, that dependency does not belong in the intended emergency path.
Product principles
Constraints became the design system.
These rules guide the work before features do.
Prepare before the emergency
The emergency is the worst possible time to configure software.
Keep the essential path offline
After setup, critical guidance should not need an account, API, server, or website.
Use what the phone already does
Prefer reliable system capabilities over recreating them in another application.
Training still matters
Technology may assist a responder; it cannot replace certified training, professional guidance, emergency services, or AED instructions.
Reliability over feature parity
Platforms do not need identical implementations. Each supported workflow needs to be dependable.
Platform support
Support expands only when reliability earns it.
There is no universal automation layer across smartphones. Apple Shortcuts is the first path under exploration. Samsung Modes and Routines may offer another. Other manufacturers expose different capabilities.
Platforms do not need to work identically. They need to be dependable.
Apple Shortcuts
Modes and Routines
Capability varies
Current status
The identity exists. The critical workflow is still being developed and validated.
The unfinished questions are not footnotes. They are the engineering work.
Which Apple Shortcuts actions remain reliable offline?
Can compression pacing be provided accurately enough using system capabilities?
Which instructions avoid unnecessary interaction during CPR?
How quickly can the prepared workflow be accessed?
What happens while the phone is locked?
What happens without cellular service?
Which steps require interaction because of operating-system security restrictions?
How should emergency calling coexist with guidance?
How can instructions remain aligned with authoritative CPR guidance?
If the implementation cannot satisfy the original constraints,
the implementation needs to change.The constraint doesn’t.
The product paradox
Success may look like no engagement at all.
Most products optimize for daily activity, retention, and return visits. StartCPR should help someone prepare, understand access, and then go on with life. Maybe they never open it again. That would be wonderful.
SET IT UP TODAY.HOPEFULLY,
NEVER USE IT.
What StartCPR taught me
The best decision so far was deciding not to build the obvious solution.
Choosing technology should come after understanding the problem. Sometimes the answer is a native app, a website, or a backend service. Sometimes the phone already contains almost everything needed, and the engineering problem becomes learning how to use those capabilities responsibly.
That is what I am trying to do with StartCPR.