1
0 Comments

Need advice on validating an API-first business model

I was recently browsing GGV Capital's index of API-first businesses. While there are obvious examples, like Stripe for payments and Twilio for SMS, there are also more niche examples, such as Duffel for booking flights. This inspired me to try and think about problems I've encountered personally through that lens, and made the idea of starting an API-first product seem less intimidating.

I settled on pursuing a need I bumped into on my last project. We wanted to gamify aspects of the core UX, but wanted the experience to feel native and didn't have the resources to invest in building out the infrastructure to support the complex use cases we were envisioning. We would have jumped on a product that provides gamification-as-a-service, but existing solutions all appeared to be catering to enterprise customers, or purpose built for e-commerce marketing. I know solving this problem would address my own need, but how do I go about validating whether a broader market exists?

So far, I've set up a landing page with a brief summary of the offer and a waitlist opt-in. I setup a somewhat arbitrary feature matrix to gauge interest on some possible pricing strategies. I'm not sure whether its too soon to be testing pricing, or if it's a legitimate validation signal. Will our target audience (entrepreneurs and engineers) pass it off as vaporware, or find the transparency appealing?

My engineering partner and I have some ideas for how the API should be structured, but we want to be sure there is sufficient interest before investing too heavily in a fully functioning SDK. What's the best way to overcome this 🐓/🥚 scenario?

Any advice from fellow hackers who have launched API-first businesses? Thanks!

on January 6, 2023