
Results Case study · Custom ERP · Shipbuilding · Kerala, India
Viraat Marine Shipyard builds and repairs vessels in Kerala. In forty-five days of summer 2026 we built them an ERP that runs the yard from the first enquiry to vessel delivery — live today at erp.viraatmarine.com, on desks in the office and on phones at the slipway.
Viraat Marine ERP is a custom enterprise system TechAuditPros built for Viraat Marine Shipyard Pvt Ltd between 20 July and 2 September 2026. It replaces separate tools and paper with one browser-based system of 19 role desks — director, design, naval architecture, production, purchase, accounts, marketing, members and attendance — on 38 database tables, with a live activity stream, realtime updates on every open screen, a sign-in gate on every desk and a phone layout for the yard. It is live at erp.viraatmarine.com and is being prepared to run on the shipyard’s own office computer with no internet connection.
A vessel is a long project made of short ones. Drawings go out for review and come back with comments. Steel, paint and electrodes are requested from the slipway and approved by people who are not standing on it. Crews are counted every morning, paid every month. Invoices follow milestones. Somewhere a director needs to see all of it on one screen without phoning six people.
The brief we were given was short. One system for design, production, purchase, finance and people. Usable on a phone at the yard, not just at a desk. Nothing ever deleted, everything traceable to who did it and when. Live data only — no demo numbers, no green tick before the database says so. And, at the end, a system the yard owns outright and can run on its own machine.
We went to work on 20 July 2026. The first desk was deployed the same day.




Every desk is an isolated island with its own screens and its own modules, sharing one locked database connection. The hull below fills in the way the yard did: plate by plate, over six weeks.
Real screens from the live system, captured on 6 September 2026. Names, counterparties and amounts are redacted; the layout, the numbers of drawings and the approval queues are as they were.
47 drawings under revision control on the day of capture. Six of the 19 desks shown; the sign-in page is public, the desks are not.
The purchase chain is the pattern the whole ERP is built on: a request moves through numbered steps, each step confirmed by the database before the next person sees it.
A supervisor raises a material request from the yard desk — on a phone, standing next to the job.
The purchase manager sees it in the queue, checks stock and vendors, approves or flags it. Step three of five.
Finance clearance: budget line, invoice terms. Step four. Nothing moves without a returned database row.
Final capital-expenditure clearance on the executive desk. Step five. The whole chain is visible from here.
The requester is notified, the stock registry updates, and the event lands in the live activity stream.
Drawings follow the same shape: a draftsman submits, the design head reviews and comments, a revision is recorded, an approved drawing can be shared with the client through the portal. Leave requests, invoice requests and enquiries each have their own chain. None of them can skip a step.




Below 768 pixels every desk becomes an app: a bottom bar with the four things that role does most, tables that turn into stacked cards, a chat button that stays under the thumb. A supervisor logs the crew, photographs the day’s welding and raises a material request without leaving the yard. Photos are compressed on the phone before upload so a bad signal at the water’s edge still gets the evidence through.
The same principle runs the other way. Nothing on any screen, desk or phone, is shown as done until the database has said so. That is what makes it safe to work from the slipway.
An ERP is only useful if the people using it believe it. These six rules are enforced in code and at the database, not in a policy document.

Every insert and update is chained to a read-back. A save only shows as saved when the database returns the row. An empty response is treated as a failure, not a success.
A failing query raises a red banner with a copyable report of exactly what was attempted. Nothing fails quietly; the owner can paste the report to us and the fix is one message away.
Records are archived, never destroyed. Deletion is blocked at the database itself by a trigger, so no screen, script or mistake can remove history.
Every desk writes to the same activity stream. At the time of writing it holds 3,500+ events, re-audited on a thirty-second cycle so a missed write is caught, not lost.
Realtime channels push changes to every open tab — one channel per tab, fanned out internally, so the director and the slipway see the same row at the same second.
A sign-in gate in front of every desk, role rules per desk, sessions that expire after 24 hours of inactivity, and credentials issued personally by the director from the members desk.
424 commits between 20 July and 2 September 2026, read from the repository. The yard used each desk as it went live; there was no single launch day to be afraid of.
Portal, director desk and the first operations views, deployed the same day.
Roles and desks, the live event log with its 48-hour history and 30-second re-audit, the 40-member roster, the Kerala marine calendar.
A shared core library, then the isolated desks: four naval architects with drawing vaults, purchase inventory and material requests, production planning.
Every mock and bypass removed; the accounts, purchase and design desks redesigned to one visual system.
Finance module, portfolio and construction engine, drawing revision control, the admin console, confirmable writes on every table, realtime everywhere.
Sign-in and session lock on all 19 desks, notification indicators, archive controls, the phone app shell.
Self-hosting scaffold: the full database stack in Docker on one office PC, 38 tables and 21 files migrated, working with no internet.
The repository, the database and the hosting accounts belong to Viraat Marine. The next step, already scaffolded and rehearsed on the owner’s machine, moves the whole system onto one office PC at the yard: the full database stack in Docker, every desk served over the office network, working with no internet at all, and a nightly backup as the safety net. In the rehearsal, 38 tables and 21 stored files came across intact.
That is the difference between a subscription and a system. If we disappeared tomorrow, the yard would still open the ERP on Monday morning.


Kerala builds ships. Now one of its yards runs on a system built twenty kilometres from the slipway.
Questions about this case study
The sign-in page is public at erp.viraatmarine.com; the desks behind it are the yard’s live data, so they are not. Book a call and we will walk you through the real system on a screen share, with the client’s permission, and show you the parts that match your own business.
Forty-five days from first commit to handover round — 20 July to 2 September 2026, 424 commits — with the yard using desks as they went live rather than waiting for a single launch day. The self-hosting work that followed took one further day.
It is scoped on a call, because the honest number depends on how many desks, how many approval chains and how much data already exists. What we can promise in advance is a written plan for the first ninety days, a staging URL you can open every week, and one agreed monthly fee rather than a rate card with surprises.
No. It is hand-built for one shipyard: 19 desks written for the people who sit at them, 38 database tables shaped around vessels, drawings, purchase chains and site logs, and 80 isolated modules. Nothing was licensed from an ERP vendor and there is no per-user fee.
Plain HTML, CSS and JavaScript on the front end — no framework, each desk an isolated island — and a managed PostgreSQL database with realtime channels and file storage behind it, hosted on a global edge network. That choice is why it runs on a phone on the slipway and why the yard can self-host it later on a single office PC.
The client does. The repository, the database and the hosting accounts are theirs, and the handover package includes a self-hosting installer and runbook so the system can run on their own machine with no dependency on us or on any cloud subscription.
Yes. Below 768 pixels every desk switches to an app shell: a bottom bar with the four destinations that desk uses most, tables that become stacked cards, and a chat button that stays reachable with a thumb. Supervisors log the day and upload photo evidence from the yard.
Nothing on a screen is shown as saved until the database has returned the saved row; failures raise a red banner instead of a silent nothing; records are archived rather than deleted; and every desk writes to one live event log that is re-audited every thirty seconds.
Yes, and the pattern travels well beyond shipbuilding: any business with drawings or specifications, a purchase approval chain, work on a floor and accounts at the end has the same shape. We start by looking at one real workflow with you, free, and writing down what one system would replace.
The same team that built it keeps improving it on one agreed monthly fee: new desks, changed approval chains, reports, and the self-hosting migration when the client is ready. Every change ships to a staging copy first and is written up in a monthly report.