In 2014 I was working for an agritech startup whilst it was still in the 0 —> 1 phase. One of the challenges that we faced was that as a mapping tool for farmers, we needed to track the location of the farmer as they moved around the field. This consumed a lot of power. However, because the farmer was walking in a field, they were necessarily away from a power source for pretty much all of that time. That meant that we were seeing phone batteries dying 75% through a farm walk - not a great look for us, and not great for the farmer who is stuck in the field with a dead phone.

We spent a great deal of time working on potential solutions to this, most of which only provided incremental gains. The heart of the problem was that we simply didn’t know enough about how to reduce the power consumed by the GPS whilst keeping tracking accurate.

Frustrated, we decided to try speaking to the author of one of the open source packages that we were using to log GPS locations and see if they had any knowledge of ways to allieviate the power drain. We tracked down the author’s twitter, tweeted a plea to them, got an email address and eventually arranged a 30 minute video call explaining the issues we were seeing.

The call was a revelation. We had, accidentally, stumbled upon the one person in the world who had made it almost their life’s mission to know everything about GPS. Their depth of knowledge on not only their package implementation, but also what was happening on the device at the lowest level was astonishing.

We came away from the call blown away and willingly paypal’ed their fee across to them. If I’d known the value of that call to the company before the call I’d have paid 5 times as much. 30 minutes and $250 spent on the phone to them advanced the project no less than 6 weeks.

---

There are points in almost every project that require domain expertise outside of the developer or engineer’s own knowledge. We had great developers and ready access to farmers at this startup, but we didn’t have someone who specialised in the intricacies of on-device GPS, because well, why would we? It was a small yet fundamental component, but only one piece of a much larger puzzle being solved by 6 people racing to get a product to market.

It was after this call that I first started mulling the idea of building a community of experts that were readily accessible by those that needed hyper specific expertise. I’d come across this type of issue again and again over the next 8 years, and became comfortable with sending an email to authors of packages but often found that they had no real mechanism of providing paid support on a one-off basis, if at all.

Then in late-summer 2021 I saw a tweet from railway.app founded Jake Cooper:

https://twitter.com/JustJake/status/1440571055739793413

Cameo for Engineers. Interesting.

What if a marketplace existed that allowed engineers to be hyper specific about their provable expertise? Not like Fiverr or Upwork where anyone can jump in and fight over projects, but where the experts need to have demonstrated that they really know their stuff. No technical tests, just a requirement that they demonstrate their technical chops by contributing to the projects that they are experts on.

I started working on an application that I’d want to use; where I could type in a package and find a developer with the specific expertise that I needed to solve my problem or implement a package, and pay them properly for their time and knowledge.

From talking with the open source community I realised that there was a greater opportunity, to provide a turnkey support system for open source projects that could then directly support the community. And so Ringer was born.

I hope you like it and that it’s useful to you, both in sharing your own expertise and learning from others. Ringer. It’s sort of like Cameo, but for Engineers.