DEV Community

Sean Er
Sean Er

Posted on

Why we started sampleapp.ai

On December 15, 2024, 1 month away from our Alchemist Accelerator Demo Day, we took a leap of faith, and made the decision to pivot from our previous startup, API-Rex (an AI Documentation Startup) to our current company sampleapp.ai, setting ourselves on the path to somehow, find traction before demo day. This decision followed after a gruelling few months of debate between my cofounder and me about the direction of the company and what our previous startup stood for.

We were working on API-Rex because we felt that developers should not waste time writing documentation and should focus on shipping features. This was following my experience at ByteDance where I was tasked to document a system to set up redundancy, and I ended up spending 3 whole months working on it before being able to get any engineering work done. The process was endless and I do not wish it up anyone else to have gone through what I went through.

Why we pivoted

During the time of our previous startup, we realised that there were 3 fundamental problems with documentation

  1. Documentation is an afterthought
  2. Open source documentation
  3. Use cases for API was a bigger problem

Documentation is an afterthought

This meant that companies do not invest enough time or hours into making sure their APIs and SDKs are well documented. Engineers rather ship features than write documentation and because of this, documentation is often outdated.

We thought that this was a problem but often it is not, because when documentation is outdated, there are systems in place to request for a support ticket to then subsequently resolve it. It was a problem which could be resolved quickly.

However, this should not be the case, exempted by companies like Stripe and Clerk, where from the perspective of a developer, high quality documentation and developer experience can often be one of the key differentiating factor between deciding to go with a company. Therefore, we still strongly believe that documentation should be a first class citizen, but it was tough to convince companies to feel the same way.

Open source documentation

The wide availability of incredible open source documentation tools like Docusaurus and Scalar that not only look great, but work great, meant that the base price we can charge is $0, and we would have to upsell with a ton of other features like custom domain and custom CSS. Coupled with the fact that there was already a ton of incredible companies like Gitbook, ReadMe and Mintlify, that are pushing the documentation space forwards, we found it really difficult to make people care enough to price our product competitively.

Often, we found ourselves having to convince companies and explain our value, and finding that they still did not see it.

Because of the overly saturated market that we were in, we wanted to explore other solutions elsewhere.

Use cases for APIs

A great analogy I came across is, APIs are the plumbing and use cases are the living room.

Often, what helps an API and SDK gain mass adoption is not just the fantastic and reliable documentation that companies have, but the use cases that come with it. This is why companies like Pinecone have a dedicated sample app section on their documentation, why Stripe spends a ton of engineering resources building up different apps for developers to easily onboard onto Stripe, and why founders and developer relations engineers like Eric from Firecrawl and Hassan from Together.ai spend days every week, building up sample applications to show developers how to use their APIs and SDKs.

Just a few days ago, Eric - CEO of Firecrawl - announced that they were closing down their previous startup, Mendable in this article and Hassan was promoted to the Director of Developer Relations in this post, both of whom post sample applications they build on a daily basis. These recent posts are testament to the prolific impact of sample applications on the adoption of Firecrawl and Together.ai.

To break it down, sample applications are crucial for mass adoption of APIs and SDKs because they help people understand the value of an API and SDK.

The start of sampleapp.ai

We went on to interview a ton of developer relations engineers and founders, and besides the time consuming nature of building sample applications, they shared with us other insights too. It fundamentally boiled down to 3 things. Besides just building sample applications, companies wanted

  1. Faster developer onboarding
  2. Analytics to understand what people are building with their APIs so that they can craft their marketing messaging and know what apps to promote
  3. Use cases

The early validation that we got from developer relations engineers and founders suggested that this was a problem people cared about a lot more about, and we decided to create sampleapp.ai

We built a prompt to app builder trained on a company’s API and we called it sampleapp.ai. With this tool, any company can use it to build sample applications trained on their API and SDK Documentation quickly, and they can expose it to the public, letting developers build on their API and SDK. Based on our early testing, developers have successfully onboarded themselves into APIs they had no context of in around 3 minutes.

Try sampleapp.ai

At sampleapp.ai, we believe that in this age of AI, developer onboarding should be in minutes, not hours or even days, and we are committed to helping improve the developer onboarding experience for companies that work with.

If you have an API or SDK that your company is trying to promote and you want the fastest onboarding experience for your developers, drop me a text on LinkedIn

Top comments (0)