Case Study · OkieNerd

A statewide dispatch platform. Two fully native apps. One engine running it all.

OkieNerd dispatches background-checked, in-home tech help across nearly 70,000 square miles of Oklahoma. Scheduling, dispatch, matching, payments, phones, texting, remote support, and the entire back office run as one engine, with native iPhone and Android apps live in both stores. It is my own company, so nothing here is filtered for a client's comfort: I architected every system, set every standard, and drove my development team through everything that shipped.

Role
Founder, chief architect, delivery lead
Scope
Brand, platform, native apps, operations
Status
Live in production, taking payments
20
Markets launch-ready behind a single back-office switch
2
Native apps carried through both app stores
3
Rented platforms retired, replaced with owned code
0
Double-bookings possible, enforced by the database itself

01The problem: dispatching trust across 70,000 square miles

The business idea was simple: patient, in-home tech help for people who would rather have a polite person at the kitchen table than a support line in another time zone. The operating problem behind it was not simple at all. It meant dispatching vetted contractors across a service territory of nearly 70,000 square miles, pricing every drive honestly, protecting the customer from the contractor and the contractor from the customer, and doing all of it on margins that survive a rural service call.

No off-the-shelf product solves that. Hosted scheduling tools manage one person's calendar; this needed a fleet, with travel time, skills, background-check gates, and per-distance pricing decided at the moment of booking. So instead of stitching the company together from a dozen subscriptions, I architected one platform that runs the entire business end to end, and led the build from systems design through delivery.

02The architecture, at a glance

The design is deliberately simple: every surface a customer or technician touches talks to one engine, so a business rule changed once is changed everywhere. Simple systems are cheap to run, fast to change, and easy to reason about when something goes wrong.

03What one platform carries

Everything below ships from one codebase, behind one API, under one set of engineering standards.

Booking & dispatch

A purpose-built engine models every technician's day as precise intervals. Holds, bookings, and dispatches are the same kind of record, so on-demand service is configuration, not a rewrite.

Matching intelligence

Returning customers get the technician who helped them last. Skills profiles keep the wrong person from being sent to fail. Coverage is computed from real committed drive ranges.

Payments

Memberships, one-time visits, in-field charges, and tips on one set of rails, with versioned terms: a price change never rewrites what an existing member agreed to.

Telephony & messaging

The phone system's intelligence lives in our own code on a usage-priced carrier: one greeting for every line, masked relay calls, and local numbers chosen per visitor.

Remote support

Self-hosted remote desktop for computers, plus a purpose-built iPhone screen-sharing path that mainstream remote-support products simply do not offer.

Native mobile

Native Swift on iPhone, native Kotlin on Android, deliberately mirrored so features ship to both stores in step. Widgets, live activities, and native payment sheets included.

The back office

Seventeen permissioned modules for books, payouts, coverage, hiring, and messaging, with access enforced server-side per module so no role quietly grows into another.

Print on demand

Each technician's cards are composed from live data: right phone number, right price, their own referral code, proofed at press geometry and drop-shipped to their door.

White-label gear store

A branded merchandise storefront, public-facing and internal, fulfilled print-on-demand with tax, tracking, and shipping notifications handled. Zero inventory, zero risk, and the brand on every box.

04Decisions that protect revenue and trust

These are the calls a buyer should ask any architect about, because they are invisible until the day they are everything.

Double-booking is impossible by construction

The conflict check and the write that claims a slot happen as one atomic transaction. Dedicated tests race two customers for the same slot to prove it.

Travel is modeled honestly

A job blocks the drive on both sides of it, inside the technician's stated hours. Nobody's day gets silently consumed by double-counted drive time.

Sold and actual are separate figures

A visit that runs long never silently rewrites the agreed price. Overage goes to a human, never an auto-bill, with an append-only audit trail behind every visit.

Third parties can never break the core

AI triage estimates realistic durations from the customer's own words, but it is advisory: if it is down, the booking completes. Calendar sync can subtract availability, never add it.

Privacy lives in the data model

Contractors never see a customer's phone number or email. Not hidden by the interface: structurally absent from every payload they can reach. Webhooks are signature-verified; staff sign-in is SSO with server-side checks.

Deploys refuse to ship mistakes

Every deploy audits its own pages and claims against their source of truth and ends by polling the live health endpoint. If any check fails, nothing ships. Backups are integrity-checked nightly into three failure domains.

05Owned where it matters, rented where it should be

The build-versus-buy line was drawn deliberately: own everything that is the business, rent only commodity utilities priced by use, and never let anything rented hold the customer relationship or the data.

CapabilityHow it is delivered
Scheduling & dispatchOwned engine, built for a fleet; hosted tools schedule a person
WebsiteOwned static site, generated from one source of truth; no CMS to hack
Phone systemOwned call logic on a usage-priced carrier; no per-seat licenses
Remote supportSelf-hosted; no per-technician licenses
Payments & screeningDeliberately rented: regulated money movement and compliance stay with specialists, priced per transaction
Marketing collateralOwned variable-data renderer; trade printing per order, no minimums, no inventory
Branded gearWhite-label storefront on per-item print-on-demand fulfillment; zero inventory risk

The result is a stack with no per-seat software anywhere in it: the tenth technician and the hundredth cost the same software dollars, which is zero, and the marginal cost of serving the next customer or the next market is close to nothing. All twenty markets were mapped, priced, and wired in before launch, so opening a new city is a switch in the back office rather than an engineering project.

The asset test: the platform is a documented, version-controlled, tested codebase with a replacement cost at contractor rates well into the mid six figures, delivered in-house. It has been security-reviewed, it takes live payments, and it is backed up in three places. That is the difference between a stack of subscriptions and a company that owns its own machinery.

06What this means for your project

OkieNerd is proof of full-scope delivery: brand identity, product design, platform architecture, two native apps carried through store review, payment rails, telephony, security posture, and the operational tooling to run it, all under one accountable architecture. That is what I bring to an engagement: I design the system, set the engineering standard, and stay hands-on with the team building it, so the vision and the execution never drift apart. If your business needs software shaped to how it actually operates, connected to everything you already run, and owned rather than rented, this is what that looks like carried all the way to production.

Next case study Red River Integration: the whole revenue engine, owned, as one system →

Work With Me

Want this level of engineering on your business?

Most engagements begin with a complimentary scoping call: what you have, what you need, and the honest shape of the work between them.