Case Studies

What we built
and what changed

Six projects, described the way we would describe them to you on a call — the problem, what we did, and what was different afterwards.

A note on names

Sectors, not logos

Most of this is internal software, and the businesses would rather not publish how their operations run. Sector, scale and outcome are real; the names are withheld. We are happy to arrange a reference call.

RetailNashik, 6 outlets

Six outlets, one stock figure everybody trusts

The problem

Stock lived in three places — a POS at each branch, a central Excel file, and whatever the branch manager remembered. Transfers between outlets were recorded on WhatsApp. Month-end reconciliation took four days and never fully balanced.

What we did

We audited the physical flow first, then built inventory and sales modules that read directly from each POS and write back to Tally. Branch transfers became a two-tap action with an audit trail. Rolled out one outlet at a time over five weeks.

What changed

Stock is now accurate to the previous night across all six outlets. Month-end closes in half a day. The owner sees live sales per branch on a phone dashboard instead of waiting for a Monday summary.

4 days → 4 hrsMonth-end close
6Outlets on one system
~92%Stock accuracy, from 60s
Next.jsNode.jsPostgreSQLTally ODBCAWS

ERP Systems

E-commerceMaharashtra

From WhatsApp orders to a store that runs itself

The problem

Orders arrived as WhatsApp messages and were copied into a spreadsheet by hand. Two people spent most of their day on data entry, and roughly one order in twenty was lost or duplicated.

What we did

A storefront with proper inventory, variants and coupons, plus an admin panel built around how their team already worked. Razorpay for payments, Shiprocket for dispatch, and automatic WhatsApp status updates so customers stopped calling to ask.

What changed

Live in three weeks. Order entry is gone as a job. The two staff moved to customer service and packing, and "where is my order" calls dropped sharply because the update now arrives before the customer thinks to ask.

3 weeksConcept to live
0Manual order entry
~70%Fewer status calls
Next.jsPostgreSQLRazorpayShiprocketVercel

Web Development

ConstructionNashik & Pune

Site progress the director can see without a phone call

The problem

Progress on eleven active sites was reported by phone every evening. Material consumption was reconciled monthly, by which point overspend was already sunk. Nobody could compare sites on the same basis.

What we did

A field app site engineers use on their phones — works offline, syncs when signal returns — feeding a consolidated dashboard. We spent the first week agreeing what "percent complete" actually means, which turned out to be the hard part.

What changed

Progress and material consumption update daily instead of monthly. Overspend surfaces while it can still be acted on. Site comparison is now like-for-like because everyone measures the same way.

11Sites live
Monthly → dailyMaterial visibility
OfflineWorks without signal
ReactPWANode.jsPostgreSQLPower BI

Data Analytics & BI

ManufacturingNashik MIDC

Visual quality checks that do not depend on who is on shift

The problem

Surface defects were caught by eye at the end of the line. Detection varied by operator and by hour of the shift, and rejects were often found only after packing, when rework cost the most.

What we did

We ran a two-week feasibility on their existing photographs before proposing anything. Once the data supported it, a vision model was trained on labelled samples and deployed on a small edge device beside the line, flagging suspect pieces for a human to confirm.

What changed

Detection is consistent across shifts and defects are caught before packing rather than after. The model assists the operator rather than replacing them — every flag is still confirmed by a person.

Pre-packDefects now caught
ConsistentAcross all shifts
2 weeksFeasibility before build
PythonPyTorchOpenCVEdge deviceFastAPI

Machine Learning

HospitalityNashik

One booking view across properties and channels

The problem

Bookings arrived from three OTAs, a phone line and walk-ins. Each channel had its own screen. Double-bookings happened often enough to be budgeted for, and rate changes had to be made five times.

What we did

A single reservation view that pulls from every channel, with rate and availability pushed back out. Housekeeping and maintenance were added as a second phase once the booking side had proved itself.

What changed

Availability is consistent across channels, so double-bookings stopped being a routine cost. Rates change once and propagate everywhere.

5 → 1Screens to check
SingleRate update point
2 phasesBooking, then ops
Next.jsNode.jsMySQLChannel APIsAWS

Enterprise Apps

HealthcareMaharashtra

Patient records that load before the consultation starts

The problem

Records were split between paper files and an ageing desktop application that only ran on one machine. Retrieving a returning patient’s history took long enough that consultations regularly started without it.

What we did

A web-based records system with role-based access and a full audit trail, plus a structured digitisation of the back catalogue. Access control was designed with the practice before anything was built, given the sensitivity.

What changed

History is on screen before the patient sits down. Access is logged per user. Backups are automated and have been restored under supervision, so the practice knows they work.

InstantHistory retrieval
Per-userAccess audit trail
TestedBackup restores
ReactNode.jsPostgreSQLEncrypted storageAzure

Enterprise Apps

Want to talk to one of them?

We can usually arrange a reference call with a client in your sector. Ask when you get in touch.

Start a project +91 91453 10264