The visible feature was only the surface
Institutions often manage operational requests across chat, spreadsheets, fixed forms, and verbal follow-up, separating submitted information from ownership, current status, and accountability.
The system also had to respect concrete constraints. English and Bengali must be complete interfaces, with locale-aware content and Bengali or Latin numeral handling where appropriate. Google identity, platform authority, and institution membership are separate security boundaries, so every protected read and mutation must be authorized on the server. Historical submissions must remain interpretable after an institution edits a form or workflow, requiring immutable published versions and explicit state transitions. Google OAuth, Neon, Resend, and Netlify depend on environment-specific configuration without moving credentials into source control.
My role covered product design and full-stack engineering, with responsibility for multi-tenant authorization, configurable workflows, and bilingual service delivery.
I turned the constraints into boundaries
TanStack Start routes and server functions deliver role-aware React workspaces; framework-independent domain modules own forms, workflows, status transitions, and authorization; Drizzle repositories scope Neon PostgreSQL records by institution and actor; Better Auth, Google OAuth, Resend, Netlify Functions, and GitHub Actions form the identity, communication, deployment, and quality boundaries.
Google sign-in establishes identity, while platform authority and institution membership independently determine what a person can see and do.
Each submission retains the immutable Form Version and Workflow Version it entered, so later edits cannot rewrite the meaning or required process of historical work.
Role-aware navigation improves usability, but server functions and institution-scoped queries remain the security controls for every protected read and mutation.
Employees and managers can preserve operational detail without publishing every internal note to the person who submitted the request.
The key decision: Separate identity from institution access.
The implementation had to prove the model
I delivered the work across the full path: Designed role-specific journeys for Super Admins, Admins, Managers, Requesters, and Employees across English and Bengali interfaces. Built dynamic form creation, immutable publishing, configurable workflows, submission tracking, assignment, work updates, notifications, invitations, profiles, and audit views. Modeled tenant boundaries, delegated Manager capabilities, versioned records, and role-specific data access across domain modules, repositories, and database migrations. Established automated domain, application, authorization, route, and presentation checks with GitHub Actions and a Netlify SSR deployment.
The result is concrete: Institutions can define bilingual forms and operational workflows without changing application source code. Requesters can submit a published form, receive a tracking number, and follow requester-visible progress from one record. Admins and delegated Managers can review queues, assign Employees, manage people, and inspect accountable history within their institution. Employees can accept assigned work, record progress and evidence, and complete or return the assignment through explicit workflow states. Published versions, work logs, notifications, decisions, and audit events preserve a traceable history as the process evolves.
The senior engineering lesson was that solving the visible workflow is only half the job. The architecture must also make constraints, failure modes, evidence, and ownership explicit enough for the next change to remain safe.