I am Justin Pennington, founder of Infraxio, based in Ponte Vedra. I made the opposite call. I still work in our codebases every week, and I think it is one of the better decisions I have made for the company. This post is less about pride in typing and more about what it actually buys a small software team, and what it costs.

Code review is a conversation, not a sign-off

When a founder only sees architecture diagrams and status reports, review turns into approval theater. Someone presents, the founder nods, and the real tradeoffs stay in the room where the engineers made them.

Working in the same repositories changes that. When I push back on a data model or a queue design, I am pushing back from inside the system, not from a slide. The team can tell the difference. So can I: half the time I am the one who learns something, because the person closest to the code saw an edge case I missed. That two-way trust is hard to fake, and it makes every technical conversation shorter and more honest.

"Can it do that?" deserves a first-hand answer

Clients ask what a system can and cannot do, usually in a meeting, usually with money attached to the answer. A founder who has to say "let me check with the team" on every question adds a round trip to every decision.

Because I build, configure, and test the same tools we ship, I can usually answer on the spot, and when I cannot, I know exactly who to ask and what to ask them. Directness like that is a quiet competitive advantage for a small firm. It saves the client time and it keeps us from promising things the codebase cannot back up.

Your mental model has an expiration date

The tooling around software changes every year. Frameworks, hosting, APIs, and now AI-assisted development have all shifted under our feet in a short window. A founder who stopped coding five years ago is making strategy calls with a five-year-old picture of what is easy, what is hard, and what is now nearly free.

Staying in the code is how I keep that picture current. It shows up in estimates, in which projects we take, in how we staff them, and in which of our own products we decide to build next. Strategy built on stale assumptions about effort is just guessing with confidence.

The cost is real, so I budget for it

None of this is free. Every hour in an editor is an hour not spent on sales, partnerships, or business development, and a founder who codes all day is usually a founder who is avoiding the harder parts of the job.

A few rules keep it in balance for me:

• Focused blocks, not drive-by commits. I code in scheduled stretches on specific projects instead of dipping into every ticket.
• Selective, not everywhere. I pick work where my context helps most: early architecture, tricky integrations, and internal tools. I stay out of the critical path on client deadlines.
• The team owns delivery. Implementation, testing, and rollout belong to the people accountable for them. My commits go through the same review as anyone else's.
• Stop when it becomes a hiding place. If I notice I am reaching for the editor to dodge a hard call or a hard conversation, that is the signal to close it.

What it looks like from Northeast Florida

Building a software company from Ponte Vedra, with clients across St. Johns County, Jacksonville, and beyond, means the team is small enough that every senior person's skills matter. There is no deep bench of architects to hide behind. A founder who can still read a stack trace, review a pull request, and ship a fix is one more experienced engineer on a team where that is never wasted.

That is the real argument. Not that founders must code, but that in a small product studio, stepping away from the work entirely is a choice with costs too. I would rather pay the cost of staying close than the cost of losing touch.

Justin Pennington is founder of Infraxio, a technology company based in Ponte Vedra, Florida. This is a reworked version of an essay that first appeared on his site: Why I Stay Hands-On in the Code. More at penningtonj.com and infraxio.com/justin-pennington.

I am Justin Pennington, founder of Infraxio, based in Ponte Vedra. Across our work with logistics and distribution teams in Northeast Florida and beyond, I keep watching the same pattern: the interior of the warehouse gets a modern WMS and ERP, and the dock door still runs on dry-erase marker.

Inside the building is instrumented. The perimeter is not.

Companies spend serious money on warehouse management, transportation platforms, and ERP upgrades. Inventory moves are scanned. Orders flow through workflows. Nightly financials reconcile. Walk to the dock and you often find a clipboard, a phone number taped to the wall, and tomorrow's appointments written in marker that only one person can see.

That would be a problem if the schedule were purely internal. It is not. An appointment time is a commitment: show up then, and we will be ready to load or unload. When that commitment breaks, detention starts, labor is wasted, and carrier relationships get expensive.

I wrote about this briefly earlier this year. The longer I stay with the problem, the clearer it becomes that the dock schedule is a case study in a wider operations pattern: the handoff between your system and someone else's world is where value leaks fastest and technology shows up last.

Why WMS and ERP projects stop at the four walls

Receiving, putaway, picking, packing, and shipping sit inside your control. Implementation teams can map every step, configure every workflow, and train every user. The dock is different. Drivers show up for twenty minutes and leave. Dispatchers call from a carrier office. 3PL coordinators juggle pickups across facilities. Your WMS vendor did not build for that audience. Your ERP shipping module often assumes the trailer is already at the door.

