Surajit Pal

01Problem

02Constraints

• Tenant identity must come from the server, never from a client-supplied field.
• Paid state follows the billing provider. The UI is not a source of truth.
• Platform operators and tenant users share an API surface with different guards, not two backends.

03Responsibilities

• Built an end-to-end multi-tenant SaaS platform: a tenant workspace, a separate platform operator console, and a modular backend API.
• Tenant identity is taken from the signed session, not from the client. Org data is scoped in the data layer; only the operator console may cross tenants.
• Authentication covers email verification, access and refresh tokens with rotation, logout, and multi-factor sign-in with TOTP enrolment and backup codes.
• Stripe is the source of truth for paid state: plan catalogue, checkout, customer portal, cancellation, refunds, and signed webhooks — the UI is not trusted for payment status.
• In-app notifications and transactional email follow domain events. Plan-gated tenant chat is entitlement-checked on the server.

Resume wording. Engineering detail behind these is pending verification.

04Architecture

• One NestJS API, MongoDB persistence, a tenant React app, and a separate operator console.
• Org-scoped queries carry a tenant key from the authenticated session. Cross-tenant reads exist only on operator routes.
• Access and refresh tokens, with rotation and logout. Multi-factor enrolment is optional on the account.
• Stripe checkout, customer portal, and signed webhooks update subscription state. In-app notifications and mail follow domain events in-process — no message broker in this deployment.
• Tenant chat is gated by plan entitlements checked on the server.

05Technical decisions

• Shared database with a tenant key, rather than a database per organisation, so operator oversight stays one query path.
• Webhooks, not the checkout return URL, decide whether a subscription is active.
• Domain events stay in-process so notifications and mail do not require a queue for the current scale.

06Implementation

• Public registration creates a tenant and its first user. Operators are not created through that path.
• The API is documented publicly. Live tenant and operator apps are linked from the project record.

07Difficult problems

08Trade-offs

• In-process events keep operations simple and avoid a broker. They will not survive multiple API instances without a later move to a queue.
• Workspace and file modules exist as structure only; they are not claimed as a shipped task or storage product.

01Problem

02Constraints

• Third-party public review platforms cannot receive a server-side post from this tool.
• Guest traffic must not share the owner API. A scan is not a login.
• A submit must persist before any redirect or outbound delivery.

03Responsibilities

• Built a QR-driven review assistant: a guest scans, rates, and receives an AI-drafted review they can edit before submit.
• Guest routes are public and separate from the owner dashboard. Owners authenticate to manage businesses, QR codes, sessions, and analytics.
• Submit always persists on the platform first. High ratings can offer a public-review path the customer completes themselves; lower ratings stay private with the owner.
• Owners can connect their own website or app for server-side delivery. Connections can be tested, and failed deliveries retried. Third-party review sites are not posted to from the server.

Resume wording. Engineering detail behind these is pending verification.

04Architecture

• NestJS API, PostgreSQL, a React guest flow and owner dashboard. QR codes encode the guest landing, not an API URL.
• Public routes cover business lookup, session, draft, and submit. Owner routes sit behind authentication: businesses, QR, sessions, analytics, and outbound connections.
• Drafting calls a hosted language-model API behind an internal provider interface. Which vendor answers is a runtime concern, not a public contract.
• Owners may connect their own website or app. The platform can push a submitted review there. Public review sites, if offered, are a customer-completed redirect after save.

05Technical decisions

• Always save on this platform first. Delivery and any public-review prompt happen after that write.
• Lower ratings stay with the owner. They are not sent down a public-review path.
• Guest and owner surfaces are separate route trees so a leaked guest URL cannot reach owner settings or outbound connections.

06Implementation

• The customer edits the draft before submit. The product does not publish unedited model output as a finished review.
• Outbound connections can be tested from the dashboard, and a failed delivery can be retried. Secrets for those connections are not logged.

07Difficult problems

08Trade-offs

• No completion signal comes back from a public review site after redirect. The dashboard can see that a redirect was offered, not that a post landed.
• A hosted model API is used instead of a self-hosted model, so draft quality depends on an upstream that this product does not operate.

