← all projects
Healthcare SaaS

Medcord

Multi-tenant hospital management SaaS. Hospitals sign up, set up a workspace, and run patient management, EMR, labs, and asset tracking from one platform. Go + Gin backend, React 19 frontend on Feature-Sliced Design.

Medcord

Multi-tenant hospital platform unifying patient management, EMR, labs, and asset tracking. Go 1.25 + Gin backend with i18n and generics-based ServiceResult; React 19 + Vite frontend built in disciplined, spec-verified phases.

MongoDB
React
TypeScript
Vite

Problem Statement

Hospitals — especially smaller and mid-sized ones — run on a patchwork of disconnected tools and paper: patient records here, lab results there, asset/equipment tracking in a spreadsheet. Each hospital also needs its own isolated data and workspace. Building one platform that multiple hospitals can self-onboard onto (multi-tenant), covering patient management, EMR, labs, and assets, with the data isolation and reliability healthcare demands, is a large systems problem.

Proposed Solution

Medcord is a multi-tenant hospital management SaaS. A hospital signs up, provisions a workspace, and runs patient management, electronic medical records (EMR), lab workflows, and asset tracking from a single platform — backed by a Go API, a React 19 web app, and a dedicated marketing landing page.

Full Solution Details

  • Multi-tenant onboarding — hospitals self-register and get an isolated workspace.
  • Modules — patient management, EMR, labs, asset tracking (with QR/barcode scanning per the icon set).
  • Three surfaces — backend API, reviewer/clinical web app, and a landing page; an admin build plan exists alongside the main app.
  • i18n from day one — message keys with en/es/fr translations baked into the backend's shared constants.
  • Phased delivery — the frontend is built in numbered phases (4/5/6, 7–10) against a spec that is pre-verified against the actual backend source before any code is written.

Technical Documentation

BackendGo 1.25 + Gin, MongoDB via the official driver, structured logging with log/slog, rate limiting via ulule/limiter, security headers + CORS via gin-contrib, auth with golang-jwt/v5 + bcrypt, and request validation through go-playground/validator (Gin binding tags). Clean idiomatic layout: cmd/server (entry + graceful shutdown), internal/{app,configs,controllers,deps,middlewares,routes,shared,utils}, with deps/ wiring built once at startup and shared/types exposing generic ServiceResult[T] and Page[T]. It hard-fails on a missing JWT_SECRET (production safety, not a warning), and flips to Gin release mode + JSON logs when APP_ENV=production. Make targets cover run/dev (air live-reload)/build/test/lint/tidy.

Frontend — React 19 + Vite + TypeScript (strict) on Feature-Sliced Design, TanStack Query v5, React Router v6 (lazy), Tailwind, the author's own @medcord/ui, @medcord/api, @medcord/core packages, and meemaw utilities. The team enforces an unusually strict, spec-driven convention set (documented in phase specs): no .map()/&&/raw ternaries in JSX — instead meemaw's <Repeat>, <Show>, <Switch>/<Case>, and a <Loadable> wrapper around every data-fetching screen; readonly *Props interfaces co-located with components; named exports only; and EP/endpoint paths verified against the real backend routes before implementation.

Tech Stack

Go 1.25, Gin, MongoDB, slog, golang-jwt, bcrypt, go-playground/validator, ulule/limiter, gin-contrib/secure+cors (backend); React 19, TypeScript, Vite, TanStack Query v5, React Router v6, Tailwind, meemaw, internal @medcord/{ui,api,core} packages (frontend).

System Design

Hospital ──signup──► Workspace (tenant-isolated)
        │
   React 19 FE (FSD) ──@medcord/api (typed EP)──► Go/Gin API
   <Loadable> screens                              │ JWT (hard-fail if no secret)
   <Repeat>/<Show> (no raw JSX)                     │ slog · rate limit · CORS/secure
        │                                           ▼
        │                       internal/: controllers → (services/repos) → MongoDB
        │                       shared/types: ServiceResult[T], Page[T] (generics)
        ▼                       shared/constants: i18n message keys (en/es/fr)
   Modules: Patients · EMR · Labs · Assets (QR/barcode)

Smart Architectural Decisions

  • Fail fast on misconfiguration. Hard-failing on a missing JWT_SECRET (rather than warning) is a deliberate production-safety stance — the app refuses to boot insecurely.
  • Generics for a uniform result/paging contract. ServiceResult[T] and Page[T] give every endpoint a consistent, type-safe envelope and pagination shape across the Go codebase.
  • Spec-verified, phased frontend. Pre-verifying every API path, response-unwrap, and icon name against the actual backend before coding each phase eliminates the integration guesswork that usually causes FE/BE drift — a rigorous, almost contract-testing-like discipline.
  • JSX as declarative components, enforced. Banning .map()/&&/ternaries in favor of <Repeat>/<Show>/<Loadable> standardizes loading/empty/list rendering across a large app (and dogfoods meemaw).
  • i18n + multi-tenancy from the start — both are notoriously painful to retrofit; building them in early shows architectural foresight for a healthcare SaaS.

Impacts

A unified, multi-tenant platform that lets hospitals run patients, EMR, labs, and assets from one workspace — engineered with production-safety defaults, a type-safe Go core, internationalization, and a frontend built under strict, drift-proof conventions.

Demonstrated Skills

Go backend engineering (Gin, idiomatic internal/ layout, generics, slog, graceful shutdown, security middleware); multi-tenant SaaS + healthcare domain modeling (EMR/labs/assets); i18n; React 19 + Feature-Sliced Design + monorepo packages; contract-first FE/BE integration discipline; production-safety mindset (fail-fast config).

Notes

  • Polyglot depth: a real Go (1.25, Gin) backend alongside a React 19 frontend shows breadth beyond the JS/TS comfort zone — and it's idiomatic Go (internal/ layout, generics, slog, air).
  • Production-safety instincts: hard-failing on missing JWT_SECRET and env-gated release mode are the kind of details that separate "works on my machine" from "safe to deploy."
  • Anti-drift engineering: pre-verifying every API path/icon/response-shape against backend source before each frontend phase is a standout discipline — it's basically self-imposed contract testing and a great interview story.
  • Hard domains handled early: multi-tenancy + i18n + healthcare (EMR) are all things teams usually regret retrofitting.
  • Three coordinated repos (API, app, landing) show end-to-end product ownership.
Ask me anything