I launched Keydesk at the worst possible time of year

There is a version of this post where the timing was a deliberate strategic choice.

It wasn't.

I opened Keydesk up to its first operators in the third week of July. Peak season. The busiest two months of the entire UK campsite and holiday park year.

I did it because the product was ready, and because I had been building for months and badly wanted people using it.

Both of those are reasons.

Neither of them is a strategy.

I planned the launch around my calendar, not theirs

Here is roughly how the thinking went.

The booking journey worked. Pricing worked. Deposits and balances worked. I had spent long enough staring at it on my own, and the only way to find out whether any of it was right was to put it in front of real operators.

So I did.

And what I had actually done, without ever framing it this way to myself, was plan a launch around my readiness rather than their availability.

Which, when you write it down, is a slightly embarrassing thing for someone building software for a seasonal industry to have missed.

What happens when you launch into peak season

Not rejection.

Silence.

I sent 140 emails. I got 7 genuine replies.

That is the part I was not prepared for. I had braced myself for people telling me the product was wrong, or too expensive, or missing the one thing they could not live without. Useful things. Things you can act on.

What I got instead was mostly nothing, plus a handful of people who asked for more information and then went quiet. Not because they had lost interest. Because it was July.

The replies didn't come because the people I was writing to were on site, busy.

They were doing changeover on a Saturday morning with three units still to turn round. They were chasing balances that should have been paid a fortnight ago. They were telling somebody, for the third time that morning, that there was no availability left for the August bank holiday. They were not sitting down to evaluate booking software, because in July nobody is.

I knew this. Genuinely, I knew it.

I just had not connected it to the decision I was actually making.

Then I published a guide explaining exactly why I was wrong

This is the bit that still makes me wince a little.

A few weeks later we published a post about the least disruptive time to switch booking systems. It works through the operator's year properly. When the forward book is at its lowest. When new bookings arrive fastest. Where the slack is.

The answer, for most seasonal sites, is late September into early November.

The worst windows are the middle of the season and the run-up to Easter.

I had written, in a fair amount of detail and with a straight face, a careful explanation of why doing what I had just done was a bad idea.

You can read the guide if you want the full version. I would recommend it. Apparently I needed it.

What the mistake actually gave me

Now the part that has changed how I think about the next twelve months.

Launching into peak season was a bad plan for selling anything. It turned out to be a very good way to learn.

Operators in peak season don't have opinions about software. They have problems.

When someone finally did have ten minutes for me, the conversations were not really about feature lists or roadmaps or how our pricing compares. They were about whatever had gone wrong that week.

One campsite owner told me something I have not stopped thinking about since.

When her site is fully booked, she pays for an extra pitch in her booking system that she cannot sell to anybody. It exists purely as a holding space.

Because when a guest needs to move pitch on a full site, she has to shift one booking into that spare slot, rearrange two or three others around it, then bring the first one back. She would ideally like to do this on a tablet, where she cannot drag and drop, so every one of those moves means opening the booking and changing the pitch by hand.

She was not complaining. She described it the way you describe something you stopped questioning a long time ago.

Sit with what that actually is. Her system charges her per pitch, so every month she pays for a pitch that does not exist, in order to work around a limitation in the software she is already paying for.

She would never have raised that in a demo. It is not a feature request. Nobody writes "better pitch reassignment on a tablet" on a requirements list. It is a small operational detail that only becomes a problem when the site is full and these things happen in practice, which is to say exactly when I happened to be asking.

That is far better input than a calm January demo would ever have produced. In January you get told what people think they want. In August you get shown what actually hurts.

I have not solved her problem yet, and I am not going to pretend otherwise in a blog post. I am telling you about it because it reset what I think the job actually is. Not a longer feature list. Fewer moments in an operator's week where the software turns an ordinary decision into a painful process.

A lot of what we have built and written since came out of conversations like that one: the arrivals and balances work, the peak-season triage guide, the emphasis on amending a booking without breaking three others. None of it came from a roadmap I wrote in the spring. It came from catching people in their worst weeks and listening properly.

And the bigger one: this business does not run on my calendar.

Software developers think in sprints and releases. A two-week cycle feels like a natural unit of time when you are the one writing the code.

Operators think in seasons. Their year has a shape, and that shape is not negotiable. Bookings arrive in January for stays in July. Decisions get made in the autumn. Nothing can be changed in March.

If you are building for an industry, you do not get to keep your own calendar. You adopt theirs.

I think I understood that as a fact before. I understand it now as a constraint, which is a different thing entirely.

What I would do differently, and what I am doing now

If I could rerun it, I would have spent the summer doing exactly what I ended up doing by accident, but on purpose: talking to operators mid-season, watching what broke, building against real pressure, and asking nobody to buy anything.

Then I would have opened properly in late September, when the forward book empties out and people can lift their heads.

So that is roughly what the autumn now looks like. The Early Partner places are still open, deliberately capped at ten, because I would rather have ten operators I can actually look after through a first season than a number I can use to make myself feel good. The Pitchup integration went live this month, which matters far more going into next season's booking curve than it would have in July.

And when someone tells me they are thinking about changing systems, I am now much more likely to say wait until October than to try to sign them in the middle of August.

That costs me something in the short term. But moving systems takes real attention from the operator, not just from me, and in August there is none going spare. Pushing someone to do it anyway would not get them onto Keydesk any faster. It would just give them a worse first month.

The honest position

I got the timing wrong. Not fatally, but genuinely, and for a reason I should have seen coming given the entire premise of the product is understanding how accommodation businesses actually run.

The useful thing about getting something wrong this early is that it is cheap. Nobody was harmed by a quiet July. I lost some momentum and a bit of pride, and I got a much better understanding of my customers' year in exchange, which is a trade I would take again.

The real test is the next few months, when operators finish the season and start thinking about next year. That is the window I should have launched into.

But it is the one I am ready for now.