From demo to first pilots: four things that break.

A few founders I’m working with are about to take on their first paying customers. The demo works. The question is what happens when ten sites are live and using it for real.

I’ve spent over 30 years in software, 15 of them in hospitality tech, a lot of it watching software grow from a handful of sites to thousands. The same four problems come up nearly every time at this stage.

One is keeping customers’ data apart. With one customer it doesn’t matter. With ten, every query has to know which customer it’s for, and in most early codebases that depends on a developer remembering to add the filter. Miss one and a site can see another site’s bookings. We used to rely on pen testers to catch this. The trouble is a pen test only covers the code as it was that week, and only the parts the testers got to. The next release can break it again. What worked better for us was a common data layer that every query goes through, which checks what’s being requested against the current session. Developers don’t have to remember the filter because they can’t reach the data without it. Then add automated tests that try to read another customer’s data on every endpoint whenever the code changes.

Another is getting real data in. Demo data is clean because the founder made it. A real customer’s export from their old system won’t be. Expect duplicates, missing fields and formats nobody planned for. If importing it means a developer running a script by hand, that won’t hold up past a few customers.

Then there’s Friday and Saturday night. This is the biggest of the four. It’s when hospitality software is under the most load, and when it can least afford to go down. I’ve been through peak-night outages and they’re hellish for everyone involved. Venues can’t see who’s booked in. Support are fielding calls while engineers try to fix a live system under the heaviest load of the week. Most early products have never been tested at that volume. Load test before the first busy weekend, and keep doing it. Production load changes as you add customers, and as the ones you have start using the product differently. Know what breaks first and who’s on call, and give venues a way to keep working while it’s fixed. If your only developer is part-time, there may be nobody watching at all.

And then data protection. Once real guest data is in, you’re processing it on the venue’s behalf. Your first serious customer will ask for a data processing agreement, how deletion works and who your sub-processors are. Have that ready before they ask.

This is most of what I do with founders now: a few days in the code and the setup before the first pilots go live. All four are much cheaper to sort out then than after.