01Problem

02Constraints

• ONDC protocol compliance sets the outer boundary: the protocol dictates the contracts and the role semantics.
• Services, schema, and infrastructure predate the work and are extended where they stand rather than replaced.

03Responsibilities

• Developing backend services for a microservices-based ONDC-style platform supporting multiple user roles.
• Designed and implemented workflows supporting authentication, order lifecycle, driver operations, and admin systems.
• Owned backend services for order processing and multi-role authorization logic in a distributed environment.
• Improved API structure and middleware organization to enhance response handling and maintainability.

Resume wording. Engineering detail behind these is pending verification.

04Architecture

• The platform is a multi-role delivery system: customers, retailers, drivers, and admin share one product around catalogue, ordering, and fulfilment.
• Work sits in a set of backend services rather than a single application, covering order flow, driver operations, and admin alongside the public client.
• The client is a Next.js / React application. MongoDB is the primary datastore. Stripe covers payment and refund on the order path.

05Technical decisions

• Existing services were extended in place rather than replaced.
• MongoDB remains the primary datastore for platform data.

06Implementation

• A step in the order lifecycle that fails midway is retried. When retries are exhausted the order is cancelled, and cancellation triggers a refund of any captured payment.
• API and middleware layering was restructured into modular units, so cross-cutting concerns sit in one place and response handling stays consistent across the surface instead of being restated per route.

09OutcomeNot published

01Problem

02Constraints

• Employee and employer must not reach each other's flows.
• Onboarding is sequential: an employee cannot treat the profile as complete until job preference, education, employment history, and social links are done; an employer cannot reach the rest of the product until the company profile is saved.
• A CV upload has to leave the browser and land in durable storage without the API becoming a file proxy for every byte.

03Responsibilities

• Built a two-sided hiring product for catering and hospitality: employee and employer portals on one API, with routes gated by role.
• Implemented authentication covering registration, email OTP, password and OTP login, Google sign-in, refresh tokens, and password reset.
• Designed employee onboarding as sequenced steps — job preference, education, employment history, social links, and CV upload — with completion flags enforced on the server and in the client router.
• Built employer company-profile onboarding. Job posting, candidate search, and subscription checkout exist as client screens; those workflows are not implemented in the API.

Resume wording. Engineering detail behind these is pending verification.

04Architecture

• One Express API over MySQL, and a Next.js client with separate employee and employer route trees.
• A user is one of superadmin, employee, or employer. Employers further distinguish company and individual; employees distinguish instant and permanent work.
• Access is a JWT session. Next.js middleware and the API both read role and onboarding-completion flags, so skipping a step in the browser is not enough to enter a gated route.
• Employee records cover job preference, education, employment history, social links, and a CV. Employer records cover company and hiring profile.
• Uploads go to object storage through a provider chosen in configuration. The API issues the upload grant and later moves a temporary object into its lasting location.

05Technical decisions

• Completion is stored on the user record rather than inferred from related rows at request time, so both the API and the client router can gate on the same flags.
• The employee profile is created on the first onboarding call, and that call requires an employment type, which is why job preference is the first step.
• Object storage is selected in configuration rather than hardcoded, so the client and API share one upload contract across providers.

06Implementation

• Registration issues access and refresh tokens, stores a one-time code, and emails it. The same OTP path also supports passwordless login. Google sign-in verifies an ID token on the server.
• Education and employment history can be replaced in bulk or edited one row at a time. Each mutation recalculates the matching completion flag.
• Failed password attempts lock the account for a period. Refresh tokens are persisted on the user and rotated on refresh.

08Trade-offs

• Employer plan and job-credit fields sit on the profile, and the client already has screens for posting, search, and checkout. Those screens have no API behind them, so a paid hire path cannot complete from this implementation.

09OutcomeNot published

01Problem

02Constraints

• Each module has to work per tenant, with per-tenant configuration and per-tenant subscription entitlements.

03Responsibilities

