I design systems, build them, and keep them running.

Catalogue

Thousands of pages, none maintained by hand

Every college is a database record and its slug is the route. A new record triggers a worker, and the worker calls a page builder that renders that college's page with its own data and components. Redis keeps the hot lists in memory, and a CDN sits in front.

Trade-off Generated pages mean cache invalidation has to be designed, not hoped for. Catalogue updates land weekly and the cache is rebuilt in batches.

Data

A catalogue that stays true

Scrapers and browser automation collect from college websites and brochures, and partner institutions send their own. Everything is verified before it goes live and refreshed every week. When a student spots something wrong, it comes back through support and gets fixed at the source.

Why Data collection here is an ongoing job, not a one-off import.

People

Software for the paperwork, people for the relationship

An enquiry becomes an application record, and a hybrid process assigns a relationship manager. The back office tracks applications, assignments and how accurate they were, plus operational logs, behind multilevel role-based access with super-admin controls.

Same model as the studio The platform does the repetitive work; people handle the parts that need judgement.

Money

Two ways to pay, one set of books

Students either pay the college directly or pay through SikshaHelpline. Every movement of money gets an invoice: one when a student pays us, another when a college pays us. Payments run through Razorpay and are reconciled, and refunds follow a formal request with the relationship manager involved.

Running it

Always a way back

Separate development, staging and production, with CI on GitHub, Sentry for errors, server images plus local backups, and media on S3. When the infrastructure went down, I rolled back to a known-good version and had the service restored within two hours of the servers being available. The platform's technology runs on under ₹20,000 a month.

Platform

A platform, not a chatbot

Each vertical sits on shared foundations for identity, retrieval and administration. SYNA DI is the first one. The next can launch without rebuilding any of that.

Retrieval

Answers grounded in what we actually know

A question goes through two kinds of retrieval: similarity search over embeddings, and a knowledge graph that knows how institutions, courses, eligibility and fees relate (Graph RAG). The model writes from what was retrieved, not from memory.

Handoff

AI passes the student to people

When a student is ready to act, SYNA DI passes them to SikshaHelpline's admissions pipeline, and a relationship manager takes it from there. The AI product and the human operation share one path, so nothing gets re-entered.

Validation

Proved on a small group before scaling

Alpha, then a closed beta with 100 students. Nine of them completed admission through the pipeline. That count excludes SikshaHelpline's own admissions, and the beta was free, so it isn't a paid conversion rate. The public release comes next.

Monorepo

One codebase, three apps

Web, admin and API share seven packages: UI, design tokens, auth, the API client, the database layer, and common and config code. A change to a token, a type or an auth rule lands everywhere at once and is type-checked everywhere at once.

API

An API shaped like the business

REST-first on NestJS and Fastify, documented with OpenAPI, and split into 24 domain modules: catalog, discovery, order, payment and delivery, through to retention, data export and account deletion. It runs on PostgreSQL with migrations and seeds. Redis and BullMQ workers handle anything that shouldn't block a request, and errors are monitored in every app.

Pipeline

Every change has to pass the same checks

CI runs linting, documentation checks, type checks, environment validation and unit tests. It then runs API integration tests against real PostgreSQL and Redis, plus an offline end-to-end delivery test. Each app gets a preview deployment. Production, staging and rollback workflows are written down before launch.

Decisions

Product decisions made before the code

• One ritual, one box, one order, so v1 has no cart.
• Discovery by occasion, ritual, festival or intent, without a chatbot front end.
• The phone number is the identity, with OTP sign-in.
• Three admin roles: super, operations and support.
• ECS Fargate rather than Kubernetes for launch.
• The user journey, database, admin, API and design-system architecture were all frozen before implementation began.

Model

Knowledge as a graph, not a pile of prompts

Each node has a type: principle, practice, pattern, threat, decision, tool, technology or architecture layer. Edges have types too: depends-on, implements, mitigates, gates, alternative-to, supersedes. Every node also says how binding it is (a rule, a recommendation or a principle) and how confident and useful it is.

Shown here Only the schema. The graph's contents stay private.

Retrieval

Only what the task needs

Retrieval scopes by the task, the project's stack and the graph's relationships, with per-project overrides and a version lock, so the agent gets a relevant slice instead of everything. That costs a little more context at the start and saves rounds of correction later.

Feedback

It learns from the work

Findings are captured in each project, reviewed, and promoted to the main graph when they generalise. Changes are additive: outdated nodes are deprecated or superseded rather than deleted, and the graph is validated after every change.

In use

It shaped a real build

On PujaBox, DevCodex set the security baseline and the engineering pipeline for a full e-commerce build. It also chose the error-monitoring and product-analytics setup.

The site

A chat that knows when to bring me in

The site is static at the edge, and edge functions sit on a small SQLite database. Bloopie answers from what's on the site, can open parts of the page, and saves requests. A second pass on every message records who the visitor is. Each conversation gets its own Telegram topic, so I can reply from my phone and the answer appears in their chat.

The pipeline

A media buyer's first week, in a few minutes

The pipeline reads every live video ad in a category. It groups the ads by the site they send people to, so creator pages roll up to the brand paying for them, scores each brand, and tears down its ads with the same questions every time. Then it writes three hooks for the gap it found and builds variants: three hooks on one body, one variable per test.

The back office

Scheduled jobs I don't have to babysit

Six scheduled workflows do the routine work. They sync prospects into the CRM sheet and export it back nightly, merge contacts, watch for replies, and pull site visitors in every ten minutes. Rows are marked synced only after the sheet write succeeds.

Guardrails

Rules the system can't break

• Outreach is written as drafts only. A person sends every email.
• Client data never goes to free AI tiers.
• The chat has rate limits, a daily model budget, a human check, and a fallback if a model is down.
• No raw IP addresses are stored.
• The site claims no result the studio hasn't produced.