PROJECT PROFILE — State Tourism eServices Portal

1. Snapshot

The department of tourism of a northern Indian state licensed every category of tourism operator — homestays, hotels/resorts, travel agents, guides, photographers, and water-sports & adventure operators — through manual, counter-and-paper processes, each governed by distinct statutory rules. Agentryx designed, built and deployed a single configuration-driven e-services portal that runs the entire registration lifecycle online: a service-specific application, a multi-officer approval pipeline (Dealing Assistant → District Tourism Officer → inspection), payment through the State treasury's eChallan payment gateway, and an auto-issued, publicly verifiable digital certificate — across 8 service verticals and all 12 districts of the State. The Homestay service has run on production for 3+ months with ~979 registrations processed end to end; seven further services are in district UAT on a hardened four-environment release pipeline.

2. The Challenge

Each service is governed by its own legislation (e.g. the State's tourism trade rules, the State's water-sports and adventure-activity rules, the State aero-sports rules) — with its own form fields, fee schedule, validity term, document set and officer chain — yet all had to present as one coherent portal to citizens and to district officers. Four hard constraints shaped every design choice: (a) integration with the State treasury's eChallan payment gateway, an encrypted, exact-contract payment gateway that fails opaquely on the smallest deviation; (b) an air-gapped production data centre with no inbound access from the development network — every release is hand-carried and there is no roll-forward safety net; (c) a live public service (Homestay) that must never break while seven more services were built around it; and (d) policy values — fees, seasonal windows, validity periods, required documents, even which services are visible — that change by government order and therefore cannot be hard-coded.

3. What We Built

A multi-service platform on a shared spine with deliberate per-service isolation. Four "generic" services (restaurant, travel agent, guide, photographer) and the multi-stage Tourism Unit run on a single configuration-driven engine — forms, fees, validity and documents are data, not code. Two heavily-regulated verticals (Water Sports, Adventure Tourism) run as bespoke modules with their own compound-validity licensing. Tourism Unit implements a rule-driven certificate progression — Essentiality → Provisional → Final — that resolves the correct stage from the applicant's land status, Section-118 clearance and Fire/Pollution NOCs. Around these sit the shared capabilities: a role-, service- and district-aware officer pipeline with dedicated review queues; treasury-gateway payment with server-side reconciliation and supplementary-payment auto-heal; atomic, collision-free application and certificate numbering; a database-resident policy store; digital PDF certificates with frozen officer signatures and a public verification portal; a configurable seasonal-blackout engine; an officer signature-scheduling system; and a guided correction flow. Citizens and each officer role get a purpose-built cockpit; the interface is themed, accessible and dark-mode-ready.

4. Architecture & How It Works

The system is layered: a React / Vite single-page app (citizen and officer cockpits); a Node / Express API bundled to a single ESM artifact with esbuild and run under PM2; PostgreSQL via Drizzle ORM for typed data access and migrations; a runtime policy store (system_settings) the application reads on every flow; and the treasury-gateway payment integration. The lifecycle flows as: a Zod-validated, service-specific form → an atomic application number minted by a Postgres INSERT … ON CONFLICT counter (per-service, per-year, district-tagged) → routed by role + service + district to the correct Dealing Assistant queue → District Tourism Officer review → an inspection / security-deposit / indemnity gate → treasury-gateway payment (an encrypted encdata + exact merchant_code POST) → server-side reconciliation → an atomic certificate number and a PDF certificate carrying the officer's frozen signature → public verification. The design decisions are explicit and justified: configuration-driven (policy in the database, not code) because statutory values change by order; service-group isolation so changing or adding one vertical cannot break a live one; atomic database counters rather than application-level random/MAX numbering, because a government register must be gap-free and collision-free; and an air-gapped, four-environment pipeline (DEV → STG → UAT → PROD) with a mandatory staging dry-run, because production is unreachable and an outage is a public-service outage.

5. Technology Stack