• Built multi-tenant SaaS platform with email parsing, AI chatbot integration, IVR workflows, subscription management, and ticketing modules.
• Designed backend modules supporting tenant isolation and configurable subscription plans.

Resume wording. Engineering detail behind these is pending verification.

04Architecture

• Tenants share one database. Isolation is a tenant key on operational records, not a database per tenant.
• The authenticated user is loaded from a signed token; the tenant is derived from that user, never from a client-supplied header. Queries and role checks then scope work to that tenant.
• Roles are platform operator, tenant supervisor, agent, and customer.
• Inbound mail is handled by a separate background service. A tenant configures either IMAP or OAuth, and the tenant is resolved from the support address the mail was delivered to.
• Each tenant's assistant answers from that tenant's knowledge base, retrieved at query time. There is no per-tenant model training, and a query cannot ask for another tenant's documents.
• Call-handling scripts and the tickets they produce are persisted in the platform; telephony is delegated to the dialler. An IVR interaction opens a ticket in the same pipeline as email and chat.

05Technical decisions

• Assistant isolation is the knowledge base loaded for that tenant at chat time, not a separate model host per tenant.
• A tenant picks one inbound-mail method — IMAP or OAuth — rather than running both.
• Plans combine feature access with usage limits on agent seats and ticket volume, checked against the tenant rather than only at billing time.

06Implementation

• Parsed inbound mail opens tickets automatically, with the ticket built from the content of the message.
• Tickets can originate from email, chatbot, IVR, or manual entry, and keep assignment history and conversation history.
• The subscription lifecycle covers trials, upgrades, downgrades with proration, and cancellation.

07Difficult problems

09OutcomeNot published

01Problem

02Constraints

• Encryption of patient data in transit and at rest.
• Audit logging of access to patient records.
• Retention rules are enforced in scheduled jobs.
• Minimum-necessary access: a clinician's patient list is scoped by ownership on the server.
• Business associate agreements with processors that handle protected health information.
• A constrained hosting region.

03Responsibilities

• Developed HIPAA-compliant therapy platform with secure patient file management and AI-assisted reporting.
• Implemented secure access control and protected file handling mechanisms.

Resume wording. Engineering detail behind these is pending verification.

04Architecture

• Login roles are admin and doctor. A patient is a record owned by a clinician; patients and relatives reach specific flows through scoped tokens, not the same role enum.
• A clinician may only read a patient record they own. Collateral files are reachable only where the relationship and the consent on the record allow it.
• Consent is persisted and checked in server guards, not only in the UI.
• Patient files live in object storage. Upload and deletion are authorised in the API against the owning clinician.
• Transcription uses a hosted speech-to-text API. Report drafting is delegated to a separate inference service. The clinician reviews each generated section.

05Technical decisions

• Consent is part of the authorization decision rather than a display rule, so a patient withholding access is a fact the server enforces, not something the interface hides.
• Ownership is enforced on the server, so a clinician never receives another clinician's records to filter in the client.
• Reporting requires an active paid subscription. Plan quota for how many reports a clinician may produce is enforced on the request, not only at checkout.

06Implementation

• AI-assisted reporting consumes clinician-supplied session material and prompt templates, and returns a section the clinician reviews. Templates default by practice framework and can be customised per clinician.
• The API authorises who may attach or delete a file; it does not stream object bytes and does not issue short-lived signed URLs.

09OutcomeNot published

01Problem

02Constraints

• Seven distinct roles share one system, and only the platform's own roles may reach the admin console.
• A provider must be able to hand work to their staff without those staff gaining provider-level rights, and the split differs from one provider to the next.
• Job state changes originate in the field, on phones, and have to reach the provider without a refresh.

03Responsibilities

• Developed multi-role admin panels with CMS and automated workflow for providers, agents, and customers.

Resume wording. Engineering detail behind these is pending verification.

04Architecture

