WordPress has run out of excuses (says someone who lived off it for ten years)
A custom Laravel build used to be a luxury costing thousands. With AI it isn't anymore, and using your website as a brochure is starting to get expensive.
Leer más →A developer was giving us his weekends, and I asked him to stop working on the one thing that brought in money. It made sense. Here's why.
In January I asked a developer to stop working on payments.
Yes, payments. The part that brings in the money.
Here's what happened.
We were building our booking engine in the gaps. Client work during the week. At weekends, an outside developer giving up his own. We didn't have a product team. We had borrowed Saturdays and Sundays.
Two things were on his list. Calendar sync, so a property's availability is the same on every channel it sells on. And card payments through the bank's virtual POS.
Payments were giving us grief. A lot of it. And in the end the problem wasn't the code.
It was the certificate.
Hours staring at code to find out the fault lived in the most boring layer of all. Like searching the whole house for your keys and finding them in the door.
The easy move was to push on payments. It's the "real" feature. The one that sounds good in a sales meeting: "Can guests pay online?"
But meanwhile, in mid-January, the booking engine for a rural masia was ready. Connected by API to one of the big booking platforms. All that was left was to show the owner and switch it on.
That's when a booking engine stops being a website feature. It becomes infrastructure.
If someone books on the platform, the date closes on the owner's own site. If someone books direct, the platform knows. When that fails, you don't lose a payment. You get two families with their suitcases outside the same room.
A payment problem has workarounds. Ask for a transfer. Charge on arrival. Annoying, but nobody's holiday is ruined.
A double booking has no workaround. It's a phone call nobody wants to make.
So I asked him to park payments and put everything into calendars.
Build first the part that hurts most when it fails, not the part that looks best in a demo.
Until I said it clearly, he had both things down for the same weekend. Fair enough. Nobody had told him which came first.
When someone gives you their weekends, setting the priority is your job. Not theirs. Two half-finished features are worth less than one finished one.
And clients ask for what they can imagine. Nobody imagines a sync failure until it happens to them. My job is to imagine it first.
Payments have to work, yes. But they can be manual for a while. Calendars can't: nobody syncs by hand in real time.
When nobody funds you, this isn't a detail. The services pay for the product, and that only works if every product hour goes to what matters most. You can't do it all at once. The sequence is the strategy.
I asked him to stop working on the part that brings in the money.
Because a full calendar with manual payments is a nuisance. A broken calendar is a disaster.
P.S. Before anyone touches a line of code, check the certificate. I say this from experience, and from several of someone else's weekends.