On the board before the confirmation screen.

The challenge

Nobody on the shoulder of I-75 is browsing. They want a number that dials and a way to say where they are, and every extra field between them and that is a chance to lose them to the next result on the page. On the other side of it, the requests that do come in land in a phone that is already ringing, and the dispatcher is holding the whole board in their head.

What we built

The site and the system that runs it, as one build: a tow request submitted from the roadside is on the dispatch board before the customer's confirmation screen has finished rendering.

• An action bar that never hides — Call now and Request service fixed to the bottom of every phone screen. A bar that disappears while you scroll is a bar you have to hunt for at the exact moment you decide to act
• Three required fields in the entire request flow — a name, a callable number, and some idea of where you are. An address, a description, a landmark, a highway reference, a mile marker or a browser fix all satisfy the last one. Every required field is a chance to fail at the worst possible moment
• Geolocation offered, never demanded — declining is a supported path rather than an error state, and the manual fields are already on the same screen
• Photos that upload after the request exists — the job is on the board the instant they press send and the pictures catch up, so a failed upload can never cost somebody their tow
• Martin's DASH — dispatch board, drivers, fleet, customers, commercial and repair accounts, leads, site content and reports, in one place
• Save first, notify second, always — a dead SMS provider produces a logged failure, never a lost request, and DASH surfaces skipped and failed notifications so staff can see the system isn't texting them
• Driver conflicts that surface instead of overwriting — assigning a driver who already holds an open job returns what they're on. A dispatcher can still double them up, but only deliberately

What the site refuses to say

Three facts about the business were supplied for this build: the name, the phone number and the address. Everything else a towing website normally asserts — hours, response times, fleet size, equipment, certifications, service radius, testimonials — is absent, not guessed. A plausible-looking placeholder is indistinguishable from a fact once it's on a live site, and on a towing website those are exactly the claims that are most damaging to get wrong.

So ten service pages, six service-area pages and eleven FAQs ship as drafts, with the questions written and the answers empty, and the site renders nothing at all where a value is unset. Publishing is refused, in plain English, until the content is real — and a service-area page needs at least 200 characters of genuinely area-specific copy, which makes it structurally impossible to spin out a rack of identical city pages with the name swapped. One more rule sits in the same family: a request is not a dispatch, and nothing tells a customer a driver is coming until dispatch actually says so.

The result

A towing company with a front door built for the worst ten minutes of somebody's day and a back office that keeps up with it — every request logged, every status change written to history, and a website that can only ever say things that are true. It's the custom website and operations platform work we bring to any business where the job starts with a phone call.

See it live: View the site ↗

A look at the site