In 2016, UK startup Chirp got an unexpected call. It was UK energy provider EDF, enquiring about how it could use Chirp’s technology, which lets users send data over sound, in one of its nuclear power stations. EDF’s innovation delivery team were looking for communication alternatives to wifi and mobile phones in a radio-frequency restriction environment.
It’s far from the only big client which has got in touch with Chirp. The startup also works with an Indian bus service, a kids game company, Microsoft and Arm. What’s more, CEO James Nesfield says new business is “overwhelmingly inbound” – clients are discovering Chirp via its blog, hackathons, social media and developer communities like StackOverflow, rather than the other way around.
Developers can register to gain free access to Chirp’s software design kits (SDKs), and then experiment with uses for the technology, which can transmit audio signals from any device with a speaker to any with a microphone. It’s proving an efficient way to land new business.
Sifted spoke to Chirp CEO James Nesfield about how his eight-person startup has managed to land deals with such a diverse mix of companies. This is an edited version of our conversation.
How are you making it easy for businesses and developers to adopt Chirp?
In 2018, we really opened up the platform. Frankly, that’s to encourage the proliferation and experimentation of where data over sound can be applied.
What we find time and time again is that if you provide the tools and they’re easy to access and use, we have new and creative use cases coming to us that I doubt we would have come up with ourselves.
Taking an example of how we got the nuclear power station project – we weren’t sitting around the table thinking, ‘Wouldn’t [working with] nuclear power stations be great?’. Even if we had had that epiphany, it might have been difficult for us to approach someone like EDF.
It’s incredibly rewarding to see other people building on top of your technology.
How are you helping developers work out how they could use Chirp’s technology?
If you have a tech that’s so broadly applicable, it’s difficult to have a cookie-cutter process whereby you can target engineers in the nuclear space or toy manufacturers or transportation companies. So it’s about making sure the product is use-case agnostic, and that it’s very flexible, down to the way the engineering interface accepts bytes of data – we don’t care if [it’s being used for] ticket validation or an interactive experience on mobile app – we just take the bytes from A to B.
It’s about making it clear to businesses that they can use this in a way that’s useful to them. And that they don’t need any adapters, that there’s no need to change the way their application works.
We also show it working in simple ways, and actually demonstrate data going between two different devices. After you’ve planted that initial seed very clearly and visually, then you can let the imagination of the person you’re talking to take over and apply it to their specific sector. But if you start with just explaining it, or trying to go too in-depth to their specific application, sometimes what you end up doing is inadvertently stepping on a problem their side. Then they might go off it for reasons which are easily solvable.
How do people discover Chirp?
Blog, Twitter, pretty by-the-book inbound marketing stuff. And then because we’re talking about engineers, things like Stack Overflow and GitHub and good old-fashioned SEO.
We also try to do internal hackathons, as well as attend external events.
And we look at packages which allow us to distribute our software through existing communities. We’ve come up with wrappers for our tech which allows it to be very easily integrated into an Amazon Alexa skill or used in a Firebase app. What that allows us to do is shout about Chirp in those communities – and because they’re already formed, it’s an efficient way of getting something tailor made to a predefined group.
What’s the typical journey from initial inbound email to signing a software licence?
A lot of the time the first point of contact is a request for the SDK, which includes an email address which we keep an eye on. Then it’s a case of, at the earliest stages, educating engineers about the capabilities of the tech, and making sure there’s a good product solution fit. We do our best to be clear cut about the capabilities of our tech – what it’s good at and what its limitations are. That initial contact all about making sure that the third party is not trying to do something impossible. And that they are supported and understand how to integrate tech.
That’s all with a view to creating a proof of concept. That’s really important because it not only de-risks the technical side, but also puts a real tangible example in front of decision makers. It demonstrates value as much as it demonstrates technical capabilities. That makes commercial discussions more straight forward, because everyone is looking at the same proof of concept.
We’re not really trying to sell anything – we’re a tool, and that’s why more often than not it’s the engineers who are trying to solve problems who are requesting our SDKs. They’re not requesting them because they woke up that day and thought, ‘Wow data over sound would be cool. I had a Chirp guy on the phone and they were really convincing.’ No, it’s because their boss asked them to make this interaction faster and simpler, to solve a problem, and they think to themselves, ‘I wonder if I can do that with sound? Who’s out there who could facilitate that?’
Often those conversations start at a much more qualified level [because the client is] self-selected.
Image: Martina Paukova