Our default full-stack setup is Next.js with TypeScript for the website and app, PostgreSQL for data, and a separate Python service built with FastAPI for anything that involves AI or voice. It is tested with Playwright and Vitest and deployed on managed hosting. Each choice is boring on purpose: well documented, widely used and easy for a client's future team to pick up.
Here is why each part is there.
Why Next.js and TypeScript for the front end?
Next.js renders pages on the server, so visitors and search engines get real HTML straight away instead of waiting for JavaScript. That matters for speed scores, for SEO and for AI answer engines that read the page text. The same framework handles the marketing site, the logged-in app and small API routes, which keeps a project in one codebase.
TypeScript catches a large class of mistakes before the code runs. On a small team, that is the difference between finding a bug on your laptop and finding it in production.
Why a separate Python service for AI?
Most AI tooling, from model SDKs to voice frameworks such as LiveKit Agents, is strongest in Python. FastAPI gives us a fast, typed API with automatic documentation, so the website and the AI service agree on exactly what each request looks like. Keeping AI work in its own service also means it can scale, restart or be replaced without touching the website.
Why PostgreSQL?
Postgres is a reliable, open-source database that handles almost every need a business app has: accounts, bookings, leads, audit logs and, with an extension, the vector search used in AI search over documents. One well-run database is easier to back up, secure and reason about than several specialised ones.
How do you keep data separate between customers?
Many of our builds serve more than one business from one system. Every table that holds customer data carries a tenant ID, every query filters by it, and the API checks the signed-in user's tenant on every request. Secrets such as telephony credentials are encrypted at rest. These rules live in shared code, not in each screen, so they cannot be forgotten.
How is it tested?
- Vitest for unit tests on the logic that matters: pricing, permissions, slot holds.
- Playwright for end-to-end tests that click through the real site in a browser, including mobile sizes and dark mode.
- Automated accessibility checks with axe on key pages.
- Type checks and linting on every change, before anything is merged.
How is it hosted?
The Next.js site runs on a managed platform with a global CDN, so pages are served close to the visitor. Python services run in containers with health checks, so a stuck process is restarted automatically. Environment variables hold every secret, and nothing sensitive is committed to the code.
Will another team be able to take it over?
That is the test we design for. The code belongs to the client, the stack is mainstream, and each project ships with a README that explains how to run, test and deploy it. If the client later hires their own developers, they should recognise every tool on day one.
Design and web