Guide›Code & export
Code & exportIntermediate9 min

Customize your stack

Myndlab defaults are sensible, but you can pick any combination of frontend framework, backend language, and database to match your team's existing skills.

The default stack

When you don't specify a stack in your prompt, Myndlab generates code using its default combination: a React frontend built with Vite, a FastAPI backend written in Python, and a PostgreSQL database. This trio was chosen because it covers the widest range of use cases, has excellent library ecosystems in all three layers, and is well-understood by Myndlab's code generation models.

The default stack is a solid choice for the vast majority of SaaS apps, internal tools, and data-driven dashboards. You only need to deviate from it if your team has a specific skills requirement, an existing codebase you're building alongside, or a deployment constraint that favours a different runtime.

ℹ
Note.The stack you choose affects which libraries Myndlab imports, how authentication is scaffolded, how database migrations are generated, and which deployment targets are available. Changing it later costs credits because substantial parts of the codebase need to be regenerated. Pick your stack before your first code-gen pass.

Choosing a frontend

Myndlab supports two frontend options: React with Vite (the default) and Next.js. Here is when to reach for each:

1
React + Vite — best for SPAs and internal tools
React + Vite is ideal when your app lives behind a login and doesn't need to rank in search engines. Internal dashboards, admin panels, customer portals, and data-heavy applications are all great fits. Vite's development server is fast, the build output is a static bundle you can serve from any CDN, and the generated code is easy to understand and extend. This is the default for good reason.
2
Next.js — best for public-facing products
Choose Next.js when your app has pages that need to be indexed by search engines, or when you want server-side rendering for fast initial page loads on slow connections. Marketing pages, blogs, e-commerce storefronts, and SaaS landing pages paired with an authenticated dashboard are the classic Next.js use cases. Myndlab generates App Router code (Next.js 14+) and co-locates API routes in the same project, reducing the need for a separate backend service for simple data operations.
💡
Tip.If you're building a SaaS with both a public marketing site and an authenticated app section, choose Next.js. Myndlab will scaffold the marketing pages as static routes and the app section as client components behind a middleware-protected layout — all in a single project.

Choosing a backend

Myndlab can generate backend code in three languages and frameworks. Each has a distinct profile:

1
FastAPI (Python) — default, best for AI-heavy apps
FastAPI is Myndlab's default backend. It's the right choice when your app calls OpenAI, Anthropic, HuggingFace, or any other Python-native AI library, because those libraries are Python-first and the integration is seamless. FastAPI also has excellent support for async operations, automatic OpenAPI docs generation, and Pydantic-based request validation. If your team knows Python or your app does anything with machine learning or data processing, keep the default.
2
Express (Node.js/TypeScript) — best for JS teams
Choose Express when your team is JavaScript or TypeScript native and wants to share types between the frontend and backend. Express is the right call for real-time features (websockets, server-sent events), when you're using a JavaScript-first database client like Prisma, or when you want to avoid context-switching between Python and TypeScript in the same codebase. Myndlab generates fully typed TypeScript Express code with Zod validation schemas that can be shared with the frontend.
3
Go Fiber — best for high-throughput APIs
Go Fiber is the highest-performance option. Choose it when your API will handle a very large number of concurrent requests, when you're deploying to resource-constrained environments (small VMs, edge nodes), or when binary size and startup time matter (container-heavy architectures). Go Fiber is more verbose than FastAPI or Express, but the generated code is explicit, easy to audit, and produces extremely lean Docker images. Go is also the right choice for GCC or data-sovereignty deployments where a single self-contained binary simplifies operations.
ℹ
Note.If you choose Next.js as your frontend, Myndlab can optionally skip generating a separate backend entirely and use Next.js API routes for data operations. This works well for simpler apps. Mention 'no separate backend' in your prompt to use this mode.

Choosing a database

Database choice affects your schema generation, migration tooling, and hosting options. Myndlab supports three primary options:

1
PostgreSQL — default, most versatile
PostgreSQL is the default and the right choice for the vast majority of apps. It handles relational data, JSON documents, and full-text search in a single engine. Myndlab generates Alembic migrations (FastAPI), Prisma migrations (Express/Next.js), or raw SQL migration files (Go Fiber), depending on your backend. PostgreSQL is supported by every major managed hosting provider: Supabase, Railway, Render, Neon, AWS RDS, and your own VPS.
2
MySQL — best for existing MySQL infrastructure
Choose MySQL if you're building alongside an existing MySQL database, or if your team's expertise is MySQL-specific. Myndlab generates MySQL-compatible schema and migration files. Note that MySQL has a few limitations compared to PostgreSQL: no native UUID type (use VARCHAR(36)), no JSONB with indexing, and slightly different full-text search capabilities. For greenfield projects, PostgreSQL is generally preferred.
3
Supabase — best for fast iteration with built-ins
Supabase is a managed Postgres platform that bundles authentication, real-time subscriptions, storage, and auto-generated REST/GraphQL APIs on top of a standard PostgreSQL database. Choose it when you want to move fast and don't want to build auth from scratch, or when you need real-time features (live-updating lists, collaborative editing) without writing websocket code. Myndlab generates Supabase client code, uses Supabase Auth instead of a custom JWT layer, and can leverage Supabase Storage for file uploads. Note: Supabase is a managed cloud service and is not available for on-premise or air-gapped deployments.

