Swasthya Sarathi
A healthcare-companion platform for Swasthya Sarathi
A website and mobile app development project for a multi-service healthcare companion — It helps peo...
Read itCustom ERP and operations systems
ERP systems built on a stock and money ledger that is only added to, never changed — multi-plant, multi-GSTIN, correct for GST, and matched to the physical count instead of arguing with it.
Last updated
Almost every ERP conversation we have starts in the same place: a Tally setup that only handles the books, four Google Sheets that hold the real day-to-day facts, and one person — usually in accounts — who is the only one who knows how the numbers connect. When that person takes leave, the month-end closes late.
An ERP is not accounting software. It is the one place that records what you have, what you owe, what you are owed, and where every order stands right now. Get it right and a plant manager in Bhiwadi and a finance controller in Gurugram see the same number at the same moment. Get it wrong and you have bought a very expensive data-entry job.
We build ERPs for manufacturers, distributors and multi-location retailers who have outgrown spreadsheets but do not fit a ready-made product — because their costing is job-based, or they run three GSTINs across two states, or they make goods to order and no template has a field for it. We will also tell you, honestly, when Odoo or Zoho would do the job for a fifth of the money.
These are the messages that reach our inbox. Not one of them is solved by another spreadsheet.
A quantity column that six processes overwrite, and a warehouse manager who "corrects" it by hand when it looks wrong. Nobody can find out why the number moved.
Purchase registers in one sheet, sales in another, Tally somewhere in the middle. Closing the books is a matching project, not a report you run.
They built the macros, they know which column is authoritative, and they have not taken a proper holiday since 2021. That is not a good system, it is one weak spot that can break everything.
A six-week-old challan gets edited to fix a typo and today's stock silently shifts by 40 units. No record of who changed it, no approval, no way to prove what the number was on the 31st.
The true material and labour cost of an order shows up weeks later, once someone adds it up by hand — long after you quoted the next one at the same price.
Three units, three GRN formats, two GSTINs and a stock transfer note that exists only in WhatsApp. Combined reports are guesswork put together once a quarter.
Here is the single design decision that separates an ERP you can trust from one you cannot: stock must be an append-only ledger, never a mutable quantity column.
The easy design is a products table with a qty integer that every process increments and decrements. It works for a month. Then two users receive the same GRN at the same time and one save silently overwrites the other. Then somebody edits a six-week-old delivery challan to fix a typo and today's stock quietly shifts by 40 units. Then a warehouse manager "corrects" the number by hand because it looked wrong, and now nobody can find out why. You end up with a figure nobody believes and a physical count every two weeks.
We save stock as movements that never change: every receipt, issue, transfer, adjustment and return is a row that is written once and never updated. Current stock is the sum of those rows. Nothing edits history — a mistake is fixed by a reversing entry, just like in a journal. That gives you three things you cannot buy back later: stock on any past date, a record that names the person and the time behind every unit, and a number that matches your physical count instead of arguing with it.
The same rule applies to money entries, batch and serial tracking, and costing. Add, never change. It is not exciting, but it is the whole game.
Typical change across manufacturing and distribution rollouts, measured two quarters after the cut-off date — not on the day it goes live, when everyone is still being polite.
Scope an ERPDown from nine to eleven days
System vs physical count, cycle-counted
Corrections are reversing entries, not overwrites
Duplicate keying across sheets and Tally
Switching everything on one day, on a system this central, is how ERPs make the news. We do it in small parts, each one in real use before the next begins.
We walk the plant and the warehouse. We watch a GRN actually get received, a challan actually get raised, a job card actually get filled. What people do and what the SOP says are different things, and the ERP has to serve the first one. We leave with a process map, a data plan and an honest list of the habits that will have to change.
Chart of accounts, item masters, HSN codes, tax classes, units of measure, warehouses, entities and GSTINs. Then the movement ledger itself. This is the plain two weeks that decide whether the system still works in year four, and we do not rush it to make a plan chart look better.
Each module goes into real use as soon as it is ready. Purchase orders, GRN with quality hold, stock movements and transfers, sales orders, delivery challans, GST-correct invoicing with IRN and e-way bill. Your buying team is using the purchase module while we are still building production.
Masters, opening balances and history are pulled from Tally and the spreadsheets, cleaned of duplicates, and loaded as opening ledger entries. Then both systems run side by side for a full cycle, matched every single day. Trust in the new number comes from watching it agree with the old one, not from being told to trust it.
A fixed date after which the old sheet is read-only, announced by someone senior enough that it sticks. Every process owner confirms that their module is live. We stay on the floor for the first week, because on day two somebody will want to go back and someone has to be there to say no and then help.
Bills of material, job cards, work-in-progress, actual job costing, quality checks, and the dashboards a controller really opens. Built on a ledger that is already trusted, which is the only reason these numbers mean anything.
Built on one ledger, one set of master data, one permission model. Not six products joined together with a nightly CSV.
Many warehouses, batch and serial tracking, bin locations, regular counting, and stock as at any past date. Corrections are reversing entries — history is never rewritten.
Indents, RFQs, purchase orders with approval limits, GRN with a quality hold, three-way matching against the invoice, and vendor ageing that finance can act on.
Quotations, sales orders, stock set aside from what is really available, delivery challans, e-invoice and e-way bill, receivables ageing and a credit limit that blocks the order instead of only warning.
Multi-level bills of material, work orders, WIP tracking, machine and labour records, scrap and rework. Actual cost per job, visible while the job is still open.
Permissions set by entity, plant and module. Money entries and rate changes go through an approval trail that names the person, the time and the value before and after.
Stock ageing, margin by SKU and by customer, plant-wise consumption, receivables and payables ageing. Combined across GSTINs, and you can open it down to each single movement.
| Tally + sheets | Zoho / Odoo | Custom ERP | |
|---|---|---|---|
| Real-time stock across plants | No | Yes | Yes |
| Append-only auditable ledger | No | Partial | Yes |
| Job-based or make-to-order costing | No | Painful | Native |
| Multi-entity, multi-GSTIN consolidation | Manual | Add-on | Native |
| Cost scales with headcount | No | Per user, forever | No |
| Time to first live module | No | 6–10 weeks | 10–14 weeks |
| Sensible when | Under ₹5 cr turnover | Conventional processes | Your process is the moat |
ERP rollouts do not usually fail for technical reasons. They fail because the store supervisor keeps a second notebook, the sales team keeps quoting from an old price list, and nobody senior ever said out loud that the spreadsheet is now dead.
So we plan the people half as carefully as the data design. We name an owner for each module — a real person, not a committee. We run the new system next to the old one for one full cycle, matching daily, so trust is earned and not ordered. We train on your data, not on demo data, because a warehouse team will not care about a made-up example. And we agree a cut-off date after which the old spreadsheet is read-only, and we keep to that date.
We have seen more ERPs die from a cut-off that nobody enforced than from any bug we have ever shipped.
No private runtime, no per-seat licence, no vendor who can hold your operations hostage at renewal.
Manufacturers and distributors running on a ledger they trust.
A fleet, ePOD and route-planning platform that works offline first, for drivers on roads with poor signal. The two ready...
A Shopify store for a Surat ethnic-wear label. It has 200+ SKUs of lehengas, sarees and suits, sorted by type, colour, f...
A Shopify storefront for a Surat watch and eyewear retailer — where shoppers can browse by gender, brand, style and comb...
Bring the Tally export, the four spreadsheets and the last physical count. We will show you exactly where the number goes wrong and what it takes to make it right.
Proof
Swasthya Sarathi
A website and mobile app development project for a multi-service healthcare companion — It helps peo...
Read itMV Tech Education
A website development project for a Bihar vocational institute. It is a course list and admissions s...
Read itPatna Taxi
A website development project for a Patna and Muzaffarpur cab operator. It is a fast taxi-booking si...
Read itLive web applications built on Laravel, Next.js and Postgres. They are typed, tested, easy...
ExploreFlutter, React Native and native apps that keep working offline, on old phones and on a me...
ExploreCommerce platforms where the checkout turns visits into sales and the back office numbers...
ExploreLet's talk erp development
A senior engineer reads every enquiry. You'll get a real answer — scope, risk and a number — within one business day.