• One TypeScript Express service over MongoDB, with routes under a single version prefix and one response envelope across the surface.
• Every persona is a row in one user collection discriminated by a user type: platform super admin, admin, finance, service provider, team lead, field agent, and customer.
• Authorization is three layers. A token guard establishes the user, a role guard declares which user types a route accepts, and a per-user permission record carries the rights a provider has delegated to their own staff.
• A team record links a provider to its field agents, so delegated rights are scoped to that provider's own people rather than to the role in general.
• Provider matching is a geospatial query against an indexed location on the user record: the nearest provider within a fixed radius, resolved in the database rather than by filtering distances in application code.
• Socket.IO carries request acceptance, field location updates, job list refreshes, and chat.
• The admin console is a React application with Redux Toolkit and sagas per domain, over server-side paginated tables.

05Technical decisions

• Delegated authority is a separate permission record rather than more roles. A team lead is one role whose capabilities vary per user, so a provider granting one of them the right to accept work does not add a role to the system.
• Each route declares the user types it accepts at the route definition, so a route's audience is readable without opening the handler.
• The service catalogue is configuration rather than code: a category carries its own intake questions, so a new service type is set up by an administrator instead of shipped in a release.

06Implementation

• A service request moves from not started, to pending once a provider accepts, to started, to completed. Withdrawal is not a single state: cancellation records whether the provider or the assigned field agent pulled out, because the two need different follow-ups.
• A field agent can only move a request they are the assigned agent on. That check is against the request, not against the role.
• What the console content-manages is the operational catalogue — service categories, the intake questions beneath them, and the shift windows work can be booked into — rather than marketing pages.
• Alongside the catalogue, the console covers provider verification, request browsing with server-side pagination and CSV export, and an access log for administrator sessions.

07Difficult problems

08Trade-offs

• One collection for every persona keeps identity, contact, device, and location in a single place, which is what makes the geospatial match a single query. The cost is a schema where a large share of the fields are meaningful for only some user types.
• Work advances on the request that causes it: a state change, a match, or an assignment happens inline and is pushed to listeners. Nothing runs on a schedule, so nothing expires, escalates, or retries on its own.

09OutcomeNot published

01Problem

02Constraints

• Card entry is deliberately out of scope for the application, which puts the payment step on the provider's own page and outside this client's control.
• The plan catalogue and the entitlements attached to it are served by the API. The client renders what it is given rather than keeping its own copy.
• Subscription state gates what a customer can reach, so it cannot be a client-side flag.

03Responsibilities

• Implemented Stripe-based recurring payment architecture and subscription lifecycle workflows.
• Managed recurring billing logic and payment validation mechanisms.

Resume wording. Engineering detail behind these is pending verification.

04Architecture

• A React and TypeScript client with Redux Toolkit slices for authentication and subscription, and MUI for the interface.
• Subscribing posts the chosen plan to the API, which creates a Stripe checkout session. The client receives a session id and redirects; card entry happens on Stripe's hosted page.
• The return from checkout carries that session id back. The client posts it to the API, which answers with a refreshed user record and a newly issued token, so paid state arrives from the server rather than being inferred from having landed on a success URL.
• A customer who already subscribes changes plan through a subscription-update call rather than a second checkout: the existing billing relationship is modified in place.
• Cancellation, refund requests, and current subscription detail are API calls. Self-service billing management is a redirect to the Stripe customer portal, with the portal URL minted server-side.
• A plan record carries the provider's price id together with its trial configuration and its entitlement quotas, so the catalogue and the entitlement matrix are one object.

05Technical decisions

• Hosted checkout rather than an in-app card form: the application never sees a card number, and the provider's page carries that burden.
• Paid state is re-read from the API after checkout and delivered in a re-issued token, so reaching the success URL by any other route grants nothing.
• Both the successful and the cancelled return post the session id back, so the client reconciles its view of the subscription even when the customer walks away from payment.
• An upgrade modifies the subscription instead of creating another one, so a customer changing plan does not end up with two billing relationships to reconcile.

06Implementation