So the dock stays on paper. The yard gets managed by whoever is outside. The gap between a carefully instrumented interior and an unstructured perimeter widens every time you upgrade the systems inside without touching the edge.

This is rarely a pure technology gap. Dock scheduling tools exist. The practical story is ownership and budget: operations owns the dock, IT owns the WMS, and the dock line item rarely survives the warehouse project. By go-live, the team is tired, the budget is spent, and the whiteboard keeps doing the job it has always done.

Three parties, three schedules, zero coordination

A whiteboard or a desktop spreadsheet fails for a fundamental reason: the appointment is a coordination point, not a private plan. Your facility, the carrier, and often a broker or customer logistics team all need the same live truth.

Without a shared system, each side invents its own. The dispatcher has the time from a phone call. Receiving has whatever is on the board, which may not include the update from an hour ago. Inventory is still looking at ERP expected-receipt dates that never moved after the PO was cut. Trucks arrive to doors that are not ready. Trailers sit in the yard while a slot opened up and nobody told the driver. A reschedule lands in voicemail while the old appointment stays on the board. Labor is staged for a no-show. An early truck has nowhere to go.

That is the same failure mode we designed IFX Hub to reduce at the workflow level: keep tasks, approvals, and records in one place so the people who need to act are looking at the same information. The dock schedule is that principle applied to a high-friction perimeter handoff.

Detention is the invoice. Reputation is the longer bill.

When a carrier arrives on time and the facility is not ready, free time burns down and detention starts. The invoice is real. The quieter cost is reputation. Carriers talk. Facilities that hold drivers past appointment windows get harder to book, or they pay a premium for the same capacity.

Missed appointments cut the other way. A no-show or a multi-hour late arrival leaves a door and a crew staged for nothing. In a tight production or just-in-time inbound flow, that miss cascades. Both detention and missed appointments share a root cause: the schedule is not a live, shared system both sides can see and update. Every deviation becomes a phone call, a delay, and a cost.

Replace the phone queue with a self-service slot

The simplest upgrade is often a self-service appointment link. Instead of hold music and a hope that someone wrote the booking down correctly, the carrier sees open slots and books one. Confirmation is instant. The appointment is in the system the moment it is made, visible to receiving, yard, and inventory.

That is the starting point for DockOps. We are not beginning with a grand reimagining of the entire yard. We are turning the appointment into shared digital structure: scheduling, check-in, and visibility first. Everything useful builds on that data existing.

Structured data first. Then AI on the exceptions.

You cannot automate exception handling on top of a whiteboard. When the schedule is structured, a two-hour late truck can shift the appointment, update the door, notify receiving, and send the driver a new time without a fifteen-minute phone scramble.

That is where AI starts to earn its keep: flag conflicts, suggest door reassignments by trailer type and priority, draft carrier notices, and put the work on a task board with a human review step. The agent needs a system of record. Chaos plus a chat window is still chaos. The same pattern shows up across our custom systems work at Infraxio, whether the shared commitment is a bid deadline in IFX Bid, a campaign send in Growth7, a deliverable in Hub, or a dock appointment.

Build for the person at the door

The hardest part of digitizing the dock is not the software. It is the supervisor or yard jockey who has run this with a clipboard and a radio for years. They will not switch because the front office modernized. They will switch when the tablet is faster than the clipboard.

Every feature has to pass that test. Check-in faster than paper. Schedule view that shows what matters without hunting. Yard status that does not require a walking tour. Features that please the office but slow the dock get bypassed inside a week.

From Ponte Vedra, this is not abstract. Jacksonville and the rest of Northeast Florida sit at the intersection of port, rail, and interstate distribution. Facilities here deal with dock scheduling at real scale. The operators who bring the same discipline to the perimeter that they already have inside the four walls run tighter, treat carriers better, and stop bleeding money at the handoff almost nobody is watching.

The dock door is your last mile

Most last-mile talk focuses on the customer delivery. Inside a facility, the dock door is the last mile: the boundary between your controlled environment and the outside world. Planning meets reality there. Systems meet people who do not work for you. Promises either get kept or broken.

That boundary deserves a real system. The schedule is a promise. The check-in is a handshake. The yard is a shared resource. Manage all of it with the same rigor you bring to everything inside the building.

That is what we are building with DockOps, grounded in the same conviction that drives Infraxio: operational systems work when they meet people where the work actually happens. At the dock, the work is fast, the stakes are real, and the person at the door does not care about your roadmap. They care about getting through the day. Build for that, and adoption follows.

Justin Pennington is founder of Infraxio, a technology company based in Ponte Vedra, Florida. Original essay: Your Dock Schedule Is a Promise You Cannot Keep on a Whiteboard.