RURAL HEALTHCARE / AI-NATIVE PROTOTYPING
Courier
The idea became working software in one morning.
Courier began with an opportunity to present a better way of supporting a complex delivery route to a group representing 31 rural healthcare providers.
The couriers carry more than packages. They carry a day’s worth of timing constraints, pickup and drop-off details, access instructions, and accumulated local knowledge.
Instead of arriving with a presentation about what an app might become, I used AI to build a working version in a single morning. The point was not speed for its own sake. It was to move the conversation from “could this help?” to “this is what help could feel like.”
The hard part was already in the route.
A route spreadsheet can record stop order. It does not relieve the courier of remembering what matters at each stop, which details are easy to miss, or which timed commitment is approaching.
Courier turns that existing route knowledge into a calm progression through the day. It keeps attention on the current stop, preserves enough context to understand what comes next, and prevents a seemingly harmless route change from breaking a real timing constraint.
The route book remains the source of truth. The software makes that truth easier to use.
The speed came from a different division of labor.
Once the product idea was clear, AI could translate it into the data model, validation rules, timing behavior, local state, and mobile interface while I stayed focused on the actual experience.
This was not a request for a generic courier app. The work was a continuous exchange: provide the real operating constraints, inspect what the software did, correct what the AI misunderstood, and keep narrowing the product until it felt like the right kind of help.
In a few hours, a specific operational observation became a credible working artifact. That collapse in time changes when software can enter a conversation—and who can afford to explore a custom solution.
Help, not surveillance.
Many operational applications turn the person doing the work into a source of management telemetry. Courier deliberately refuses that bargain.
It is local-first. It does not need a supervisor dashboard, location tracking, performance scoring, cloud sync, or a backend watching the route. The courier sees what matters now, completes the work, and moves on.
That restraint is not unfinished functionality. It is the product judgment at the center of the app: guidance should reduce cognitive load without making the person receiving it feel monitored.
A demonstration, not a deployment.
Courier is a working, bounded demonstration. It can compile and validate a route, guide someone through its stops, preserve completion state locally, surface timing constraints, and show the day as a whole.
It has not yet been proven as a live field tool, and it should not be presented as production healthcare software. The current experience still uses a fixed demonstration clock, and real-world maps, native-device behavior, security, and sustained field use remain open.
The opportunity with the rural healthcare providers is still being explored. Whatever comes next, the project has already demonstrated the larger point: AI can turn a well-observed operational problem into specific, credible software early enough for that software to shape the conversation.
Owen Fowler
AI Systems Builder
Tell me what you’re working on.
A few sentences is enough.