My own Headless SAAS - Part 1: Where I begin

In my previous post I described the background and reasons that lead me to begin developing my own SAAS: Tooltap.

Here I want to describe on my first steps and how I decided to focus my effort.

Decision #1 - Main business domain

Or in other words - what do I want to develop?
This was my first area to consider, and it did take me a while, but finally i fixed my mind on Headless SAAS that delivers a set of common-usage APIs.

The reasons for that are:

1. I wanted something within my skillset and passion, and APIs have always been there for me
2. I do frontend, but I really prefer not to. and;
3. During years of leading dev teams, I was walking through so many stylish SAASs, spending my time on understanding their interfaces, registrations and more registrations, just to finally get to the API and take my API keys. I want to create a service that doesn't need all that.
4. I can get to a Headless SAAS MVP within days, not months.
5. The demand for APIs is always increasing, as more SAAS and new software comes to light.

Decision #2 - My minimum viable product

My requirements from an MVP are to be usable and valuable, meaning a user should be able to use it without contacting me, and immediately gain value.
To achieve that I realized I need to build:

1. Basic user management with a Sign up and a method to retrieve auth keys - all based on APIs
2. The actual API service itself - which must be simple but valuable (touch on that later)
3. Documentation - API docs which adhere to OpenAPI standard and manuals to quickly get the developer set up and working with my service.

Decision #3 - The service itself

I was seeking for a service that is an API by nature, relatively easy for me to implement (MVP within days!!) and with a high market demand.
Scrolling through RapidAPI's list of most common APIs, I realized the one answering my requirements is the IP-to-Geolocation API.

IP-to-Geolocation is one of the most commonly used APIs out there, merely because every SAAS or web app with users traffic needs it.
Developers who're required to add IP-to-geo functionality to their apps can develop it in-house, but the better choice is to consume it as a service since it's cheap to consume but expensive to maintain.

Yeah I know. There're gazillion IP-to-Geo services out there.
But again, the demand is always rising, it's classic for an MVP, and I do sincerely believe that once I get more services in, then also this one will gain traffic.

Decision #4 - Tools & Framework

Here the decision was the easiest for me.
A non-popular opinion ahead: Javascript is ugly, node makes me a headache, Python is my true love <3.
There I said it.
I know people like to fancy their React, Vue, Node.js skills nowadays. But as someone who's been here since native JS, through Prototype.js, jQuery, underscore, backbone, handlebars and so on. And then seeing the development of PHP frameworks since PHP3, Ruby and RoR, and so many others...
I have to break this to you once and for all: Django got it spot-on since 2010.
So you guessed it, I'm proudly building on the wonderful Django framework with Python3.9.

Decision #5 - Website and documentation

I'm focusing on building it headless, so to begin with I decided on a no-website.
However, I still need to host some API docs and manuals, and for that I decided on having a documentation repository on Github, and by using github-pages it translates into a website under my own domain.
To ease up the API docs experience I created a workspace on Stoplight, which's hosting my OpenAPI docs.

Next post: On the IP-to-Geo API and my roadmap

---

I'm still adding users as design partners with exclusive early-bird benefits. Contact me if you don't want to miss this opportunity.