One night in Truro, my partner and I found what looked like a club night on Facebook. It sounded promising, so we went to have a look.
What we found was a tiny pub with a DJ and about ten people in it.
There was nothing wrong with the pub, the DJ or the ten people. The strange bit was how little the information we had found online had told us about what we were actually going to.
That experience stuck with me because it was not unusual. When we travel, we tend to look for things to do rather than simply going to whatever happens to be nearest: live music, DJs, karaoke, somewhere with a bit of life in it. Sometimes you get lucky. Somebody behind the bar knows a place. A taxi driver gives you the useful answer. You find the right local Facebook group or the one Instagram account that actually knows what is happening.
But the process is still oddly primitive for something the internet has supposedly made easy.
A good gig can be two streets away and effectively invisible unless you know where to look. A small pub in a Cornish village can have an excellent act on and almost nobody outside the village would know. The event exists. The information exists. Yet somehow, from the point of view of the person trying to discover it, it barely exists at all.
That frustration became one of the things behind Music Kite.
Three problems that turned out to be connected
Music Kite did not begin with a pristine founder story in which I identified a market gap, drew a triangle on a whiteboard and announced a platform.
There were several problems bothering me at the same time.
One was discovery. My partner and I were constantly piecing together what was happening from Google, Facebook, Instagram, venue websites, ticket sites, local groups and whoever happened to know the area.
Another came from being a musician. If you want to play more gigs, it should not be difficult to understand which venues actually book live music, what kind of acts they use, who books them, or where the opportunities are. Yet much of that knowledge still lives in networks of people rather than dependable public information.
Then I started looking seriously at a mobile food business. Suddenly I was asking another set of apparently unrelated questions: where do vendors trade? Which festivals use outside traders? Which venues have opportunities? Who organises what?
Eventually it became obvious that these were not really separate worlds.
Artists, venues, festivals, vendors and audiences were all circling the same events, while the useful information about those events was scattered across dozens of little systems that rarely agreed with each other.
The consumer problem was: what is actually happening?
The product problem became: how do you know?
That second question turned out to be much harder.
The information is everywhere, which is why it can feel like nowhere
There is no shortage of event information online. That is almost the problem.
A venue has a website. The artist posts on Instagram. Somebody creates a Facebook event. Tickets appear on Eventbrite or another ticketing service. Google may surface structured event information. A local entertainment account reposts the poster. The pub puts the same poster on a board outside. Somebody shares it into a community group.
Each of those can be useful.
Together they can also create a mess.
The date changes in one place but not another. The support act is replaced. A ticket link dies. A cancellation appears on the venue page but the original poster is still circulating. One listing says doors at seven, another says eight, and somebody in the comments confidently says half seven.
If you are trying to go out, you now have a research task.
This is particularly visible in Cornwall because so much good live entertainment happens away from obvious central listings. There are pubs in villages and outlying areas that can have excellent performers on a Friday night, but unless you already follow the right page or know the place, the event can be almost invisible.
That is not because nobody has tried to solve event discovery. Plenty of companies have. Google supports Event structured data and an event search experience. Ticketmaster has substantial event infrastructure. Bandsintown allows artists to publish events and surface them elsewhere. Other UK products are working on grassroots discovery and update-once models.
So the claim is not that nobody else has noticed.
It is that, despite all of that technology, real-world information remains fragmented enough that ordinary people keep falling back on local knowledge and detective work.
Building a discovery product turned into building a research system
Once I started building Music Kite, I discovered that showing event information was the easy part.
The hard part was getting reliable information into the system in the first place.
If you want coverage beyond the obvious major events, you cannot simply connect one giant API and declare the country solved. You end up dealing with venue sites, artist pages, ticket providers, festival programmes, social posts and local sources, all describing overlapping pieces of reality with different levels of quality.
So the research side became a project in its own right. At one point I was running what I remember as roughly thirty-two agents working across different UK research pathways, with stages for collecting, classifying, deduplicating and progressively verifying information.
That number sounds impressive until one of the agents confidently manufactures evidence, at which point it becomes an excellent way of producing problems at scale.
The deeper lesson was that having data is not the same as knowing something.
A record can exist and still be stale. Two records can describe the same event. A source can be real while the conclusion drawn from it is wrong. A venue identity can be correct while the event date attached to it is not.
Discovery depends on trust long before it depends on presentation.
Updating the same event everywhere is its own problem
Then there is the other side of fragmentation: the people responsible for keeping the information current.
An artist changes a gig time and may need to update a website, social accounts, an event platform and whatever else has copied the information. A venue does the same. A promoter does it again.
One real-world fact has several digital lives.
That is why I became interested in Live Hubs and structured distribution inside Music Kite. The idea is not that Music Kite should own the entire internet, or that every artist and venue should abandon the sites they already use. Quite the opposite.
The useful principle is that information should have a sensible home and be reusable. If an entity maintains an event or public information in Music Kite, supported outputs should be able to reflect that information without somebody manually recreating the same fact each time.
That concept is not unique to Music Kite and I would be suspicious of anyone claiming otherwise. The value for me is much simpler: after spending enough time looking at the problem, repeatedly typing the same change into disconnected systems started to look absurd.
Technology should be particularly good at removing that kind of work.
The technology is not the point
There is a danger when you build software around a problem that the software slowly becomes the subject.
I do not actually want people spending more time staring at Music Kite.
The point of the product is almost the opposite.
If somebody can find the band they did not know was playing two miles away, go to the pub, hear them and have a good night, the useful part happened away from the screen.
If a musician finds a venue they would never otherwise have contacted and ends up playing there, the useful part is the gig.
If a vendor finds a festival opportunity, or somebody discovers a place they did not know existed, the software is just the bit that reduced the friction between not knowing and doing something.
That is probably the thread that holds the whole idea together for me.
The internet is astonishingly good at containing information. It is less consistently good at making the right information easy to find, current and trustworthy at the moment somebody actually needs it.
I tend to get interested when I find something that does not work the way I think it should. Sometimes I then make the questionable decision to try to build a better version.
That does not mean the better version always works.
But this particular mess stopped looking like a collection of irritating searches and started looking like something worth working on.
The gig was there all along.
The problem was finding it.