I lost a pilot customer… because they built it themselves
I lost a pilot customer last week.
Not to a competitor.
They built it themselves.
At first that sounds reasonable.
But what they built was essentially:
- a static list of experiences
- manually curated
- shown at one point in the journey
No real signal capture.
No understanding of what the guest actually wanted.
No timing.
It “worked”.
But it missed the entire opportunity.
Because the real problem isn’t:
👉 “how do we show experiences”
It’s:
👉 “how do we know what this guest is likely to want before and during the stay”
Most demand already exists.
It’s just invisible when decisions are made.
That’s the gap I’m focused on solving.
This happens when the value isn't sticky enough to overcome the 'I could just do this' instinct.
The question worth asking: what would they have had to build to replace you fully - not just the feature, but the ongoing maintenance, updates, and refinement? Usually that gap is larger than they realize when they start.
For solo product builders the response is: make the system more deeply integrated into their existing workflow, or make it clearly cheaper in time-cost than DIY. A pilot customer building their own version is actually signal - it means the problem is real enough to invest in. The question is positioning and stickiness, not viability.
Your comment about customers underestimating the maintenance and refinement gap is spot on.
What I found interesting here is that they didn’t really replace the problem, they replaced the first visible layer of it.
Showing experiences is relatively easy. Understanding intent, timing, changing behaviour, and surfacing opportunities before they become obvious is where the complexity starts to compound.
I actually see their decision as validation that the problem is real enough to invest internal resources into. The bigger question is whether manually curated experiences continue to work once guest expectations, inventory, seasonality, and operational realities start changing around them.
Curious, have you seen many hospitality businesses successfully maintain these kinds of DIY solutions over time, or do they typically hit a ceiling once the manual effort starts growing?
That is a tough pill to swallow, but it’s the ultimate validation that you solved a real problem.
I’m going through this right now with an AGPL open-core model. We chose AGPL specifically so that if a customer wants to 'build it themselves,' they can use our core for free—but if they want the advanced commerce/AI packages, they buy the license. It feels like a middle ground between losing a customer and forcing a proprietary lock-in.
Do you think having an open-source version would have kept them in your ecosystem, or were they strictly looking to avoid a recurring subscription?
That’s actually an interesting angle.
I don’t think the issue was “build vs buy”.
The issue was that they reduced the problem down to content presentation.
A static list of experiences is relatively easy to build.
Understanding guest intent before and during the stay is a very different problem.
That requires:
•. behavioural signals
• timing
• changing context
• operational visibility
• pattern recognition across the guest journey
The danger with internal tools in hospitality is they often solve the visible layer of the problem while missing the intelligence layer underneath it.
So in some ways, it reinforced the exact reason I started building TerraNova in the first place.
I’m also cautious about open-sourcing too early in hospitality because the value isn’t really the interface, it’s the thinking, signal structure, workflow logic, and operational understanding behind it.
That said, I do think there’s probably a future where parts of the ecosystem become more open and interoperable.