Three group companies want a shared backbone with isolated data. The architecture choices that separate a workable multi-tenant ERP from a permanent reconciliation problem.
By Mohammad Jamnagarwala · Simply Five Studio
Three brothers in Mumbai run three cutting-tool manufacturing companies. The brands are independent in the market and joint in the back office. Material is sourced together. The sales team covers customers across all three lines. The factory floor shares capacity. The owners look at group performance every morning and at each brand's performance throughout the day. They had been running this on Zoho One, with custom modules layered on top, and the system had stopped fitting somewhere around the second year of the arrangement.
The brief that landed at Simply Five Studio was not "build us an ERP". It was "we need one system that respects three brands, isolates customer data correctly, but gives us the rollup". That sentence is the most common shape of mid-market group-company software requirements in India, and the architectural answers are not obvious.
The term gets used loosely. In SaaS architecture, multi-tenant means many unrelated customers sharing one application instance with row-level data isolation. In the context of a founder-led Indian group running multiple companies under common ownership, multi-tenant means something narrower. One application, one database, one codebase, with brand identity, customer data, and transactional data segmented at the row level. The tenants are not unrelated firms. They are the same firm operating under different brands.
This distinction matters because it shapes the architecture. A pure SaaS multi-tenant system needs hard isolation, separate billing, separate auth domains, and protection against tenant-A operators seeing tenant-B data. A group-company multi-tenant system needs soft isolation where the operators can be authorised across brands, the inventory ledger spans brands, and the reporting layer rolls up to a holding view that only the group founders see.
Three architectural shapes are available. Separate database instances per brand. Single database with schema-per-tenant. Single database with row-level tenant tagging. The work for CFX, the three-brand cutting-tool platform on AWS, landed on the third shape, with the isolation enforced at the application and query layer. The choice is deliberate. Separate databases sound safer but turn cross-brand reporting into an ETL problem. Schema-per-tenant produces operational maintenance cost on every migration. Row-level tagging, when the application layer is disciplined about it, keeps reporting fast, keeps migrations simple, and makes the isolation guarantees auditable in code that any engineer can read.
A common mistake in group-company ERP design is over-isolating. The owners ask for separation. The engineers separate everything. The result is three parallel systems with a shared login, which is no better than three independent ERPs.
The right move is to identify what genuinely differs by brand and isolate exactly those layers. Brand identity in quote templates, email headers, invoice formats, and customer-facing PDFs. Pricing structures, which in cutting tools can mean tier discounts that differ by brand even for the same SKU. Sales pipeline stages, because each brand's go-to-market is slightly different. Role-based dashboards, so a Carbiforce sales engineer sees Carbiforce opportunities by default. Customer master records, which is the data the owners care most about isolating because customer relationships are brand-specific.
What stays shared is the product master (where SKUs overlap), the inventory ledger (because the factory is shared), the vendor master, the user identity layer, and the audit log. The pattern is: isolate the customer-facing surface and the commercial agreements, share the operational backbone.
The reporting that justifies the multi-tenant approach lives in the consolidation layer. The owners need to know, at any time, which brand contributed what to the month's revenue, which brand has the strongest pipeline, where the customer overlap is, and which products are being cross-sold across brands.
This is not a dashboard exercise. It is a data model exercise. The consolidation reports work because the underlying schema treats the tenant ID as a first-class column on every transactional table, and because the reporting role is the only role authorised to see across tenant boundaries. A sales engineer cannot run the consolidation report. A brand head sees their brand. The owners see the rollup. Each view runs on the same data with different filters.
The work that produces this discipline is not glamorous. It is naming conventions, query patterns, and a permission model that the engineering team applies consistently for the life of the platform. The reward is that the owners can answer questions about the group in five minutes that previously required three separate Zoho exports and a Sunday afternoon in Excel.
The failure mode of multi-tenant group-company ERP is what we have started calling "soft pollution". Customer records from one brand show up in another brand's view because somewhere in the application a query was written without the tenant filter. A salesperson for brand A sees a brand B customer's order history. The owners discover the leak six months later when a customer asks why their data was visible to a brand they had not purchased from.
The leak is almost always a single missing line in a query. The prevention is structural. Every database query carries the tenant context. The ORM enforces it. Code review checks for it. The test suite has tenant-isolation tests. The audit log records every cross-tenant access. The discipline is not heroic. It is procedural, and it has to be in place from the first migration onward, because retrofitting tenant isolation into an existing schema is materially harder than building it in.
The same principles apply at the surface layer. Login flows, deep links, file uploads, exported PDFs, and email templates all need the tenant context to flow through. The discipline that produces a clean multi-tenant system is the same discipline that produces a clean operational system in general, which is part of why the architecture itself is not the differentiator. The execution is.
Group companies do not stay static. A fourth brand may be acquired. A brand may be sold off. Two brands may be merged. The multi-tenant architecture has to anticipate this. Adding a brand is a configuration exercise, not a build exercise. Removing one is an archive operation, not a database surgery. Merging two requires a one-time data migration that the schema supports.
This is the practical reason a fitted multi-tenant ERP outperforms a SaaS stack at this scale. The work to absorb a structural change is bounded. The cost does not scale with the number of years the system has been running. The system continues to fit the firm as the firm changes shape.
Decision infrastructure for a group-company manufacturer is not three ERPs with a dashboard glued on top. It is one operational substrate that respects the brand identity at the customer-facing layer and produces the consolidation truth at the owner layer. The architectural discipline that delivers both is what separates a working group platform from a permanent reconciliation problem. The pattern is replicable. The execution is where the work lives, as explored in the deeper essay on outgrowing Tally and the comparison between accounting software and ERP.
If your group is running three brands on stitched SaaS and the reconciliation work is starting to eat the weekend, the conversation begins with a diagnostic of where the divergence actually lives. Start a Conversation. The first phase is mapping what stays shared and what stays separate, before any code is written. The output is an architecture that fits how the group actually runs, scoped through the enterprise engagement model.
Generic school management software does not understand voluntary contributions, WhatsApp as the parent channel, or the relationship between a tahfeez and its community. A fitted system does.
A premium ceramic and sanitaryware showroom does not sell the way retail sells. The software that runs the floor has to follow walk-ins, designers, and vendor POs as one continuous journey, or it stays in the way.
Indian print-on-demand is artwork-heavy. The operational backbone for a 20 to 100 order-per-day shop covers capture, approval, production scheduling, and dispatch.
The contact form takes about two minutes. The reply comes from the founder within two working days.