• Plan cards render the server's entitlement figures directly and mark the customer's current plan. The action on a card reads subscribe or update depending on subscription state, so one component serves both first purchase and plan change.
• Cancellation and refund are confirmation-gated, and the store re-reads subscription detail after a cancellation rather than assuming what the change did.
• The subscription detail a customer sees — amount, period start, current period end — is the provider's own subscription object relayed by the API, so the client is not maintaining a second interpretation of the billing period.

08Trade-offs

• Handing the payment step to a hosted page removes card handling and gives up control of the one moment that matters most. Reconciling on return covers the customer who comes back; anything the provider decides later — a renewal, a failed charge, a dispute — has to reach the platform through the server, not through this client.
• Entitlements are described on the plan the client renders, but enforcing those quotas is the API's job. The client shows what a plan promises, not what stops a customer exceeding it.

09OutcomeNot published

01Problem

02Constraints

• Programme requirements defined by the government set the rules the workflow had to satisfy.
• A print run is a physical artefact. Once codes are on packs nothing about them can be changed, so eligibility, payout amount, and the address a code resolves to all have to be settled before the sheets go to press.
• The consumer is anonymous, on a phone, in a shop. A claim cannot depend on registration, an app install, or a stored payment instrument.

03Responsibilities

• Built QR generation and cashback admin dashboard with secure transaction workflows.
• Integrated Razorpay payment systems and handled payment processing flows.
• Implemented geospatial tracking features within the admin system.

Resume wording. Engineering detail behind these is pending verification.

04Architecture

• A batch is the unit of issuance. It fixes how many codes are in the run, how many of them are cashback-eligible, and the amount a winning code pays.
• Each code is its own record holding an opaque identifier. The printed QR encodes a URL ending in that identifier and nothing more, so the pack itself carries neither eligibility nor amount.
• Eligibility is drawn at generation: a shuffled subset of the batch is flagged as winning before a single code is printed.
• A scan resolves the identifier server-side and opens a claim form. Submitting it marks the code used; a code already marked is sent to an expired page instead.
• Cashback is disbursed through Razorpay Payouts as a UPI transfer, with the code identifier travelling as the payout reference and the provider's response stored back on the code record.
• An Express and MongoDB service behind a React admin console and the public claim page.

05Technical decisions

• The code carries an opaque identifier rather than encoded data, so eligibility and value are decided by the server and cannot be read off the pack, forged, or inferred from a neighbouring code.
• Winners are drawn when the batch is generated rather than at scan time, which fixes the payout liability of a print run before it goes to press.
• The payout is requested as soon as a winner supplies a UPI address, with the provider asked to queue the transfer if the disbursing balance is short — rather than the platform collecting claims into a batch of its own.
• The code identifier is sent as the payout reference, so a transfer can be traced back to the pack that produced it.

06Implementation

• Batch generation runs off the request path: creating a batch returns immediately and the codes are written behind it, with print-sheet generation tracked as its own job status.
• Print sheets are produced server-side as multi-page PDFs laying out a run's codes for the press.
• Scan location is taken from the browser's geolocation at claim time and stored with the submission. The admin console plots those points on a map.
• Disbursed cashback exports to a spreadsheet for reconciliation, alongside a report of the submissions themselves.

08Trade-offs

• Drawing winners at generation makes the cost of a print run knowable in advance, and it also means eligibility cannot respond to anything learned after the packs ship.
• Paying to a UPI address typed in at claim time keeps the claim to one step with no onboarding, and makes that typed address the only thing standing between a valid scan and the money reaching the right person.
• Scan coordinates are captured and plotted, but stored as plain coordinates rather than an indexed geospatial type — so the dashboard shows where scanning happened rather than answering regional questions of the data.

09OutcomeNot published

01Problem

03Responsibilities

• Developed cloud-based system for device management and energy monitoring.
• Built scalable backend APIs to process and manage device-generated data.

Resume wording. Engineering detail behind these is pending verification.

04Architecture

• Devices publish telemetry over MQTT to a broker, which the backend consumes.
• A device is identified and provisioned by a unique device identifier.
• Readings are persisted on arrival, and reporting aggregates them by region and device type.

07Difficult problems

09OutcomeNot published