AI Engineering
We build the systems that no vendor product fits, replace the ones your business has outgrown, and hand over everything needed to run them without us. If the honest answer is buy instead of build, we will say that first.
Custom software development is building a system that does not exist off the shelf — either because the process is the thing you compete on, or because no product handles the specific tangle of systems, rules and exceptions you actually run. ZenMagix is a custom software development company in Mumbai that builds line-of-business systems, modernises ageing ones, and turns down work where the right answer is to buy a product and configure it properly. We came out of blockchain infrastructure: wallets, exchanges, smart contracts. That work has an unusual property — it is adversarial by default, correctness is not negotiable, and a migration that loses a record is not a support ticket, it is a loss. Those habits carried over. We write systems that survive load, keep an audit trail, migrate data you can reconcile line by line, and come with the documentation and infrastructure code that lets your team, or the next vendor, take over cleanly. If you have been burned before, that last part is usually the one that matters.
Most companies asking for custom software should buy a product and configure it. Custom is justified when the process itself is a competitive advantage, or when no product can reach across the systems you need it to touch.
Run four questions before writing a brief. First: is this process how you win, or is it a commodity? Payroll, accounting, CRM, helpdesk and HRMS are commodities — a thousand companies solved them and you will lose money re-solving them. Your pricing engine, your dealer allocation logic, your claims triage, your production scheduling: those may be the business. Second: how many systems must it talk to? One or two, a product with an API will usually do. Five or more, each with its own idea of a customer ID, and integration becomes the actual project — that is custom territory.
Third: what do regulators or contracts force on you? Data residency, RBI or IRDAI reporting, audit trails with a retention period, segregation of duties. Products often bend for these, but if you are paying an SI to bend one this hard, you are already funding custom work without owning it. Fourth, and most useful: does the workflow already exist as a spreadsheet somebody maintains? If that spreadsheet works and only three people use it, do not build a platform. If it has thirty tabs, four owners and a monthly reconciliation ritual, it has outgrown itself and the system is worth building.
Full rewrites launched as a single cutover are how modernisation budgets die. We replace legacy systems piece by piece, run old and new in parallel, and prove the data matches before anything is switched off.
The typical Indian mid-size enterprise runs something built between 2009 and 2016 — a PHP or .NET monolith, a stored-procedure-heavy database, an original developer who left, and nobody willing to touch the billing module. The instinct is to rebuild it all and flip a switch on a long weekend. That fails because the old system encodes years of undocumented exceptions nobody can list, and you discover them in production, at scale, with no path back. We use a strangler-fig approach instead: put a routing layer in front, carve out one bounded capability at a time, and move traffic to the new implementation only after it has run in shadow mode against real requests with outputs compared automatically.
Data migration is treated as an engineering problem with a pass mark, not a scripted copy — row counts, checksums, referential integrity, financial totals reconciled to the paisa, and a dry run repeated until it is boring. Change data capture keeps both systems in step during the overlap so rollback stays possible for weeks, not hours. Cutover is a routing change you can reverse, not an event with a war room and a prayer.
Because we build systems you can take away from us. Every engagement ends with the repository, infrastructure as code, documentation and runbooks in your hands, and no proprietary framework in the middle.
The most common damage we are called in to repair is not bad code — it is a system only its builder can operate. No deployment documentation, infrastructure configured by hand in a console, credentials in one person's laptop, and a vendor-specific abstraction layer wrapped around everything so any replacement means starting over. That is not accidental; it is a retention strategy. We do the opposite deliberately: standard frameworks, boring architecture, Terraform for every environment, migrations in the repo, and a runbook covering deploys, rollbacks, backup restores and the three things most likely to page someone at 2am.
Our blockchain heritage shows up in the parts you cannot see from a demo — idempotent writes so a retried payment never books twice, immutable audit logs on anything financial or regulated, load-tested paths with real numbers rather than assurances, and adversarial review of anything a hostile user could reach. We also charge for handover time explicitly rather than treating knowledge transfer as an optional extra at the end of the budget. You should be able to fire us in month nine and lose a week, not a year.
AI belongs where input is unstructured and a human still confirms the output. It does not belong anywhere the answer must be exactly right, reproducible, or defensible to an auditor.
We build AI systems for a living and we still keep them out of most of a line-of-business application. Good fits: reading unstructured documents — invoices, POs, KYC packets, insurance claims — and proposing structured fields for a human to confirm; classifying and routing inbound email or tickets; search over internal documents that keyword search has never handled well; drafting text a person edits before it is sent. Bad fits, consistently: arithmetic and totals, which belong in code; eligibility, pricing and approval rules, which belong in a rules engine you can read and version; anything where the same input must produce the same output every time; and anything a regulator will ask you to explain.
A model that is right 94 percent of the time is excellent for triage and unacceptable for computing GST. The pattern that works in practice is narrow: model proposes, system validates against schema and business rules, human approves above a threshold, everything logged with the model version attached. If a vendor is putting an LLM in your approval path without a deterministic check behind it, ask what happens on the day it is confidently wrong.
What you get
A written review of the process, the systems involved and the products that already cover part of it, ending in a recommendation with costs on both sides. Sometimes the deliverable is a shortlist of vendors and a configuration plan.
Service boundaries, the data model with its constraints spelled out, integration contracts, auth and permission design, and the non-functional targets — throughput, latency, retention — written down before implementation starts.
Production software delivered as usable increments rather than one release at the end, with automated tests, database migrations in version control, and CI/CD pipelines your team can run themselves.
For modernisation work: the strangler-fig sequence, shadow-run comparison harness, data migration scripts with reconciliation reports, and a documented rollback procedure that has been rehearsed rather than assumed.
Repository, Terraform for every environment, architecture and API documentation, operational runbooks for deploy, rollback, restore and incident response, plus working sessions with your engineers until they can ship without us.
How we work
Two to three weeks with the people who do the work, mapping the real process including the exceptions and the spreadsheets. Output is a scope, a cost, and a straight answer on whether building is the right move.
Design the data model and boundaries, then build one narrow end-to-end path against real integrations. This is where estimates get replaced by evidence and where bad assumptions surface cheaply.
Two-week increments, each ending in software running in your environment. For modernisation, this runs alongside shadow execution and repeated data migration dry runs until reconciliation is clean.
Reversible cutover with rollback available, then four to eight weeks of hypercare while your team operates the system and we answer questions, fix what surfaces, and finish the documentation.
Every phase ends at a decision point you can stop at — see how that works across fixed-scope projects, embedded pods and retainers.
Stack
Questions
By owning everything from day one. The repository is yours, in your organisation, from the first commit. Infrastructure is Terraform, not console clicks. We use standard frameworks with no ZenMagix-specific layer, and handover — docs, runbooks, onboarding sessions — is a contracted deliverable, not a favour. You should be able to replace us in a week.
Buy, unless the process is a competitive advantage or no product can span the systems involved. Commodity functions — accounting, payroll, helpdesk, standard CRM — are cheaper to configure than to build. Custom earns its cost when integration count is high, rules are genuinely yours, or regulation forces behaviour products cannot provide. We will assess both honestly before quoting.
Scope decides it, not headcount. A focused internal system with two or three integrations is typically a lakhs-scale engagement over three to five months. Enterprise modernisation with data migration and parallel running is considerably larger. We quote in fixed-scope phases, each ending in working software, so you can stop after any phase.
Yes, and it is a large part of our work. We start with a paid audit: code quality, security exposure, dependency currency, infrastructure state and what is undocumented. You get a written assessment with risks ranked and a stabilisation plan, then decide whether to have us maintain it, modernise it, or replace it in stages.
Migration is treated as engineering with a pass mark. We define reconciliation checks up front — row counts, checksums, referential integrity, financial totals to the paisa — then rehearse the migration repeatedly against production copies until results are identical. Change data capture keeps the old system in sync during the overlap, so rollback stays available after cutover.
Usually in one or two places, not everywhere. AI is worth it where input is unstructured — document extraction, ticket classification, internal search. It is a liability in arithmetic, pricing, eligibility and approvals, which need to be deterministic and auditable. We are happy to build a system with no AI in it if that is the right design.
Questions about cost, timelines, IP ownership and data residency are answered on the general FAQ, and how this practice came out of blockchain infrastructure explains why we build the way we do.
Related
A paid diagnostic that tells you what is worth building and what is not.
The pipelines and quality layer every AI project stalls on.
A working AI product in weeks, scoped to prove one thing to investors or users.
See also: start with an assessment rather than a build through AI consulting · fix the pipelines and reporting underneath with data engineering · automate the manual steps around the system with AI workflow automation
Tell us what you are trying to build. We will tell you honestly whether we are the right team for it, and what it would realistically take.
