Technical Architecture
A modern, well-layered two-service system
A .NET 10 minimal-API backend with Entity Framework Core and PostgreSQL, and a Next.js 16 App Router frontend that serves marketing, the customer portal and the admin console — with admin traffic proxied through a same-origin backend-for-frontend.
Stack
Technology at each layer
| Layer | Technology | Notes |
|---|---|---|
| Frontend | Next.js 16 (App Router), TypeScript, next-intl | SSR marketing, portal & admin from one app; five locales. |
| Backend | .NET 10 minimal API, C# | Domain → Infrastructure → Api layering; ~110 routes. |
| Data | PostgreSQL 18, EF Core | 31 tables, 36 migrations, advisory-locked on boot. |
| Documents | QuestPDF, OpenXml, headless LibreOffice | Invoice & contract PDF generation. |
| Storage | S3-compatible object storage | Templates, signed PDFs, invoices, imagery. |
| Runtime | Docker, container hosting + managed Postgres | Health-gated deploys, single small replica tuned for low RSS. |
System shape
How the pieces fit together
Browser
│
▼
┌─────────────────────────────────────────────┐
│ Next.js 16 frontend (marketing · portal · admin) │
│ · SSR marketing + SEO · magic-link portal │
│ · admin console (no chrome) │
│ · BFF: /api/admin/* attaches admin JWT server-side │
└───────────────┬─────────────────────────────┘
│ HTTPS (CORS-restricted)
▼
┌─────────────────────────────────────────────┐
│ .NET 10 minimal API │
│ Domain → Infrastructure → Api │
│ · endpoints · feature services · workers │
│ · auth · rate limiting · audit · output cache│
└───────┬───────────────────────┬───────────────┘
│ │
▼ ▼
PostgreSQL 18 External providers
(EF Core, 31 tbl) payments · e-sign · identity
email · storage · monitoring
Backend
- Three-project solution: Domain (POCO entities + enums), Infrastructure (EF Core, migrations, seed), Api (endpoints, workers, integrations).
- Minimal-API endpoints call EF directly; non-trivial logic lives in feature services.
- Health endpoints: liveness (
/health) and DB-checked readiness (/ready). - Migrations apply on boot under a Postgres advisory lock, so concurrent instances never race DDL.
- Workstation GC tuning keeps memory low on a small replica co-hosting LibreOffice.
Frontend
- Next.js 16 App Router with server rendering for SEO-critical marketing pages.
- One app, three audiences; admin renders without marketing chrome.
next-intldrives five locales; geo/locale detection at the edge.- Same-origin BFF attaches the admin bearer token server-side — it never reaches client JavaScript.
- Consent-gated analytics and token-redacting error monitoring.
Data & privacy
Schema built for the rental domain
The relational model spans catalogue, fleet units, bookings, rentals, contracts, invoices, payments, deposits, maintenance, support and settings — 31 tables under 36 versioned migrations.
GDPR-relevant, and documented as such. Customer personal data is denormalised onto booking and rental rows rather than a single customer table — so export and erasure sweep those rows. This is called out explicitly in the system audit. Raw customer data is never part of the acquisition package.
Security
Sensible defaults throughout
- Admin auth via short-lived signed JWT; server-side BFF keeps the token off the client.
- Customer portal secured by scoped magic-link tokens; portal pages are
noindex,no-referrer. - Personal codes stored HMAC-only — never in plain text.
- Strict rate limiting on sensitive endpoints; CORS restricted to known origins.
- Audit logging on sensitive operations; secret-redaction hooks in monitoring.
Portable by construction. The current production runs on the founder's personal cloud accounts, which are excluded from the sale. An acquirer takes the code, schema, design system and templates, stands up fresh hosting and provider accounts, provisions new secrets and re-points DNS. Nothing about the architecture ties it to a specific tenant.
Go deep with the engineering team
The acquisition pack includes the full audit, route inventory and data model. Book a technical demo for a code-level walkthrough.