IFW Commission System
A private commission system for Indian Foundry Works. Operators claim, managers approve, IFW pays — and every step leaves a record. Built as a login-gated Next.js application, self-hosted rather than handed to a platform.
- Next.js App Router
- React Server Components
- Turbopack
- nginx
- Role-based access
- PDF generation
- Multi-language
01 — The Problem
A process that moves money, running without a record
Indian Foundry Works pays commission to operators involved in its machinery sales. An operator submits a photo, an account number and supporting proofs; a manager reviews the claim and approves it; IFW pays.
That is the whole of the domain, and IFW wanted it to run as a system with an auditable record of every claim rather than as an informal exchange of messages and paperwork.
Three things put this well past “a form with an approve button”. There is money at the end of the chain, so a mistake is a payment to the wrong place rather than a bad layout. There are bank details in the middle — the most sensitive data the business handles. And the people using it do not share a language: the claim flow has to work in English, Hindi and Punjabi.
There was also a constraint pointing directly against the obvious build. IFW wanted a person to verify each claim. Not a rules engine, not an auto-payout threshold. A human.
02 — The Approach
Build it as a private system, and put the sensitive parts on the server
Three decisions did most of the work, and all three follow from the same fact: this application holds other people’s bank details.
An application, not a website
Nothing in this system is for the public. Its entire web-facing surface is a login screen — the application is gated, marked noindex, and served behind nginx on Ubuntu rather than pushed to a managed hosting platform.
WhyA managed platform is the right default for a marketing site and the wrong one for a system holding commission records and account numbers. Self-hosting keeps the deployment, the logs and the data together in one place that can be pointed at and reasoned about, with no third party sitting in the middle of it.
Server-first, using React Server Components
The application is built on the Next.js App Router with React Server Components, compiled with Turbopack. The parts that matter — which claims a given role may see, what a manager is permitted to act on, and anything that touches bank details — resolve on the server.
WhyIn a server-first architecture the default is that data-access code never leaves the server, and only what a page actually needs to display crosses to the browser. For a system like this, that default is worth more than any convenience a client-rendered alternative buys you — because the mistakes it prevents are the expensive kind.
Keep the human in the loop, and build for them
IFW asked for manual verification, and we did not quietly design around it. Approval is a real state that a claim moves through, carrying the evidence a reviewer needs and recording who acted on it.
WhyAn automatic approval rule would have been easier to build and worse for the client. What they were buying was not speed; it was a defensible record of a named person having looked at a claim before money moved against it. Automating that away would have deleted the product.
03 — Key Technical Challenges
Two problems worth solving properly
Building for a human decision instead of around it
Every instinct in this kind of build pushes toward automating the approval — thresholds, rules, auto-payout above a certain confidence. IFW explicitly did not want that, which inverts the problem. The system’s job is no longer to decide. It is to make one person’s decision fast, consistent, and permanently attributable.
Get that wrong and the manual step becomes the bottleneck the client is blamed for — a queue of claims waiting on someone to open five things in four places before they can say yes.
Approval is modelled as a state the claim occupies rather than a checkbox someone ticks. The evidence a reviewer needs — the photo, the account number, the supporting proofs — is gathered against the claim itself, so the judgement is cheap to make. And the act of making it is recorded: who submitted, what they attached, who acted, and when.
The system contributes no verdict of its own. Its contribution is that every verdict has a name and a timestamp attached to it, and that the claim cannot quietly change shape afterwards.
The manual step IFW insisted on stops being the slow part of the process and becomes the audit trail they asked for in the first place.
Three scripts on a form that ends in a bank account number
The claim flow is used in English, Hindi and Punjabi — three languages across three scripts: Latin, Devanagari and Gurmukhi. It is tempting to file that under presentation polish. It is not.
If someone cannot read the label above a field, the number they type into it may be the wrong number, and on this form the failure mode is money arriving somewhere it should not. Interface language sits directly next to the most sensitive field in the system, which makes it a correctness requirement rather than a courtesy.
The claim flow is available in all three languages rather than shipped in English with translated help text bolted alongside it — the labels a person reads while entering their account details are in the language they actually read.
The language someone happens to read in stops being a source of error in a process that moves money.
04 — What We Built
Claim, review, approve, pay — with a record at every step
Claim submission
- QR-based entry into the claim flow
- Photo upload and supporting proofs
- Account details for payment
- Available in English, Hindi and Punjabi
Review & approval
- Manager approval as an explicit state
- Submitted evidence held against the claim
- Who acted, and when, recorded per claim
Payout record
- Generated PDF receipts
- A durable artifact for each settled claim
Access & platform
- Role-based access control
- Bank details held encrypted
- Login-gated and
noindexthroughout - Next.js App Router on self-hosted nginx
05 — The Result
A commission process that leaves evidence behind it
IFW runs commission claims through a system that records them. A claim carries its own evidence, an approval carries the name of the person who gave it, and a settled claim leaves a receipt — which is what “auditable” has to mean if it is going to mean anything.
The manual verification the client asked for survived the build intact. It is still a person deciding; the system just makes that decision quick to reach and impossible to lose.
This is a closed system holding commission records and bank details, so the link above opens a login screen and stops there — and we have no throughput or usage figures to quote, because that data belongs to the client. What can be verified from outside is the login page itself; everything else here is a description of what we built rather than a number we are asking you to take on trust.
Have a process that needs to leave a record?
We build internal systems that hold up to being audited — and we will tell you when a human belongs in the loop.
Start a conversation