I have always been passionate about rapidly solving problems for businesses, so when I learned of the challenges my friend’s business was facing due software constraints, I was inspired – especially since I was on holidays
I had 2-weeks of break during my 1.5 month long vacation where socialising and travel would be low. I wanted to help in my way and this was going to be a race against time to build and launch a rapid prototype the users would love
TL;DR: I did it and learned 10 key lessions. The UI was not polished but business users cared about the data and improvement to their workflow. We hope to see an uptick in customer experience, revenue and insights in the near future. They are already saving on expensive monthly subscription costs and it is cheaper to hire developers to extend the app. Also, I am working on using Relume, Figma and Next Js to build the front end, more on that in the future
Below are the 10 lessons I learned and I am keen to hear your experience in building and launching fullstack applications
Lesson #1: Your Business, Your Data, Your Software
If you want your business specific insights and customer experience then you need the software to be aligned to your needs vs your business having to work around it. When organisations depend on external service providers this is the compromise they make to keep costs low
My friend’s business relied on a subscription to a major cloud software as a servicd but given the growing needs of the business, the generic SaaS product lacked key features to fulfill these needs. This included data, for example all the customer signups were going to the 3rd party service provider
Small to Medium businesses often have to work around the software systems they bought because the large software vendors will never prioritise client specific features unless there is a large demand for it
Build & iterate on your business specific features as there is high return on investment through Customer Experience and direct revenue from data you own
Lesson #2: Building a polished MVP with backend and a reactive frontend is simpler than before
Gone are the days when launching a SaaS product was a tough task, reserved for those with extensive resources and technical know-how and time!
In this era of technological democratization, tools like Firebase, Linode, Supabase, Next.js, and Figma have simplified the process, making it accessible to a wider range of developers
This post explores the journey of building micro SaaS applications, highlighting the ease and efficiency of using modern development tools.
Lesson #3: Always start with why and who. Understanding users, processes and business needs is a key first step
Avoid the temptation to jump into a tech stack especially if you are an engineer! I wanted to spin up containers, play with streaming etc but had to hold back and start with “who” and “why”. This is similar to the discovery and design we do when building enterprise software at large scale, so why skip this step now?
I started with listening to the core business usecases and started to note down the key personas in the business interaction. Since this was a buyer/seller platform with our friend’s team facilitating in the middle – I had identified 3 key personas who were going to use the software
After replaying my understanding, validating my assumptions and role-playing the business using current software – I had a better appreciate of the what and started to capture key features for each persona
Lesson #4: Don’t skip technical design and test cases, even if this is very early MVP
System design is key to software developer and for our software I kept it lean with simple markdown and UML to hash out how I would solve the specific problem and what I would need.
I used the features I had noted down and started writing high level API design for each. Just in a markdown, rough sketch with Actions, Test Cases and event a list of data entities and attributes
This was crucial as it helped me identify the key backend services I was going to need, the tables with everything mapped it to the features that the business users needed
As I documented this design, I realised that this would become part of the prompt for LLM as I was using ChatGPT to do some of the heavy lifting with code
In all, it took 2 days from business needs to working APIs (locally) with this approach. Using the design as prompts and iterating helped speed up the process
Lesson #5: Build locally and then migrate to a cloud platform service provider
I love how there are so many cloud services there today which enable you to prototype in the cloud, demo it and … well you get locked in! I started with known technologies locally and then picked the right providers for them based on our needs.
Starting locally with a robust backend is crucial. Postgres and Node.js form a formidable pair for this. Postgres offers a powerful, open-source database system, while Node.js brings in a scalable server-side JavaScript environment. Together, they lay a solid foundation for SaaS applications.
For Local Development: I began by setting up a Postgres database and creating a backend with Express.js in Node.js. This setup allowed for full control and the ability to test features quickly.
Lesson #6: Demo early, demo often
I started to show my work early, first the rough sketches in Miro, then Figma and soon a postman demo. Regular briefings and early showcases helped remove ambiguities and gaps while building confidence in our business stakeholders
Lesson #7: Keep your scope tight
The regular showcases and demos helped drive some amazing conversations, however we had to be very clear on the scope and ensure only the “must haves” were delivered in the first release. We kept a backlog of these wonderful ideas for the future and if there was a shining star then we moved out a feature from the initial release to the backlog for this specific feature
We also locked the release feature set early to prevent continuous shuffling of our key priorities
Lesson #8: Pick your PaaS to match your stack and your budget
My next challenge was where to host and then I could just forget about the service & focus on the front end. The choice of platform can significantly impact the development process and the cost.
As I did not want bill shock for me or my friend and wanted features like Identity Management, Email, Database, Document Store / File Upload etc I had to compare the options available. Here are my notes
1. Complexity and Cost: AWS and GCP, while powerful, can be complex and costly for small-scale SaaS products. They require more setup and management effort.
2. Firebase and alternatives: Firebase, known for its real-time database and easy setup, is a popular choice, but then I found Supabase and saw it brings PostgreSQL’s power, giving it an edge in flexibility and scalability. I loved this alternative!
3. The Supabase Advantage: Supabase stands out for its PostgreSQL support, offering robust features like row-level security and powerful querying capabilities, which are invaluable for SaaS applications.
Lesson #9: Using a BaaS like Firebase or Supabase is quite good
I wanted to go the AWS or GCP route but decided to give Supabase (http://supabase.com) a try because I wanted a quick start, free tier, postgres based provider
I started porting my database to supabase and it was quite straight forward. Then I started to integrate Sign-In via Email and Google, Login and Authentcation and “Get my details” for the personas to enable viewing / updating contact details and their other business related details pulled from the relational tables now hosted in supabase
It was incredible because now I had row-level security and an identity management with email services for sending registration notification etc. I was hooked on Backend-as-Service (BaaS) as I had a working prototype with semi production ready code in under 5 days
Read more about Supabase here https://supabase.com and checkout the tutorials on YouTube. Here is a snippet showing how Supabase works
1. Authentication: Supabase simplifies user authentication. Implementing a signup and login system is straightforward with its authentication library.
// Supabase snippet for signup
const { user, error } = await supabase.auth.signUp({ email, password }); // Login snippet const { user, error } = await supabase.auth.signIn({ email, password });
2. Serving Data to Authenticated Users: Once authenticated, fetching and displaying data is efficient with Supabase’s query library.
// Fetch data for authenticated users
const { data, error } = await supabase .from('your_table') .select('*') .eq('user_id', user.id);
Lesson #10: Hand rolling HTML & js based client is cumbersome, use a framework like React, Vue or Next
In my MVP so far, I was using raw HTML and Javascript on the client side and http-server from my command line to demo the Sign Up, Login, User Details etc. This was okay but lacked responsiveness, was cumbersome to code and I really needed to roll my sleeves up and do either React, Vue or Next js based app
In my next post I talk about how I used Figma to design the pages and moved it to a Next Js app and hosted the client side
Conclusion
Building SaaS products today is not just about coding; it’s an enjoyable journey of creation and discovery and can provide rapid returns to small and medium business who are struggling to get to the next level due to software feature constraints. I learned some amazing lessons rolling out this prototpe and we are in business testing after 2 weeks!
Reflecting on this development journey, the contrast with traditional methods is stark. The ease and fun of building a SaaS product with Supabase and Next.js are unparalleled. Starting with local development and transitioning my backend services to Supabase offered insights into the flexibility and power of BaaS
The next feature involves integrating GIS queries to create a platform facilitating discovery between buyers and sellers. This exploration into geospatial data will leverage the robust querying capabilities of Supabase, opening new doors for innovative, location-based services.
Alok Mishra 