Last week, I released Page.REST — an API to extract content from any web page as JSON. It got 10 paid users within the first 24 hours, and it was just an idea I scribbled on paper 7 days ago.
Here’s why I built it and what I learned from it.
I left Atlassian a year ago to bootstrap Pragma Labs. We’ve been focusing on building a modern CMS for web teams. While we had some early adopters, traction hasn’t been great. We haven’t found the right the product-market fit. The feeling of being distant from customers created an inertia to ship (“we need this one more thing”).
I started to feel we need to shake up our mindset. We need to taste what’s it like to have people paying us. I challenged myself to get a paid customer within the next 48 hours.
“For a batsman, a decent score — whether it be at club or first-class level — prior to an international series is crucial.”
Ian Chappell #
During my time at Atlassian, there was a quarterly event called ShipIt — you drop whatever you’re currently working on to ship an idea within 24 hours. I decided to try my version of ShipIt. Build something in 24 hours — then get someone to pay for it in next 24 hours.
Find a Minimum Sellable Product
The challenge was to find an idea I can build in 24 hours that’d be enticing for someone to pay at first strike. I thought making a Slack or Trello integration would be a good bet. I knew a few people who had successes from them. However, browsing those marketplaces didn’t instill much confidence. There were already a lot of integrations, and I didn’t stumble on a good niche.
Then I reversed my thinking. If there are a lot of people building these bots, is there anything I can sell to them? I noticed most of these integrations rely on an existing web site as a data source. Public transport timetables, today’s weather, package tracking, menus from local restaurants, dad jokes — all these were built on some existing web site, and most of these niche web sites didn’t have public APIs.
My hypothesis was integration developers waste time reinventing the wheel on extracting content from a site. A solution to save time on this would trigger them to pay.
Think like a consumer
If I followed my usual developer instincts I would have written an API to solve the problem, open source it on GitHub and put a Pateron page to accept donations. I would hope people to donate. Give up hopes after a week and move on to something else. Then in the future, when issues start to pile up I’d go to Twitter to rant about why open source model doesn’t work.
Instead, I wanted to put myself in consumer’s shoes. If I were the consumer what would I need?
- I want to use this through an API.
- I prefer to avoid the troubles of setting up and maintaining it myself.
- Give me a playground to quickly test if the API works for my use case.
- I don’t want to do complicated authentication dance to access the API. Give me an access token I can include in API request.
- Give me some expectation on uptime & availability (will this vanish tomorrow?)
- It’d be good to have a code sample I can copy and modify
- Is there a way to contact the developer and are they responsive?
Personally, I would’ve paid for such a service. I started to believe there should be at least few others out there who’d think like me.
Avoid Rabbit Holes
When I started working on it, I thought I could use Puppeteer, a library to control headless instance of Chrome. But I soon found out headless Chrome didn’t work out of the box in cloud functions (Google Cloud Functions or AWS Lambda). I wanted to stick with cloud functions, so I don’t have to setup infrastructure or worry about scaling & availability.
Instead of wasting time on trying to get Puppeteer to work, I decided to find an alternative solution. I decided jsdom would be good enough for my need. It will not work for sites that use client-side rendering (a la React), but I decided not to worry about it until people complain (which is what I’m doing now since I got people willing to pay for it).
Don’t overthink pricing
After building the API, next challenge was figuring out how I should charge for it. If I can get people to pull out their credit cards after going through the landing page and playing with examples (that’s like max 5–10 minute attention span), then this experiment would be a success.
Having a simple pricing model would make that decision easy. I chose to charge a one time fee in exchange for an access token (which has a generous validity period and a daily limit).
Use early customers to find direction
As an early-stage idea, it was important to figure out how I can evolve it further and understand where the opportunities exist. Does my original hypothesis still hold?
One of the great things about having early customers is they can help you with figuring out this direction. I added OpenGraph support after few early customers requested it. Also, I picked to work on parsing client-side rendered content next as it came up multiple times in feedback.
Also, I started to uncover some interesting niches from early customers. For example, I didn’t know it’d be useful for academic research projects. I started using these insights to fine tune how I can reach more customers.
Try multiple channels to get the word out
In the past, when I do such a side project I would just share it on some mainstream channels like Twitter and Hacker News. If I were lucky, it might get picked up by some influencer and get some viral traction.
However, this time I tried to experiment a bit with the distribution strategy. I plan this to be a continuous exercise which I would iterate based on learnings (currently I set aside 1 hour a day for Page.REST’s distribution experiments).
Rather than going public first, I started promoting it on niche Slack and Facebook groups first. As I got positive signals, I moved to bigger channels like Hacker News and Reddit. Luckily it got picked up by HN audience and reached #10 on the homepage.
In Reddit, it got some traction from /r/sideproject.
My current focus is to find strategies to keep the stream flowing after the deluge.
Nice read, and quite inspiring!
I've looked for services like this when migrating customers from a legacy site to a new CMS. There are quite a few solutions I think, like https://www.apifier.com/ or https://www.diffbot.com/. Those are just two I found when googling "website as api" and I'm quite sure there are more.
A little off topic..
In regards to your CMS - I've worked with Drupal for almost 10 years as a consultant. A lot of customers found us because they had a thought pattern that went something like this:
There have been loads of other nice CMS's throughout the years that cater to developers, but the problem is often that customers don't ask for them.
So - What's your target audience?
Thanks insats!
Most early users to Page.REST came from those two and Parsehub, since it was much more straight forward to use and had a simple pricing model.
Glad you brought it up. Our target audience for Pragma is agencies. We want to help agencies to become more effective in delivering client projects.
The workflow we aim for is sort of the reverse of what you described.
Agency has multiple client projects to build & manage.
Most of these involve assembling common feature sets (a blog, event calendar, contact form, shopping cart, job board, social media sharing, etc.)
We want to make it easy for agencies to extract these common features into components that they can easily reuse.
On most cases, clients want to use SaaS (eg: Shopify for shopping cart) or a homegrown legacy system as the backend. This integration point is what usually differ from project to project. We help to abstract that through a JSON API.
As an agency, what you really get an assembly line you can use for multiple projects with minimal tweaks.
Let me know if you are interested in giving Pragma a try for your agency. You can find my contact details on profile.
I'm not in the agency world anymore (left two years ago), I was just curious since I've spent so much time thinking about CMS's and what not.
My experience is that it's not necessarily the most important thing in the world to cut down time (since that's the source of income..), and developers tend not to like tools that are in the way of actual programming. Control over the codebase and stability is more important than time, which I think is true for most customers too.
Mostly web dev agencies.
Generally, concerns have been around the switching costs.
This was one of the reasons why we started to think Page.REST is a good way to get a foot in the door. We can win trust by solving a smaller use case of agencies first and then convince them for the main product.
Ok I can definitively relate to those concerns.
I don't like the idea relying on an SaaS for the CMS. First you have to convince your customer to pay a subscription for it (..and the values they get are not meant for them but for the agency), and then you have to manage the mess that comes with changes to said SaaS (API updates, cost changes, bankruptcy etc.). Sure - companies do already pay monthly charges for hosting, so the idea of a recurring SaaS cost is not that far off, but you can change hosting quite easily, something that isn't the case for an SaaS CMS. Drupal and Wordpress both offer their "own" hosting solutions (WPE, Acquia), but you don't have to use those in order to use the system.
You've probably done a lot of research, and I don't represent all agencies, so I'm sure you've thought of these things. And maybe your CMS isn't an SaaS? It wasn't 100% clear from the website.
Ah yeah, I purposely didn't mention about pricing and distribution to avoid any early misconceptions. We plan to open source Pragma (but we are waiting till we are clear of product direction - otherwise it'd become a maintenance burden).
This is how we thought of distributing and pricing:
self-hosted: you can buy a complimentary support package (which gives access to private Docker registry & other tools for painless updates and also private stack exchange)
managed: single tenant. We will handle the updates and scaling. (good for larger clients with compliance requirements, agencies save on not having to allocate extra resources to manage them)
cloud (typical SaaS offering): multi tenant. Target audience here is personal users
As someone who ran an agency previously, how does that offering sound to you?
It sounds good. But it would require a lot more for me to even consider using it, simply because there's so much investment that goes into learning a new framework or CMS.
Drupal and Wordpress, although giant pieces of slow software, offer a lot of stuff in terms of access permissions, content workflows etc. Pragma seems, if I'm not mistaken, more like something to use for small presentational websites (simple company websites for example). Is that correct?
Who are you targeting within agencies? Managers or developers/designers (who in turn convince their managers)?
Hey everyone,
Happy answer any questions you have about launching side projects and would be awesome to get your feedback on Page.REST too.
Looks like a nifty service! I'm confused on your pricing "An access token costs $5 and will be valid for one year." Does this mean I can make an unlimited # of API requests for a year?
There will be a daily limit of 100,000 requests (I think that should be good enough for most workloads - but making tweaks as we get more users).
Is there an angle for non devs to use it? Like get a google spreadsheet of the info from a page they want?
BTW, if there's an idea you like to build with Page.REST I can help with that.
Not at the moment. Building a Zapier integration is on my list, but if anyone wants to take a stab at it - feel free to go ahead.
We're you able to get chromium working in a server less architecture? If so, what resources did you find useful on that front? I'm looking into similar concepts but don't want to deal with infrastructure maintenance if I can avoid it :)
Oh yes I did! Released https://www.page.rest#prerender last week.
It is too slow and flaky at the moment. I'm doing few optimizations, will share my findings soon.
Good post, liked your approach of launching quick and dirty.
How is the product doing so far? Were you able to get more potential customers to start paying?
Thanks!
Thanks! Glad to hear you liked the post.
Yes, currently adding 5-6 customers a daily (this post on IndieHackers probably helped to spread the word :)