• Frontend: React 18, Vite 5, TypeScript, wouter (routing), TanStack React Query 5, shadcn/ui + Radix UI, TailwindCSS 3 (+ tailwindcss-animate), Zod validation.
• Backend: Node.js, Express 4, TypeScript, Drizzle ORM 0.39, esbuild (single ESM bundle), PM2, Passport (authentication + RBAC).
• Data: PostgreSQL, Drizzle migrations, a runtime policy store (system_settings), atomic (code, year) counter tables for statutory numbering.
• Integrations: the State treasury's eChallan payment gateway (AES-encrypted challan, exact field contract, server-side reconciliation); server-side PDF certificate generation.
• Infra & deployment: on-prem, air-gapped government data centre; four-environment release pipeline (DEV / STG / UAT / PROD); PM2 process management; tarball-based hand-carried releases; a PreToolUse safety guardrail that parses an environment manifest and blocks dangerous production commands.
• QA & testing: Vitest (~1,400 automated tests) across a three-layer strategy — logic matrix, live backend smoke, and browser E2E (Playwright) — under a two-gate "not done until both pass" completion rule.

6. Capabilities & Expertise Demonstrated

• Government payment-gateway integration → a live treasury eChallan integration (encrypted encdata + the exact merchant_code contract) with server-side reconciliation and supplementary-payment auto-heal.
• Multi-service platform architecture → one portal, eight verticals: a single config-driven engine for the generic services plus isolated bespoke modules for the regulated adventure / water-sports licensing, so a live service is never at risk.
• Workflow / BPM engineering → a configurable multi-role approval pipeline (applicant → DA → DTDO → inspection → certificate) with role/service/district-aware routing and guided correction loops.
• Stateful domain modelling → a compound-validity state machine for Adventure Tourism (an outer Form-VI plus inner activity licences, grace periods and partial expiry) and the Tourism Unit's EC → PC → RC rule-driven certificate progression.
• Configuration over code → fees, seasons, validity, document lists and service visibility all read from a DB policy store and change without a deployment.
• Data-integrity engineering → atomic, collision-free statutory register numbers for both applications and certificates via Postgres ON CONFLICT counters with per-year reset, proven under concurrency.
• Production release discipline → a four-environment, air-gapped pipeline with mandatory staging dry-run, incident-driven safety guardrails and a zero-downtime requirement on a live public service.
• Test automation at scale → ~1,400 automated tests across a three-layer strategy with a two-gate completion mandate.
• e-Governance product & UX → citizen and officer cockpits, an accessible design-system UI (dark-mode), digital certificates and a public verification portal.

7. Hard Problems Solved / Innovations

• The treasury gateway's "exact-contract" payment crash. Adventure-tourism payments crashed the State treasury server with an opaque .NET ArgumentOutOfRangeException. A multi-day root-cause hunt — comparing the actual outgoing POST of the working services against the failing one — found the gateway demanded the form field merchant_code (snake_case); the client was posting merchantCode, so the treasury gateway received no merchant code and crashed on decode. The insight that broke it: diff the real wire request including the client form, not just the server payload.
• Gap-free statutory numbering. A government register cannot have duplicate or missing numbers. Application-level random / MAX numbering is collision-prone under concurrency, so it was replaced with atomic Postgres ON CONFLICT counters keyed per (service, year) — collision-free and gap-free by construction, validated with hundreds of concurrent mints.
• Growing a live service safely. Seven verticals were added around a service already serving the public. The answer was a service-group isolation discipline plus a build-enforced "production-live impact" rule: every change — even cosmetic — is audited against "does this touch the live Homestay flow?" before it ships.
• Air-gapped release safety. With no inbound access to production and two prior near-miss incidents, an automated PreToolUse guardrail was built that parses an environment manifest and hard-blocks dangerous production commands (wrong database, wrong process, data-loss migrations) before they can run.

8. Outcomes & Impact

Measured. The Homestay service has been live on production for 3+ months with ~979 registrations taken end to end (application → State payment → digital certificate). Eight service verticals have been built; ~1,400 automated tests pass across the suite; the full licensing lifecycle — previously manual and counter-based — is digitised for all 12 districts of the State, on a hardened four-environment release pipeline.

Qualitative / in rollout (not yet metricised). The platform replaces in-person counter visits and physical file movement for tourism licensing statewide, gives the Department a single operational dashboard, and issues verifiable digital certificates in place of paper. Seven services are in district UAT ahead of production rollout.

9. Roadmap & Evolution

Homestay (live on production) → the generic G2 services + Tourism Unit + Water Sports + Adventure Tourism (district UAT, sign-off in progress) → a notification module, a dedicated support console, and a careful Homestay certificate-number migration → staged production rollout of the v1.7 line. The model is land-and-expand: each service vertical is a standalone, separately-deployable scope riding a shared platform, so the Department can grow coverage one signed increment at a time.