Specifying stack in a prompt

The simplest way to set your stack is to include a one-line Stack declaration in your prompt. Myndlab recognises this pattern and uses it to configure all three layers before generating any code.

text
Build a project management tool for software agencies.

Stack: Next.js frontend, Express backend, Supabase database.

Users: Agency owners and developers.
- Owners can create client projects, set budgets, and view reports.
- Developers are assigned to projects and log time against tasks.

Data: Clients have many Projects. Projects have many Tasks and
TimeEntries. TimeEntries belong to a Developer and a Task.

The main view is a weekly time-tracking grid. Include a monthly
burn-rate chart on the Owner dashboard.

You can also be more explicit if you have additional constraints:

text
Stack: Next.js 14 App Router frontend, Go Fiber backend,
PostgreSQL 16 database (self-hosted, not managed Supabase).
Deploy target: single VPS running Docker Compose.
No third-party auth providers — use JWT with refresh tokens.
💡
Tip.If you mention a stack in your prompt but Myndlab can't fulfil part of it (for example, a database engine it doesn't yet support), it will flag this in the spec review step and suggest the closest available alternative. You'll always have a chance to confirm or change the stack before code generation begins.

Changing stack mid-project

Changing your stack after you've already generated code is possible, but it comes with real costs in both credits and manual effort. The degree of disruption depends on which layer you're changing:

1
Switching frontend framework
Going from React + Vite to Next.js (or vice versa) requires regenerating all frontend files. Backend and database files are unaffected. Expect to spend 30–70% of the original frontend generation cost, depending on how many pages and components your app has.
2
Switching backend language
Going from FastAPI to Express or Go Fiber requires regenerating all backend files. Frontend and database schema files are unaffected, though the generated API client in the frontend will need to be updated. Expect a similar cost to regenerating the backend from scratch.
3
Switching database engine
This is the most disruptive change. Going from PostgreSQL to MySQL, or from self-hosted Postgres to Supabase, requires regenerating migrations, updating the ORM/client configuration, and potentially changing how authentication is scaffolded. If you are switching from a relational DB to Supabase, any custom auth code will also be replaced. This effectively counts as a near-full regeneration. If you are unsure about your database choice, decide before your first code-gen pass.
⚠
Watch out.Switching the database engine mid-project does not automatically migrate your existing data. Myndlab generates new migration files for the new database engine, but moving data from your old database to the new one requires a manual migration script. Plan for this work before initiating a database switch.

GCC: sovereign Postgres vs managed Supabase

For teams operating under GCC (Gulf Cooperation Council) data residency requirements, UAE data protection laws, or similar regional compliance frameworks, database hosting location is a material concern. Supabase's managed cloud runs on AWS regions that may not meet in-country data residency requirements for sensitive data categories.

For GCC-region deployments, Myndlab recommends the following configuration:

1
Use sovereign Postgres on a UAE-based VPS
Self-host PostgreSQL on a server physically located in a compliant data centre (for example, AWS me-central-1 in UAE, Microsoft Azure UAE North, or a local provider like du or Etisalat Data Centres). Myndlab generates standard PostgreSQL schema and migration files that work identically on managed and self-hosted instances.
2
Use Go Fiber or FastAPI as the backend
Both produce self-contained deployables (a single Go binary or a Python app in a Docker container) that are straightforward to run on a sovereign VPS. Avoid the Next.js-only (no separate backend) mode for GCC deployments — it makes it harder to enforce data handling boundaries.
3
Replace Supabase Auth with a self-hosted JWT layer
In your prompt, specify 'No Supabase Auth — use JWT with refresh tokens stored in httpOnly cookies.' Myndlab will scaffold a complete JWT authentication system inside your backend that stores no user data on external managed services.
4
Declare the deployment constraint in your prompt
Myndlab will adjust its generated Docker Compose and deployment configuration to target a single-server or on-premise setup instead of defaulting to Vercel or Railway.
text
Stack: Next.js frontend, Go Fiber backend,
self-hosted PostgreSQL (UAE data residency required).

Auth: JWT with refresh tokens in httpOnly cookies.
No Supabase. No third-party auth services.
Deploy target: Docker Compose on a single Ubuntu 24.04 VPS.

All data must remain within UAE infrastructure.
ℹ
Note.Myndlab does not provide legal compliance advice. If your application must meet specific regulatory requirements (DIFC Data Protection Law, Saudi PDPL, or others), consult a qualified legal advisor. The configuration above is a technical starting point, not a compliance certification.