This Is The PERFECT Tech Stack For a SaaS Product
Based on Simon Høiberg's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Use DynamoDB for a schema-less, document-friendly data store that can evolve without heavy upfront modeling.
Briefing
A serverless AWS stack built with Pulumi, DynamoDB, AppSync, Cognito, Next.js, Chakra UI, and Amplify can get a SaaS product from zero to a working, authenticated GraphQL app in under an hour—often closer to 10 minutes using a ready boilerplate. The core idea is to avoid server management entirely and rely on managed services and generated scaffolding so early development focuses on product features, not infrastructure plumbing.
The backend is designed around pay-per-use and minimal operational overhead. DynamoDB serves as a schema-less, managed database where teams can store documents in a single field while still indexing entries via keys—making it easy to start simple and evolve the data model later. AppSync then provides a managed GraphQL layer: instead of running a custom API server, developers define a GraphQL schema and map queries to data sources. For authentication, Cognito handles the complexity of user sign-in, password rules, and account recovery, and it integrates cleanly with AppSync.
Infrastructure provisioning is handled with Pulumi, which lets developers define cloud resources as code. Using Pulumi with AWS, the stack can set up the DynamoDB table, AppSync GraphQL endpoint and schema, the Lambda-backed resolver path, and Cognito components (user pool, identity pool, and app client) in one repeatable deployment. The workflow is built for speed: code lives in a monorepo, and GitHub Actions is used for continuous deployment.
On the frontend, Next.js (with TypeScript) provides the application framework, while Chakra UI supplies prebuilt UI components to reduce design and layout work. Amplify connects the UI to the backend and streamlines authentication flows; it also generates GraphQL queries, mutations, and TypeScript types from the AppSync schema, keeping frontend and backend aligned as the schema evolves. For data fetching, the stack uses Apollo Client, with a custom fetch flow that attaches the JWT token to GraphQL requests so AppSync can authorize queries.
Cost concerns are addressed by leaning into serverless primitives: Lambda and AppSync operate on usage, and DynamoDB charges for read/write operations rather than always-on servers. The setup is positioned as “negligible” for early experimentation, with an additional note that AWS offers 1,000 in free credits to start.
After outlining the architecture, the walkthrough demonstrates how to implement it in Pulumi: create a DynamoDB table for user records, define a GraphQL schema with a query (e.g., fetching a user), wire AppSync to a Lambda data source via roles/policies and resolvers, and then configure Cognito pools and identity permissions. Once deployed, Pulumi outputs the IDs and endpoints needed for the frontend. The Next.js app then runs with Amplify configuration, Chakra-based auth pages (sign-in, sign-up, confirmation), and Apollo-powered GraphQL queries.
The practical takeaway is a reusable SaaS boilerplate: a full-stack, authenticated GraphQL app scaffold that can be spun up quickly from a clean slate, then extended by adding more GraphQL fields, resolvers, and UI pages—without redoing the foundational infrastructure each time.
Cornell Notes
The stack targets rapid SaaS startup by combining managed AWS services with infrastructure-as-code. DynamoDB provides a schema-less, document-friendly database; AppSync supplies a managed GraphQL API; Cognito handles authentication; and Lambda acts as the resolver logic behind GraphQL fields. Pulumi provisions all of these resources in a repeatable way, while Next.js plus Chakra UI accelerates the frontend. Amplify connects the frontend to AppSync and Cognito, and it can auto-generate GraphQL types from the schema; Apollo Client then performs authenticated GraphQL queries using JWT tokens. This matters because it shifts effort from server management and custom API plumbing to product development, with usage-based costs instead of always-on infrastructure.
Why does the backend start with DynamoDB instead of a traditional relational database?
How does AppSync reduce the need to run and maintain an API server?
What role does Cognito play, and why is it positioned as the authentication default?
How does Pulumi fit into the stack beyond “deploying things”?
What’s the division of labor between Amplify and Apollo Client on the frontend?
Why is the stack described as “serverless,” and how does that affect cost and operations?
Review Questions
- If you needed to add a new GraphQL query that reads additional fields from DynamoDB, which components would you modify (schema, resolvers, frontend types), and why?
- How would you ensure authenticated GraphQL requests include the correct JWT token when using Apollo Client with AppSync?
- What tradeoffs come from using a schema-less DynamoDB design early, and how does the stack’s approach help manage those tradeoffs?
Key Points
- 1
Use DynamoDB for a schema-less, document-friendly data store that can evolve without heavy upfront modeling.
- 2
Build the API with AppSync by defining a GraphQL schema and mapping resolvers to managed data sources instead of running a custom GraphQL server.
- 3
Rely on Cognito for authentication flows (user pool, identity pool, app client) to avoid building and maintaining login logic.
- 4
Provision everything with Pulumi so DynamoDB, AppSync, Lambda resolver wiring, and Cognito are created repeatably and can be recreated quickly for new SaaS projects.
- 5
Accelerate the frontend with Next.js + Chakra UI, and connect to the backend using Amplify for configuration and auth handling.
- 6
Use Amplify’s schema-driven type generation alongside Apollo Client for GraphQL execution and caching, attaching JWT tokens for authorization.
- 7
Adopt usage-based serverless components to keep early costs low and eliminate ongoing server maintenance work.