Case studies
Built, deployed, still running.
The internal systems staff open every working day, and the public sites in front of them. None of this was designed in a vacuum — every module started as a real requirement from a real client, and got hardened by daily use. Where a site is live, its case study links straight through to it. The one still being built is marked In build, so you can tell it from the work already running.
An advocate's site, with a knowledge centre that builds itself
Hitesh H. Virda is an advocate of the Gujarat High Court practising criminal law at Lawyer's Desk, Rajkot. The brief was a site that loads instantly, carries the same weight as the firm's own printed material, and can be kept current without a developer on call. Built, optimised, deployed and hosted end to end — design, code, SEO, server and search console, all in-house.
It is static HTML5, CSS3 and vanilla JavaScript — no framework, no runtime dependencies, and nothing that will need patching next year. Ten pages: the practice site, a Legal Insights listing and eight articles. Every piece of business information lives in a single data file: change a phone number there and every call link, every WhatsApp link and the structured data all update together.
The knowledge centre is not rendered in the browser. A Node generator reads one content file and writes real HTML — the listing, a page per article, and the sitemap — so every word is indexable and the whole section still works with JavaScript switched off. The build works out reading time from the actual word count, appends the legal disclaimer to every article, picks three related insights, builds the category chips from the categories in use, and lifts the header and footer out of the home page so the article pages can never drift out of step with the rest of the site. It refuses to build on a duplicate slug, a malformed date, a missing cover image or a disclaimer written in by hand.
The SEO was done here, not handed off: canonical URLs, Open Graph and Twitter cards, robots.txt, a sitemap the build regenerates with per-article lastmod dates, and JSON-LD throughout — ProfilePage and Person on the home page, Article and BreadcrumbList on every insight, CollectionPage and ItemList on the listing. The site was then verified in Google Search Console, the sitemap filed there, and indexing followed page by page rather than left to chance.
It is hosted on our own VPS too. The nginx vhost was written by hand to sit safely alongside the tenants already on the box — no default_server, every reload gated behind a config test, so a mistake fails closed and leaves the other sites untouched. HTTPS comes from Let's Encrypt with www redirecting to the apex, gzip is on, security headers are declared once at server level, and images and fonts cache for a year while HTML and CSS revalidate every time so an edit reaches visitors immediately. First install and later updates are two separate scripts, and the updater backs up the live site before it unpacks anything.
The firm's mark was taken from its own signboard artwork as true vector paths rather than redrawn, and one file renders it ink-on-paper in the header and paper-on-ink in the footer. Bar Council of India Rule 36 is covered twice — an acknowledgement gate on entry, remembered per visitor, and a standing notice in the footer. Verified from 320 to 1920 px: no horizontal scrolling, WCAG 2.1 AA contrast on every text style, all 50 internal links returning 200, and the whole site still usable with JavaScript disabled.
- Static HTML, CSS and vanilla JavaScript — no framework, no dependencies to patch
- Ten pages: the practice site plus a Legal Insights listing and eight articles
- A Node generator writes the insights section as real HTML — indexable, and working with JavaScript off
- Reading time, related articles, category chips, disclaimers and sitemap entries all produced by the build
- All business information in one file — one edit updates every call link, WhatsApp link and the structured data
- Consultation form validates in the browser, then hands a filled-in enquiry to WhatsApp; a real API can be switched on later without touching the form
- SEO end to end — canonical, Open Graph, Twitter cards, robots.txt, sitemap, and JSON-LD for ProfilePage, Article, BreadcrumbList and CollectionPage
- Verified in Google Search Console, sitemap submitted, indexing followed page by page
- Hosted on our own VPS — nginx vhost, Let's Encrypt HTTPS, www to apex, gzip, security headers, tuned caching
- Separate install and update scripts, with the live site backed up before every content update
- Bar Council of India Rule 36 covered by an entry acknowledgement and a standing footer notice
- Verified 320–1920 px — no horizontal scroll, WCAG 2.1 AA contrast, works with JavaScript disabled
A perfume shop that prices every cart on the server
A marketing and ordering site for the Highness perfume house in Gujarat — the storefront customers buy from, and the back office the shop runs the day out of.
The front end is React 19 on Vite with no UI framework; behind it sits a small Express API. Customers pay through Razorpay — UPI, card, net banking or wallet — or by cash on delivery, and either route creates a real order on the server.
The browser never sends prices. It says only which fragrance, size and quantity it wants, and the server recomputes every amount from the same catalogue the site renders — so a tampered cart cannot buy a ₹550 bottle for ₹1. Every payment is signature-verified server-side before an order is marked paid, and a webhook catches the orders whose customer closed the tab before coming back.
- Razorpay checkout — UPI, card, net banking, wallet — plus cash on delivery
- Server-side pricing: a tampered cart cannot change what it is charged
- HMAC-SHA256 signature verification on every payment, compared in constant time
- Webhook on payment capture, so a closed browser never becomes a lost order
- Confirmation email to the customer and an order alert to the shop
- Dashboard showing money received against money still to collect
- Orders searchable by name, phone, order id or PIN, and downloadable as CSV
- Stock taken off sale is enforced on the server, not just hidden in the page
- Rate limiting on order creation and on admin login
A storefront the studio runs itself
Muse Collective is a design studio in Rajkot. The site is the storefront for its pieces — collection grid, product pages, cart, wishlist and enquiry — built so the studio adds, prices and photographs its own work without coming back to me for every change. Built and hosted end to end, on our own server.
It is Next.js 15 with React 19 and TypeScript throughout, on the App Router, with no UI framework at all — the design system is plain CSS in two files. The shop pages prerender to static HTML, which is why the catalogue and every product page arrive as fast as a flat file while the cart, search, wishlist and drawers stay fully interactive.
Rather than renting a hosted CMS, the site carries its own password-gated admin panel: catalogue editor with photograph upload, hero banner, the studio story, the founder block, testimonials, currency rates and an enquiry inbox. The password is never stored in the browser — signing in leaves a signed httpOnly cookie whose signing key is the password itself, compared in constant time, so changing the password signs every browser out at once. nginx keeps the panel out of search results.
Every price is held in rupees and converted for display only, at rates the studio sets itself in the panel rather than pulled from a market feed — so nothing on the site can change price overnight because a currency moved, and a margin can be built into the rate. Anything malformed is dropped rather than shown as a broken price.
The contact form records every enquiry to disk before it tries to email the studio — a mail outage must never lose a message — and the response says which of the two happened. Whatever came in is read back in the panel.
It runs on our own Hostinger VPS under pm2 on Node 24, pinned to a separate Node build because the box's system Node is 18 and other apps on it depend on that. nginx terminates TLS and serves the uploaded photographs and the build output straight off disk rather than waking Node for each one. The deploy script deliberately never copies the catalogue or the uploads folder — those are edited on the server, and pushing them from a laptop would wipe real work.
- Next.js 15 App Router, React 19 and TypeScript across the whole codebase
- Shop pages prerendered to static HTML; cart, search, wishlist and drawers stay interactive
- No UI framework and no hosted CMS — the design system and the editor are both part of the site
- Password-gated admin: catalogue, photograph upload, hero banner, story, founder, testimonials, enquiries
- Signed httpOnly session cookie keyed on the password itself, compared in constant time
- Multi-currency display at rates the studio sets — prices stay in rupees, conversion is display only
- Slide-in cart with quantity control, kept in the browser between visits
- Wishlist, and a search overlay with live filtering across the collection
- Product gallery with hover image swap, lightbox and a specification accordion
- Enquiries written to disk before the email goes out, so a mail outage never loses one
- Sitemap, robots rules, a share card drawn at build time, and Store, Product and FAQPage structured data
- Shipping, delivery and returns policy pages
- Runs on our own VPS under pm2 and Node 24, behind nginx with Let's Encrypt HTTPS
A hospital website off end-of-life PHP
The public site for Aayush Group of Hospitals was running on an old PHP codebase that had stopped receiving security patches. That is a bad place for any site to sit, and a worse one for a hospital — it is the first thing a patient sees, and it carries enquiry forms.
Rather than patching around it, the front end was rebuilt in React and Next.js. The legacy PHP stack came out entirely, taking its unpatched dependencies with it. What replaced it renders fast, works properly on a phone, and is served over HTTPS from infrastructure the group controls.
- End-of-life PHP removed — no unpatched dependencies left behind
- Server-rendered pages, so departments and doctors stay searchable
- Responsive from desktop down to a small phone
- Existing content carried across, nothing lost in the move
- SSL, backups and hosting handed over documented
Applix — one login for eighteen internal systems
The staff portal a multi-unit hospital group opens every morning. Behind a single sign-in sit eighteen modules — daily schedule, OT planner, asset manager, HR recruitment, SCM item master, recognition and rewards, document folders — plus a link straight into the hospital information system. Each user only sees the modules their designation allows.
Building this is where the inventory, purchase, recruitment, asset and permission modules came from. It is also where most of the rest of this page starts.
- Quick-launch home with live and upcoming module status
- Designation-driven access, module by module, per user
- Internal news, announcements and staff celebrations built in
EaseBuddy HRMS — when a module became a product
The attendance and staff side of Applix was the piece every other business asked about. So it was rebuilt as a standalone multi-tenant HRMS: subdomain routing per company, biometric device import, selfie and GPS check-in from a Flutter app, eight leave types, gate passes, grace-period shift rules and an employee self-service portal.
- One deployment serving multiple companies
- Bulk import of employees and historical attendance
- Calendar attendance view for every employee
An importer that doesn't time out
The hospital's billing export is a 126 MB CSV with 132 columns and over one lakh rows. Most tools give up on it. This one loads it in a single pass using a COPY-based bulk loader driven by a generated column map, tracks every upload so a failure can be retried cleanly, and feeds the revenue dashboards and doctor incentive engine behind it.
- 1,17,000+ rows per file, loaded without timing out
- Incentive calculation as PostgreSQL stored procedures
- Materialised views so dashboards stay fast
Getting the data out when there is no export
The hospital's management platform held every bill and pharmacy line finance needed, and offered no usable way to get them out. No export API, no scheduled feed — someone signed in and clicked through a report by hand each time anyone wanted numbers.
The platform's own reporting API was reverse-engineered from its network traffic. Where its file-storage layer refused programmatic access, a headless browser was pointed at the same screens a person uses — it signs in, applies the filters and takes the genuine download. The rows land in PostgreSQL through an upsert that is safe to run again, hourly, with every run written to a log. Checked against the platform's own export, it matched on all 75 bills and every monetary column.
- Undocumented reporting API mapped from network traces
- Browser automation picks up where the API is blocked
- Idempotent hourly upsert, every run logged for audit
- 100% reconciliation against the platform's own export
- A schema-agnostic explorer alongside it — point it at any JSON endpoint and get a filterable, sortable table with Excel, CSV and PDF export, no field names hardcoded
The OT list, current wherever the team is standing
Operation theatre scheduling and ward handover for surgeons, nurses and OT staff, with a Flutter app so the list is never out of date on the floor. Role-based flows for doctor, nurse, OT staff and admin, procedure search with scrub-nurse assignment, and a push notification the moment anything on the schedule moves.
- Ward handover and discharge intimation workflow
- Push notifications on every schedule change
- Automated daily database backups
Procure-to-disposal, on its own domain
An asset and procurement system running at its own address for a hospital group: purchase requisition, quotation, purchase order, asset register and asset disposal, with user management and MIS reports behind it. The director dashboard opens on a unit-wise summary of every pending and completed request across seven units — Morbi, Oswal, Sava, Mehsana, Bhuj, Junagadh and Samarpan — plus total asset count and portfolio value.
- Full lifecycle: requisition → quotation → PO → register → disposal
- Every request tracked by number and status, unit by unit
- Live asset count and portfolio value on the director's home screen
Reorder levels that write the purchase order for you
The item master behind a hospital unit's stock: 974 items across eight categories, each with its own reorder level, order type and conversion rate. The screen flags the 929 items sitting below ROL, works out an order quantity for each, and generates the purchase order — one run came to 84,713 units and just over ₹18.5 lakh, calculated rather than typed.
- Bulk upload of item master, actual stock, PO quantity and rates
- Filters for below-ROL, refill, auto and order-required items
- Fifteen toggleable columns, PO history and Excel export
Whether the work actually got logged
A daily activity module inside the staff portal, so a manager can see at a glance who is logging their day and who is not. Each person gets submitted and missed counts, a success rate against a target, hours logged split between office and personal, and a month calendar where every day is marked. Activity breaks down by group, category, sub-category and location, over 7, 30 or 90 days.
- Per-day calendar view of submitted, missed and pending slots
- Success rate against a stated compliance goal
- All-users analytics view for managers, not just self-service
Also in production: an asset and purchase requisition system across seven units and head office, and a Docker Compose platform running several of these side by side with PostgreSQL, MongoDB, Redis and MinIO.
Something here look like your problem?
If your process resembles one of these, there is a good chance most of the work is already done.