Enterprise applications
Systems that carry a whole organisation
What this means in practice
The six things that separate a system from a website
Many roles, one truth
A branch manager, an accountant, a regional head and an auditor each need a different view of the same record — and none of them may quietly see something they should not. Role-based access designed at the data layer rather than hidden in the interface, because a screen that merely does not render a button is not access control.
Approvals that mean something
Multi-step approval chains with delegation, escalation and a timestamped record of who approved what on which version. The version part is what matters in a dispute: an approval attached to a document that was edited afterwards is not an approval.
An audit trail you can defend
Every change written as an event, not as an overwrite — old value, new value, actor, time and reason. Reconstructable months later, which is the only test that counts, and the reason financial and regulated operations can run on it at all.
Money that reconciles
Collections, settlements, refunds, payouts and the ledger that has to balance against a bank statement at the end of the month. The integration is the easy half; the reconciliation and the failure paths are where these projects actually go wrong.
Integrations that survive the other side
Payment gateways, accounting software, government portals, logistics, messaging. Built assuming the other system will be slow, will time out and will occasionally answer twice — so a retry cannot charge a customer a second time.
Migration without a shutdown
Moving off spreadsheets or off software you have outgrown, with both running in parallel until the new one is proven. A cutover weekend with no way back is a decision nobody should be asked to make on a Sunday night.
How it runs
Six phases, and the first one is not code
Study what actually happens
Not the process as documented — the process as performed, including the workarounds. The workarounds are the requirements; a system that ignores them is the one staff quietly keep a spreadsheet beside.
Architecture and a written decision record
The structure, the data model, the integrations and the trade-offs, written down with the reasoning. So that in two years somebody can see why a choice was made instead of guessing and reversing it.
Build in usable slices
One department or one branch at a time, live and in real use, rather than an eighteen-month build revealed at the end. The first slice is in production while the second is being written.
Migrate and run in parallel
Historical data moved and verified by reconciliation, not by inspection. Both systems live until the numbers agree for a full cycle.
Train the people who will use it
On their own data, in their own branch. Adoption is where most of these projects fail, and it fails quietly — the software works and nobody uses it.
Operate it
Monitoring, backups tested by restoring them, an on-call path and a roadmap reviewed quarterly. A system nobody owns after launch degrades whether or not anybody changes it.
Stack
Named, so it can be checked
Product
- Next.js
- React
- TypeScript
- Tailwind CSS
- React Native
- Expo
Backend
- NestJS
- Node.js
- PostgreSQL
- Prisma
- Redis
- WebSockets
Cloud
- Vercel
- Render
- Cloudflare
- Docker
- Object storage
- CDN
Money
- Razorpay
- Stripe
- Cashfree
- UPI
- Payouts
- Subscriptions
AI
- Google Gemini
- Claude
- Vision
- Speech
- Embeddings
- Agents
Growth
- Technical SEO
- Meta Ads
- Google Ads
- WhatsApp Business
- Analytics
Bring the process, not the specification.
The most useful first meeting is a walk through what your team does on an ordinary Tuesday. The specification comes out of that — and it is ours to write, not yours.