Build the boring parts once
The eleven products are not eleven codebases. They sit on a shared substrate of modules that were written once and are reused wherever they fit.
Staff payroll is the clearest example. It was built for the Business Suite. When SchoolOS needed to pay teachers and non-teaching staff, it did not get a second payroll — it got the same one. A fix to statutory deductions lands in both products on the same day, because there is only one place to fix.
The same is true of documents and approvals, which serve the legal and CA practice tools; of tasks and deadlines, which both practice tools share; of inventory and accounting; and of the notification module that sends every SMS, email and WhatsApp message across the whole portfolio.
Built once · reused everywhere
Four decisions, each with a cost
Principles are only worth stating if they rule something out. These do.
- One substrate, even when a product would ship faster without it. Fitting a new product to the shared modules is slower at the start and much cheaper for the rest of its life. The cost is that the first release of anything takes longer than it would standalone.
- The system before the agent. We build the software a profession runs on first, then the agent that acts inside it. The cost is that our agents arrive later than competitors who wrap someone else's API — and reach further when they do.
- Move the date, not the scope. When a client's feedback changes what a release has to do, we change the date and say so publicly. The cost is visible slippage, like the Learning Platform below.
- Own the deployment. Every product runs on infrastructure we operate, in one region, with one set of operational habits. The cost is that we say no to work that would need a different stack.
How we work with clients
The Learning Platform was planned for launch on 17 August. Our client's feedback changed the scope of several features, and we chose to rework them rather than ship a release we would have had to apologise for. The launch moved, and the reworked platform has since launched.
We publish that because a vendor who hides a slipped date once will hide yours later. If we tell you a date, you will hear from us before it passes, not after.
What we actually run on
Technical buyers look for this and almost nobody publishes it.
| Layer | What we use | Where |
|---|---|---|
| Application runtime | Google Cloud Run | asia-south1 (Mumbai) |
| Primary database | Cloud SQL — PostgreSQL 15 | asia-south1 (Mumbai) |
| Object storage | Google Cloud Storage | asia-south1 (Mumbai) |
| Public web | Firebase Hosting, Google-managed TLS | Global CDN |
| Messaging | SMS, email and WhatsApp Business gateways | Per client configuration |
Customer data stays in India. Where a client needs a different arrangement, that is a conversation before the contract, not after.
Talk to us
If you want to interrogate any of this before trusting us with a system your organisation runs on, that is the right instinct. Ask.