We stopped customising our booking engine, with one exception

For years, "yes" felt like the safe answer.

In November I sent a proposal full of "no".

It was the most honest one I'd written in a long time.

A rural lodging wanted to renew its website, with a booking engine and a channel manager. After a phone call, I sent them what I called the most honest proposal we could make. A dedicated server. The booking engine in its latest official version, the same for everyone, with no custom changes that would block future updates. And a clear list of what would work differently from before.

I explained why plainly: any customisation of the booking engine would leave us stuck again.

Some of the things they'd told us were essential became a plain "not possible" on that list. Others changed how they work. Gift vouchers would still be sold the same way, but redeemed at the end of checkout, like any standard discount code.

A few days later we sent the quote.

How a product turns back into a pile of projects

Every customisation feels small when you agree to it. A field here. A special rule there. A different flow for one client's vouchers.

Then the product moves forward, and that client is stuck on an old version because their special rule would break with the update. Now you're maintaining two products. Then three.

It's like those kitchens where every drawer has a "trick". Lift it slightly, push left, then pull. Fine for the owner. A nightmare for anyone else, forever.

That "stuck again" in my proposal wasn't theoretical. It's how a product slowly turns back into a pile of custom projects.

Every customisation you sell today is an update you can't ship tomorrow.

The one exception, with its price tag

Saying no to a paying client still feels uncomfortable. We started with 300 € in 2014, and for a long time "yes" felt safe. Part of me worries a client will walk away. Part of me wonders if it sounds arrogant.

But I think the alternative is worse. Saying yes and then, months later, explaining why their engine can't get the improvements everyone else has. That's not service. That's a trap with a nice invoice at the start.

And yes, even here there was one exception. The client didn't want guests to lose the leftover balance of a voucher in low season. We agreed to make that possible by embedding a piece of code, and told them clearly we'd need to coordinate between updates to keep it working.

That's the honest version of an exception. Small, named, and with its cost written down.

The bigger question stays, though. If one lodging needs something, others probably do too. Then it isn't a customisation. It's a feature request, and it belongs in the product for everyone or not at all. The website can be custom. The server can be dedicated. The engine stays the same for everyone.

That same month I also spent a week trying to get a Verifactu test certificate from the tax agency. Attachments rejected, rules about links and images, and a few other hurdles. It made me appreciate how simple my own rule is.

We don't have a large team to maintain twenty versions of the same engine. We have Yeray, me, and a product we want to keep improving. Patient money only works if the product stays light enough to carry.

I used to think saying yes to every request was good service.

Now I think good service is telling the client, before they sign, what we won't do.

P.S. Writing "not possible" in a proposal is much easier than saying "it broke after the update" on the phone. I've tried both.