Reworking a trucking payments app around its users

The real problem: it didn't fit how carriers work

The app didn't need a teardown. Most of its structure was sound, and carriers are owner-operators running a business from the cab of a truck, so an app they rely on to get paid is not a place to surprise them. It needed to fit how they actually work, and two changes did most of that.

First, I reformatted the core listing and detail screens around the data a carrier actually scans for. The old screens led with the PO number, which carriers rarely use to identify loads. I led with the broker name and the pickup and drop-off locations, which is how a trucker actually recognizes a load. A small change on paper, a big difference in how fast the app reads.

Second, at the founder's push, I added a bottom nav that puts the app's main areas one tap away, so the things people reach for most are always in reach. A bottom nav has a ceiling, so we made the plan explicit: once there are more areas than it can hold, the app graduates to a fuller menu. Committing to the bottom nav now and naming its successor kept the app fast today without painting us into a corner later.

Testing it against real carriers

A redesign is a hypothesis until someone who isn't you tries to use it. We ran several rounds of moderated testing, about five to start, some I ran and some with Chase, BasicBlock's PM. They were rigorous: explicit success criteria per task, a think-aloud protocol, and a "we're testing the app, not you" framing. We ran the real workflows, happy paths and unhappy ones alike, from onboarding and document upload to requesting an advance, always asking the same thing: could a driver confidently self-serve without calling support?

We also got it in front of carriers who had never touched BasicBlock at all. Chase took an iPad to an industry conference and tested the app on the go with real drivers who had never seen it, which is the hardest and most honest audience there is: no context, no goodwill, just "does this make sense."

AI earned its keep in testing, too, as a tool, not a replacement. By the later rounds we weren't testing a Figma click-path but a real, coded prototype. That mattered: a Figma prototype walks everyone down the happy path, while a prototype that behaves like real software lets people go the wrong way, and what you learn then is true. As the PM put it, the old Figma version had felt like we were just guiding people to the answer.

When the evidence cut a feature

One idea we were genuinely unsure about was a way for carriers to poke or nudge a submitted load they hadn't heard back on, a release valve instead of calling in. The intent was good. The problem was that nobody, on our side or the carriers', could say what it actually did. Did it move you up a queue? Notify your rep? Promise a response? We reframed it into a testable "Nudge / Follow Up" feature and put it in front of carriers.

The testing confirmed the ambiguity. Carriers couldn't tell what it would do, or what to expect after using it, the same uncertainty we'd had internally. Across continued rounds it didn't earn its place, and it was cut. That call got made together, once the evidence was on the table. It's the cleanest example I have of what user research is actually for: letting evidence, not anyone's gut, decide what ships.

Building it

Validated designs still have to become working software, and this is where AI carried real weight for the first time on one of my projects. Working from the existing app code, we let AI take a first pass at the whole rework in more or less one shot. It did pretty well, further than I expected, and it did it in a few days. A from-scratch build would have gotten there too, and been perfectly good, but it would have taken months, so the speed was the real win. Still, "pretty well" isn't shippable. Steps were off, the UI drifted from the design in small ways, and the last stretch, the part where the design actually lives, still needed a person.

Conducting the build

So I became the conductor. I went screen by screen, AI writing the code while I judged every one: does this match the design, does it behave right, is this the correct pattern. That view-by-view walkthrough and polish is what actually brought it across the finish line. The styling lives directly in React Native style objects and our own component layer, so the rework fits the existing app instead of fighting it.

I was moving more of the design-to-code work into my own hands, so the design intent survived, while the engineers stayed focused on the work that actually needed their expertise.

Anything genuinely backend, or past where a designer should be making the call, I wrote up as a ticket and the engineers took it across the finish line. Chase ran design QA alongside me, weighing in on UI calls and catching bugs, with the carrier know-how to tell when something was subtly wrong for a real driver. The deeper story of how I build with AI, where it helps and where it falls down, is its own piece: "AI didn't replace the design work. It moved it."

Measuring it

Design is easy to assert and hard to prove, so before launch I built a baseline. Chase and I inventoried the data we actually had, and I used AI to work out which datapoints were most useful and how to track them. Chief among them, the support calls that trace back to the old experience, the top one being carriers calling to ask when they'll get paid, which better in-app visibility should cut. The baseline numbers are captured in a doc, with a Claude task scheduled to pull the same cuts on a date down the road.

That is the measurement plan: a real before, a scheduled after, and targets set with the team. Building it to be measured, against targets set in advance, is the discipline most redesigns skip.

Outcome

The app launched in August 2026 and is rolling out to carriers, with roughly 500 on it as of mid-September. The product is live, and measurement is the deliberate next phase: the early signal is positive, and the real read on whether it moved the business comes from the baseline scorecard, pulled once the rollout has run.

What a rework can prove by launch, it did: carriers found it easy to use in testing, the research ruled out what didn't work as clearly as it confirmed what did, and BasicBlock came away with a modernized app it can actually grow on.

That readiness is what matters going forward. The app is set up to take on more without collapsing back into a catch-all, with a clear plan for how the navigation scales as it does. The goal was never a bigger app. It was one that stays legible as it grows.