The patient portal: production-ready in four weeks

What was built

A production-ready patient portal in four weeks. Patients get direct portal access: appointments, messages, documents, video consultation, and self-service for their own master data. The portal does not stand on its own. It plugs into the practice’s existing Practice Management System (PMS) and works with the data that is already there.

57 features in four weeks. More than 320 development hours, verified from time tracking, not estimated. Around 858 automated tests. 12 releases. A running test environment. Not a prototype, but a production-ready system with a test suite, CI/CD, and an architecture that holds.

For comparison: classic development without AI would typically need 12 to 16 weeks with a team of 3 to 4 for the same scope. Here it was one person, AI-assisted, in four weeks. The work volume of nearly two developers over a quarter, compressed into a single month, with no compromise on tests, architecture, or documentation.

The constraint

A patient portal is not a standalone product. Its value only emerges in the integration: into the practice calendar, into the master data, into the workflows that already run inside the PMS. That is exactly where most projects fail. Not at the frontend, but at the integration into a system that is already in operation.

The goal was therefore not to show a fast shell, but to build a portal that works against the real PMS and not against a mock. What gets built in four weeks has to hold up against the real PMS, not on a slide.

What the portal does

Its own online appointment booking. Patients book for themselves, connected to the practice calendar over the PMS interface. Configurable opening hours, and the practice team can book directly in the calendar on a patient’s behalf. Its own booking instead of an external service.

Video consultation on its own infrastructure. No external video SaaS. The consultation runs on the practice’s own infrastructure, and patient data stays in its own hands.

Two-way integration with the PMS. A patient requests a change to their master data, the practice approves it, and the change is written back into the PMS. A real roundtrip, not an island portal that only displays data.

Onboarding via invite link. The PMS hands over the patient data, the portal captures it automatically and pre-fills the master data, and the invitation arrives as a link. No double entry, no cumbersome sign-up.

Real-time messages between practice and patient. Live, and deliberately filterable and switchable, so a channel never turns into a flood of messages.

How it is built and operated

White-labeling without a code deploy. Logo, colors, and copy are configurable per location. One codebase, many practices, without a fork.

Modular by design. Not single features, but entire functional blocks (appointment booking, video, messaging, documents) can be switched on and off per location. The product is tailored per customer, not copied.

Fully automated setup of runtime and CI/CD. The complete environment (test and production) and the delivery pipeline stand up automatically: a push deploys the test environment, a tag deploys production, with format, typecheck, and test gates, automatic database migrations, and health checks. No manual deployment, production-ready from day one.

Plus the table stakes, built cleanly: 2FA, internal task routing, and a practice document library.

The architecture

Core-first, Ports & Adapters. The PMS sits behind a clean adapter. The domain logic lives in its own package, framework-agnostic and testable. The PMS is connected, not cast in concrete. The adapter can be swapped without touching the core logic.

A monorepo with shared types: when a contract between the portal and the interface changes, the build breaks immediately, not in production. A hierarchical config model in three tiers (vendor, location, user) carries the white-labeling and the module switches, without a code deploy.

And then the combination where most systems break: multi-tenant and multi-role at the same time. Many locations on one codebase, cleanly separated, and one person who holds several roles at once (patient, practice staff, physician, admin). Carried by a unified identity with typed profiles: permissions are evaluated from context (who, which practice, which resource) via ABAC, not from a static role. Multi-tenant and multi-role together are the pinnacle of access architecture. With classic RBAC the model breaks. ABAC carries it.

And quality is built in, not claimed: around 858 tests across unit, integration, and end-to-end level, as a gate before every push. The proof is not a claim, but a running test suite.

What remains

A portal that runs against a real PMS and is production-ready in four weeks is neither an accident nor a shortcut. It is the result of discipline: a clean boundary between core logic and integration, tests as a gate rather than an afterthought, operations as automation rather than manual work.

Its own infrastructure for video, the swappable PMS integration, the switchable modules: that is sovereignty by design instead of a vendor lock-in that gets expensive later. And the speed came not despite the discipline, but because of it.