My own app, 2026, in testing
Centline
I built an invoicing app for truck drivers who own one truck. It shows the load they're on, gives them one button for the next step, and won't send an invoice without its paperwork.
For an owner-operator, driving is half the job. The other half is paperwork, and the money waits on it. A broker (the company that hired him for the load) won't pay until the signed bill of lading and the rate confirmation come with the invoice. One missing page means a late payment.
Before and after
Before
After a delivery he has to gather the signed bill of lading (the receipt for the freight) and the rate confirmation (the agreed price), then write the invoice and send it, often from a loading dock at night. My first version didn't fix that. It tried to do five jobs at once, and its checklist let him tick boxes without attaching anything.
After
The app opens on the load he's on, with one button for what comes next: picked up, delivered, write the invoice. The invoice goes out as one PDF packet, and it won't send until both papers are in it.
How I worked
Research
The slow part was after delivery
My dad has driven a truck for 35 years and owns his own. Watching him, I saw the time didn't go into driving. It went into the stretch between delivering a load and getting paid for it.
Define
One driver, one truck, one hand on the phone
The user is an owner-operator, often in his first year, using a phone one-handed at a dock at night. He won't open an app to read reports, and he'll delete one that wastes his time. So I kept it to two jobs: move the load, and get it paid.
Design
Every change drawn two to four ways first
Before any code, I draw the options side by side, pick one and write down why. That's 28 design specs so far. When the options sit next to each other, the right one is easy to spot.
The top of Getting paid, drawn four ways, with A marked as the pick. Names and numbers are made up. Build
From the broker's email to a signed packet
He shares the rate confirmation from his email, it lands on the right load, he signs it on the phone and it joins the invoice. I design and build all of it myself. Claude Code, an AI coding tool, drafts options and checks the work against rules I wrote. Nothing merges until I approve it.
The real app on a simulator: check the rate con, write the invoice, fill the packet, get paid. Example data. Test
Rules held by tests, then someone trying to break it
Automated tests check every rule on every change, including that each screen fits phones from 280 to 466 points wide. Tests only prove what they check, so a separate AI agent, the breaker, tries to make each finished change fail. In one night it found 11 real defects before any of them shipped.
The turning point
The fork in the road
Six weeks in, I cut the whole cost side of my own app: pricing, deadhead (the empty miles driven to reach a load), a load check and a broker network.
Why I went this way
The easy path was to keep what I'd already built. But drivers weren't losing time on pricing. They were losing it between delivered and paid. I'd rather do two jobs well than five halfway, and the cut took the app from 5 tabs to 4: Now, Loads, Invoices and Profile.
The proof
- 1button on the home screen, always the next step for the load
- 4steps from the broker's email to a signed invoice packet
- 0invoices that can be sent without the signed bill of lading
- 5 → 2jobs the app does, after cutting what wasn't the pain
What it meansFor a driver, the invoice is the paycheck. Building around the moment after delivery, and refusing to send an incomplete packet, protects money he's already earned. A focused app is also one a skeptical driver keeps instead of deleting. It's in testing now and not on the App Store yet.
