What I Learned Running a $30M General Contractor

By the end of the Orlando project, I couldn't tell you what had happened on site the night before.

We were running a TI for a luxury fashion retailer in an Orlando mall and had gone to double shifts, days and nights, to hold the turnover date after falling behind. Retail buildouts run on the brand's timeline, not yours, and the cost of a missed opening lands on us, the GC.

For the past two weeks, every morning had started the same way: an hour spent piecing the night crew's shift back together. What we ordered against what actually got delivered. The inverter that burned out during install at 2 a.m., whether it was being repaired by the electrician or replaced by the supplier, who was absorbing the cost, and who was tracking it. How many hands were on site, how many man-hours, and how much of that was overtime I now owed. Where we stood against the lookahead. What our trades had actually completed versus what I assumed. And what I was supposed to tell the brand's project manager when they called at 9 a.m. asking how the night went. All of it while still running our other active builds across Florida.

I couldn't get a straight answer without three people on the phone. The dailies didn't match the schedule. The manpower reports conflicted. Our delivery records said one thing; the suppliers said another.

The data existed. It was scattered across a stack of tools and a few guys' heads, and none of it connected. After two weeks of this, I knew something had to change. The small tools fit us when we were small and stopped keeping up as we grew. The enterprise platforms that could were priced for billion-dollar builders, not for us. Nothing was built for a mid-sized contractor, and at our size everything was starting to break.

Jack of all trades, master of none

When we started Ernest, I had never set foot on a job site. No family in the trades, no summers swinging a hammer, nobody to shadow. I learned this business the only way left to me: on real jobs, with real money on the line, getting it wrong and fixing it the next time.

The way we learned was to take everything. Warehouse lighting retrofits. QSR ground-ups. Luxury retail TIs. Healthcare renovations. Whatever came through the door, we took it and figured it out, and every job taught us something the last one didn't.

Any contractor will tell you what that much variety does to you. It makes you a jack of all trades and a master of none. If we had planted a flag on one thing, just QSRs, just retail TIs, just healthcare renos, we would have gotten great at it. We never did. We were never the best in any single lane.

But running that many kinds of work back to back, we started to see what most builders never get to see. The details change wildly job to job. The backbone doesn't. Estimating, budgeting, bidding, buyout, scheduling, procurement, turnover: that spine runs the same through a QSR and a hospital reno, especially in commercial. The expertise changes. The process doesn't.

So we never mastered a build type. We mastered the process underneath all of them. That's what saved us, and it's what everything we built later stands on.

Ten tools to run one job

When we were doing a million or two a year, the off-the-shelf stuff worked. ServiceTitan, BuilderTrend, JobTread. Good products, all of them, and fine for us when we were small. Then the business started working, and that's exactly when they stopped.

As we grew, none of it fit. Procore was the obvious move, but it wasn't built for us. Too expensive for our size, aimed at builders way bigger than we were. Everything else was too service, too residential, or made for guys smaller than we'd become. We were stuck in the gap nobody builds for: too big for the small tools, too small to be Procore's customer.

So we did what every mid-sized GC in that gap does. We stitched it together ourselves. On any given day we were running Building Connected for bids, Microsoft Project for the schedule, one tool for dailies, another for photos, another for time tracking, one for material orders, one for rental equipment, a procurement log, a billing tool, and something else for RFIs and submittals. Ten systems to run one job. None of them talked to each other, so somebody had to.

That somebody was the PM, and the math was brutal. We were burning about fifteen hours a week, per PM, per job, just moving data between tools and reconciling it so we could hand the client something that made sense. Fifteen hours a week isn't a workflow problem. It's a person. We were paying most of a full headcount per PM just to keep the software we already paid for in sync. And even after all that, the picture was a day or two stale, which is how you end up standing on a job in Orlando at 9 a.m. with no idea what happened on your own site the night before.

That was the job where I finally admitted this was the thing we had to fix. Not a nuisance, not the cost of doing business. A problem big enough to put us out of business if we let it keep going. And I knew it wasn't getting fixed with the software we'd been running, or with anything else that's been sitting in this industry for twenty-plus years. It definitely wasn't getting fixed by some Stanford grad in Silicon Valley telling me what I needed on my job site when he'd never stood on one. If we wanted it fixed, we were going to have to build it ourselves: the system we needed to run our own jobs.

So we built it ourselves

We built it one piece at a time, around that same spine, from the first estimate all the way to turnover. We weren't trying to reinvent construction. We were trying to get control of our own operation.

The one rule: every piece had to talk to the piece next to it. Our schedule knew our budget. Our field fed our office without anyone retyping a thing. Our daily log rolled straight up into something we could hand an owner without rebuilding it by hand every night.

Then something happened we didn't see coming. We started making more money. Not because we bid any different, but because we stopped leaking hours and stopped finding out about problems a week too late. Same team, more work. We were growing the top line on software we'd built for ourselves, and we kept building.

Somewhere in there, I started talking to other contractors our size, and it hit me: this wasn't just our problem. Everyone had it. They were stuck the same way we'd been, either overpaying for a platform built for a company ten times their size, rigid, no help getting their team to do more, or running the same ten disconnected tools we were because they knew nothing else actually worked. They were paying for it the same way we did too, in the hours their people burned moving data around just to run a single job. Nobody had built for the mid-sized contractor. No product solved the whole job without us wiring it together ourselves on the backend. That's when the system we built to save Ernest became Shackleton, and we decided to put it in front of other GCs instead of keeping it to ourselves.

Then the system started doing the fifteen hours

Once we'd built the system and gotten our teams onto it, the thing that really made our lives a hell of a lot easier was automation. I'll be straight about this, because the hype around AI in construction is exhausting and most of it is nonsense. Agents aren't running your job. They aren't making your calls or your decisions. What they're good at right now is the grunt work a PM should never have been doing by hand in the first place: moving data between systems, reconciling it, flagging what changed on site overnight. That grunt work was the fifteen hours.

When all of it lived in one system instead of ten, the system could do that work itself. We roughly doubled our revenue per PM. Same people, same caliber, close to twice the work each one could carry, because we stopped making them the glue between ten tools and let them go back to running jobs.

That's the whole idea, more than any one feature. The people running the work should own the software, and the software should handle the parts of the job that were never really the job. We built Shackleton because we were contractors first and a software company second, and that order is the entire point. It's the difference between software designed by watching contractors and software designed by being one.

I still think about those mornings in Orlando. The truth is the information was never the problem. We had all of it. We just couldn't get it in one place fast enough to do anything with it. If you're running a contractor in the same gap we were, too big for the small tools, too small for Procore, paying a PM to be the glue between ten systems, that's the exact thing we built Shackleton to kill. If that's your shop, don't start with some giant rollout. Start with one job. Run it the way we wish we could have run Orlando, and see what your PMs do with the fifteen hours back.