How to choose a Tech Stack for your SaaS Product

After a successful launch of my latest SaaS Product, FeedHive, I've been asked this question countless times.

What is the Tech Stack of FeedHive, and what were the main considerations for the architecture.

Well, there are - of course - many great solutions.
But let me just break down the Tech Stack and architecture that I chose for this SaaS Product.

Serverless Architecture

FeedHive runs Cloud Native on a fully Serverless Architecture.
When you're bootstrapping a SaaS business, this is an extremely attractive solution, given the pay-per-use pricing model that is associated with Serverless.

This solution is not only saving you time and overhead - it also automatically scales as users come in and demand goes up.

But most importantly - it's also super cheap.
On Amazon Web Services, I pay 0.08$ pr. user, pr. month, on average.

That means, that with the current pricing model of FeedHive, if just 1 out of 62 users is on the paid plan - they will cover the server cost entirely.


All data is stored in DynamoDB.

It's fully managed by AWS, so you don't need a server running to host the database.

This enables extremely high flexibility when it comes to up- and down-scaling your solution.

GraphQL and AppSync

GraphQL is a query language and an alternative to SQL and MySQL.

With GraphQL we can specify exactly what we need and the relation between the data coming from the backend, all in a single request.

AWS has a solution called AppSync which enables you to create a managed GraphqQL layer to securely access, write, and combine data from one or more data sources.

You can link a DynamoDB table as a data source directly, without having to write custom resolver logic.

AppSync is again fully managed, so you don't need a server running your GraphQL API.

Lambda Functions

The entire backend of FeedHive is written in TypeScript, executed in a Node.js environment running on individual Lambda Functions that live in the cloud.

Even though you can link a DynamoDB table as a data source directly using AppSync, you typically need a bit more custom resolver-logic.
Fortunately, you can use Lambda as a data source for AppSync as well.

And once again: The environment that the lambdas are executed in is entirely managed by Amazon Web Services.

The pricing can be a little difficult to figure out a first, since both the duration and memory consumption of a lambda is factored into the price, but essentially, you pay $0.00-00-1667 for every GB-second, and $0.20 pr. one million requests.

User Authentication

Finally, Amazon Web Services has a great solution to handle authentication of your users called Cognito.

With FeedHive, you log in using Twitter, which is a third-party social Identity provider.
Amazon Web Services call this Federation.

After authenticating with a social Identity provider, Cognito will securely map the authenticated user to the roles that are allowed to access the resources on AWS that the user needs to access and use the app.

Optionally, you can create a User Pool, which is a managed user directory, containing all the relevant information about a user.
In this way, you don't have to worry about maintaining a user table in a database yourself.

And here's where it gets really incredible.
AWS runs a library called Amplify, which you can install on your front end and will help you tremendously with user authentication on the client-side.

The Front End

The Front End of FeedHive is written in React.

If you don't know already, React is a JavaScript library for building user interfaces.
It's especially powerful for writing Single Page Applications, or so-called SPAs.

React has amazing TypeScript support as well.
In fact, the entire Front End of FeedHive is written in TypeScript.

For the state management of the application, FeedHive uses Recoil, which is an upcoming atom-based state management library.
It's still in beta, but it is an absolutely awesome alternative to the tedious, "boilerplaty" solutions we currently have out there.

The SPA itself is hosted on S3 and distributed with CloudFront.

Client-Server interaction

As mentioned before, Amplify enables us to integrate a lot of the things we have covered so far.
Most importantly, it makes it really easy to manage authentication using Cognito.

FeedHive authenticates using Twitter as a social identity provider, but the options when combining Amplify and Cognito are more or less limitless.
You can use any Social Identity Provider like Facebook, Google, GitHub and Twitter, but you can also use enterprise identity providers like SAML or OpenID Connect.
You can even use Amazon Web Services' own hosted authentication endpoint for absolute ease.

Testing the Application

I am a huge fan of Test Driven Development, and I use this approach whenever the situation allows me to.

Both the front end and back end of FeedHive contain unit tests written and run by Jest.

Additionally, I'm a huge fan of Cypress, which I use rigorously for both integration tests and full end-to-end testing.

As a part of the deployment pipeline, GitHub Actions will spin up in a hosted test environment which Cypress will use to run end-to-end tests against.


So, finally, I want to mention the deployment setup.

FeedHive uses the Serverless Framework.
This allows us to use infrastructure-as-code for the entire cloud infrastructure.

We can set up both DynamoDB, AppSync, GraphQL Schema, and all our Lambdas in a single yml-file.

It's an incredible tool!


Let's do a quick summary.

The biggest takeaway from the tech stack that I have chosen for FeedHive, is that it's serverless!

  • No need to manage servers.
  • Pay-per-use instead of paying for uptime.
  • Serverless is inherently scalable.
  • Reducing cost.
  • Energy-efficient, and cheap.

If you want more details, you can read the full article here:

I hope you got something out of this write-up.
Feel free to ask any questions in the comments, and I'll answer the best I can!

Good luck with architecting your next SaaS Product 🚀

  1. 3

    Any tips on the github actions/test environment part of it? How are you managing environment variables and serverless variables? I don't have this part of my stack worked out as smoothly as I'd like.

    1. 2

      I'm not sure what @SimonHoiberg is doing--I'm sure it's better than what I'm doing haha--but I've also been running Cypress on GitHub Actions to test a serverless Next.js app (here's the configuration if you're curious).

      For public environment variables (e.g. public identifiers like API endpoints, auth domains), I use .env files that are just included in my repository.

      For private environment variables (e.g. API keys), I set repository-level GitHub secrets that are then automatically included in any GitHub Actions triggered by collaborators.

  2. 2

    Have you been enjoying DynamoDB? I always found myself wrestling with tbe data model, especially for doing searching.

  3. 1

    Thank you very much for your detailed post, I have some questions regarding it:

    How do you prevent overspending on AWS?
    I have built a SaaS app in Azure and so far spending is minimal, however given the nature of serverless I am afraid that spending could increase too quickly in case the product gets too popular and not enough users would be paying users or in case I made a mistake or experienced a DDOS attack.

    How do you accurately measure the total cost pr user?
    Can you provide some examples?
    At the moment I have done rough estimates for example by trying to predict the usage of the services in cloud (Serverless functions runs, API requests, Storage and so on).

    Do you know if AppSync is the same as CosmosDB with GraphQL API (DB) in Azure?

    Lastly how do you secure the communication between mobile apps and the API?

  4. 1

    Thanks for sharing your tech stack!
    It is very interesting to take a look under the hood for such services.

Trending on Indie Hackers
💯 users 💯 days 31 comments Can you give me some feedback? 18 comments HootSuite founder Ryan Holmes discusses product validation platform Kernal 7 comments How to fight back against Google FLoC 6 comments Building in Public for the first time!😲 2 comments How Leave Me Alone App Got Its First 100 Customers 2 comments