Technical Environment

Frontend: The B2B SaaS application's frontend is built using React with TypeScript for type safety and leverages Material UI Joy (MUI) for a consistent and modern user interface.

Backend: The backend utilizes Next.js, a framework for building server-side rendered React applications.

Database: The database is PostgreSQL, by default hosted on Supabase. PostgreSQL provides the flexibility to migrate to other hosting providers in the future. If a document style database is needed for any given function or object we counsel the use of the JSON column format in PostgreSQL.

Testing: Testing employs Jest for unit and integration tests, primarily conducted manually.

Deployment: Deployment is handled through Vercel for the front end and Supabase Edge functions for any needed backend services.

Source Control: GitHub is the chosen platform for source code management.

CI/CD: Continuous integration and continuous deployment are automated using GitHub Actions, streamlining builds, testing, and deployments.

Development Environment: Developers use Cursor as their primary development environment. Code quality is maintained through ESLint, with rulesets tailored for TypeScript and React.

User Authentication: The application supports first-party authentication with username/password combinations. Primary federated authentication is provided via LinkedIn, Google Workspace, or Microsoft Entra. Secondary federated authentication with other social networks will be added over time. The primary focus is getting the users to sign-up using Federated approaches with the username / password as a fallback option. Implementation would use the Firebase standard Authentication models.

Design and User Interface: Figma is used for design and user interface development.

Monitoring: Monitoring is comprehensive, incorporating Google Analytics to track user behavior, Vercel for front end logging and Supabase for backed logging.

Feature Flagging - You can use whatever you like!

Project Management: Project tracking will be managed, initially, through included GitHub Projects. We expect to migrate to Jira as we get more scale.

Product and Development Documentation - Confluence and this website.

Development Users: Development users are managed through GitHub.

LLMs: Administration of Large Language Models (LLMs) involves setting up and tracking separate accounts per company, typically for Gemini, ChatGPT, and Perplexity. Vercel's AI libraries are used for easy cross LLM movement.

In System Messaging: Native support is provided in Baseplate for user notifications and messaging.

Third Party API Administration: API account setup and tracking for application-specific functions are handled as needed. We recommend wrapping all third party service API calls in Supabase edge functions to protect credentials.

Rationale for Technical Environment

This section outlines the reasoning behind the key technology choices for the technical environment. Each decision was made to balance scalability, developer productivity, maintainability, and cost-effectiveness. If any of these choices need to be revisited in the future due to evolving requirements, performance concerns, or cost constraints, this document serves as a reference point for why the decisions were originally made.

React + Node.js + Material UI

The frontend of our SaaS application is built with React and Material UI, while the backend utilizes Node.js. This choice was driven by several key factors:

Industry-Standard Technologies: React, Node.js, and Material UI are widely used across the software development industry, ensuring long-term support and community-driven improvements.
Developer Availability: These technologies have extensive adoption, making it easy to find and onboard developers with relevant experience.
Standardized Development Environment: Using React and Node.js enables us to maintain a common source code layout and best practices, reducing the learning curve for new developers.
Modern and Developer-Friendly: React and Material UI offer a sleek, component-based approach to UI development, while Node.js ensures flexibility and efficiency in handling backend services. This stack attracts developers who are excited to work with modern, in-demand technologies.

Why We Chose PostgreSQL as the Database

We selected PostgreSQL as the primary database due to its structured approach, flexibility, and long-term scalability:

Structured Data Model: PostgreSQL enforces schema consistency, ensuring that the data model remains well-organized and thoughtfully architected.
Flexible for Unstructured Data: While PostgreSQL is a relational database, it includes support for JSON fields, allowing us to store and query semi-structured data when needed, without the overhead of a separate document database.
Optimized Performance: PostgreSQL offers powerful indexing, structured queries, and optimized performance for complex queries, making it a solid choice for analytics and transactional workloads.
Forces Thoughtful Design: By requiring schema definitions, PostgreSQL encourages developers to plan data structures carefully, leading to better long-term maintainability and fewer technical debt issues.

Why We Chose Supabase

We chose Supabase because it gives us a complete, open-source backend platform with minimal operational overhead. It provides native PostgreSQL hosting with built-in connection pooling and garbage collection—eliminating the need to write and manage complex code for database connections, which can otherwise become a black hole of time and energy. Supabase also offers logical container files that we can run anywhere, giving us flexibility across environments while maintaining consistency.

By using Supabase's managed hosting, we materially simplify our deployment process—everything can be hosted and run within the Supabase infrastructure, allowing us to focus on building product instead of maintaining infrastructure. It’s a modern stack that aligns perfectly with our goal of shipping fast, iterating quickly, and avoiding unnecessary operational complexity.

Infrastructure Features

Configuration & Feature Flags
- Central configuration management via Supabase and Vercel
- Toggle new features, run beta tests, or enable/disable modules at runtime.
Logging & Monitoring
- Consistent log collection via Vercel (front end) or Supabase (backend)
- Real-time performance stats via Vercel (front end) and Supabase (backend)
- Default logging of user changes to system data
Developer Documentation & Example Apps
- GitHub wiki with code snippets, architecture diagrams, best practices.
- Example React + MUI Joy application showcasing typical use of APIs.
LLM Query Framework
- Standardized methods for querying different LLMs and storing query text and responses
- Our experience is that the ability to debug LLM responses and detect common error states is key
- This would give us insight into what was queried and what the response was across all queries
Customer / License Limits - Basic functions for defining limits on system use based on some system scope

Development and Production Environments

We maintain three distinct environments—Dev, Test, and Production—to support a clean and efficient development workflow while ensuring system reliability and integrity.

Dev (Local Development): Developers run Supabase locally using self-hosted containers. This setup allows for rapid iteration and debugging without impacting shared resources. Local environments mirror production schemas closely, and changes can be tested in isolation before promotion.
Test (Staging Environment): This environment runs on Supabase’s managed hosting and is treated as a pre-production environment. It mirrors the Production environment in both infrastructure and data structure. Test is used for QA, UAT, and integration testing, allowing us to validate releases in a realistic setting before they go live.
Production: Our live environment is also hosted on Supabase’s production infrastructure. This is where all customer-facing traffic is routed. By standardizing on Supabase for both Test and Production, we eliminate inconsistencies across environments and reduce deployment risk.

This tiered setup gives us the flexibility to build locally, validate thoroughly, and deploy with confidence.

Why We Use Supabase for Production

One of the things we like about Supabase is that you can self-host it. That flexibility is part of what drew us to the platform in the first place—it lets us run the full stack locally in development, and even gives us the option to move off their cloud if we ever need to.

That said, for production environments, using Supabase’s managed hosting is the better choice. From a security and scalability perspective, it’s simply more robust. Supabase provides hardened infrastructure, built-in monitoring, automated backups, and enterprise-grade connection pooling out of the box. Those are all things we’d otherwise have to build, maintain, and continually audit ourselves—costing time, money, and focus that we’d rather spend on delivering value to users.

Supabase lets us keep control and portability while offloading the operational complexity that comes with managing production infrastructure. Best of both worlds.