A major Indian automotive company replaced a foreign SAAS ERP — whose database was encrypted and inaccessible — with a fully custom ERP for their scrap operations. Pure Billion Technologies delivered a working system in 3 months. Partner adoption recovered, AI integration became possible, and the client now owns their data and processes.
The client
A major Indian automotive manufacturer with a dedicated scrap operation across multiple sites. Scrap is not a side activity for them — it is a regulated, partner-driven, document- heavy process with thousands of transactions a month. (Client name redacted at their request; details verifiable on request under NDA.)
The problem: a foreign SAAS ERP that became the bottleneck
The client had been running their scrap operations on a foreign SAAS ERP for several years. On paper it worked. In practice, every working day surfaced a structural problem:
- The database was encrypted by the vendor. The client could not see how their own data was stored. Every request — a custom report, a one-off export, a reconciliation — had to be raised as a ticket with the vendor, who then either delivered the data manually or wrote scripts at extra cost. In a fast-moving operation, this is unworkable.
- Workflows were not customizable in the way the client's operations actually ran. Process changes on the floor could not be reflected in the system without another vendor engagement.
- AI integration was blocked. Without database access, there was no path to plug forecasting, classification, or anomaly detection into operational data.
- Partners stopped using the system. Scrap operations depend on a network of recyclers, transporters, and yard partners. They found the SAAS interface complicated enough that they began routing transactions outside the system, eroding the data quality the ERP existed to maintain.
“When your partners stop using the ERP, the ERP has stopped being an ERP. It is a database that some of your operation reports into, and that is worse than no system at all.”
Why custom — and why not just “upgrade” or migrate to another SAAS
The client evaluated alternatives including SAP and other large enterprise ERPs. The same pattern emerged in every demo: feature catalogs that dwarfed the team's actual needs, multi-quarter implementation plans, and customization stories that ended in “configure-not-code” restrictions for the parts that mattered most.
| Dimension | Stay on existing SAAS | Move to SAP / large ERP | Custom ERP |
|---|---|---|---|
| Database access | Encrypted, vendor-gated | Vendor-managed | Full client ownership |
| Workflow fit | Limited | Force-fit to platform model | Designed around operations |
| AI integration path | Blocked | Vendor-dependent | Direct |
| Partner usability | Failing | Heavier interface, training cost | Designed for partner UX |
| Time to value | N/A — already failing | 6–18 months | 3 months for first phase |
| 5-yr TCO | Rising (data extraction fees) | Highest (licenses + consultants) | Lowest (one-time build + light ops) |
How we delivered in 3 months
Week 0–2: on-site discovery
We did not start in design tools or with a feature spec. We went on-site, shadowed the team across yard intake, weighing, classification, partner dispatch, billing, and reconciliation. The goal was not to redesign the operation — it was to faithfully model the operation the client had already optimized over years.
Week 2–6: first working slice
We shipped the most critical loop first — yard intake through partner dispatch — as a working module the floor team could use in parallel with the legacy SAAS. This validated the model with real transactions, not mockups.
Week 6–10: parallel operations
Remaining modules (procurement linkages, billing, partner portal, dashboards) shipped in sequence. Each module ran in parallel with the legacy system for at least one operational cycle before cutover.
Week 10–12: cutover and partner onboarding
Partners were brought onto the new partner-facing interface, which had been designed explicitly for non-technical users with intermittent connectivity. Adoption returned to where it had been before the SAAS interface drove partners away.
What changed for the client
- Data sovereignty restored. The client owns the database, the schema, and the code. Any report, any export, any analysis is now a query, not a vendor ticket.
- Process fits the operation, not the other way around. Workflow changes on the floor get reflected in the system in days, not quarters.
- AI integration unblocked. Classification and forecasting models plug directly into the operational data layer.
- Partner adoption recovered. The partner-facing interface was designed for their actual workflow, not adapted from a generic ERP module.
- Rapid site rollout in progress. The system is being extended to additional sites every few days, with adjacent operational areas following close behind.
Why this matters for your operation
If you recognize any of these signs — vendor-gated data, customization that feels like a hack, partners or staff routing around the ERP, blocked AI plans — the cost of staying is almost always higher than the cost of rebuilding. The question is not whether to move; it is what to build, in what order, on whose timeline.
Operating on an ERP you have outgrown?
Tell us where the friction is. We will give you an honest assessment in 30 minutes — including whether custom is the right answer for your operation.