What Subcontractor Payments Taught Me About Building Things

Some problems look small until you look closely, and then they turn into something else entirely. Late payments to subcontractors in Ireland was one of those.

On the surface it's simple. Payments take weeks. Milestones get approved late. Money sits in limbo. A subcontractor waiting on a €5,000 milestone can't pay their crew, can't take the next job, can't plan. So I started designing a tool to fix it: create jobs, set payment rules, approve milestones, release funds automatically. Stripe for payments, Twilio for alerts, a dashboard to watch it all. Ten hours a week saved. Delays cut by some impressive-sounding percentage. The technical part was straightforward, and the value seemed obvious.

Then I looked closer, and the problem wasn't about payments at all. It was about people.

A client holding up a milestone usually isn't doing it for a reason you can automate around. They're doing it out of habit, or caution, or because that's how it's always worked. A subcontractor not sending the final invoice isn't being disorganized — they've been burned before and they're managing the relationship. The €5,000 isn't just money sitting still. It's a signal, a bit of leverage, a piece of an ongoing negotiation that nobody wrote down. No dashboard captures that, because the thing that matters isn't in the workflow. It's underneath it.

And here's the part that actually changed how I think: automating the payment would have changed the behavior. Make payments frictionless and people start gaming the friction you removed. Subcontractors carve work into tiny billable chunks to get paid on a schedule. Clients stop reviewing as carefully because the money moves on its own. You build a tool to smooth a process and the process reshapes itself around the tool until it's something you didn't design. When you try to optimize something people do, the thing that pushes back first isn't the technology. It's the people, adjusting to whatever you changed.

This was the same lesson Memory Escrow taught me, in different clothes. Both ideas were technically buildable. Both solved a problem that was genuinely real. And both misjudged the thing that actually decides whether something works — how people behave when you put it in front of them. A good idea isn't a question of whether you can build it. It's a question of what people do with it, and people do things you didn't predict.

So the payment tool never shipped. But building it wasn't wasted, and this is the thing I want to get right, because it's easy to say as a consolation and harder to mean. The prototype wasn't the product. The prototype was a way of seeing. Mapping the workflows showed me how subcontractors actually balance cash against relationships, where unwritten deals stand in for contracts, how small invisible frictions compound into big ones. I learned more about the system from the tool I didn't ship than I would have from one I did.

I've started thinking about new ideas like a scientist rather than a builder. You don't start with a product. You start with a guess about how people work, and you build something cheap to find out where the guess is wrong. The gap between how you predicted people would act and how they actually act — that gap is the whole prize. It's where the leverage is, where the surprises are, where you see things competitors looking at the same market can't.

Most of the friction in any system is tolerated because it's invisible, or social, or hard to measure. The point of building early isn't to fix it. It's to make it visible long enough to learn which problems are real and which ones you imagined. The payment tool never shipped, and I'm fine with that. It did the only job that mattered, which was to show me I'd misread the problem before I spent a year building for it.