The collection agent is on a two-wheeler between two villages outside Bhilwara, with a borrower's cash in her bag and no signal on her phone. The NBFC that employs her wants a field collection app, and the brief arrives with three extras attached: an AI feature, offline support and, later, a super app for its customers. All three get asked for as trends, and each one carries a build cost that is easy to miss on the first estimate.
Three requests that break the same assumption
The first version of an app usually assumes the server is reachable, its answers are right, and there is one product behind one login. Each of these three requests breaks part of that.
- A model to call
- A way to judge answers
- A fallback on failure
- Rules on data sent
- Local database
- Sync queue
- Conflict rules
- Tests with no signal
- Shared login
- Module boundaries
- Separate release control
- Agreements between teams
The work in each column sits outside the screens, which is why it gets underestimated.
An AI feature assumes a model can be reached and trusted. Offline support moves the data onto the device. A super app puts several services behind one identity and one shell. None of these is a screen you can draw in a mockup, and that is why they surprise people at estimate time.
An AI feature is easy to build and hard to judge
For the NBFC, the obvious AI feature is reading the handwritten receipt the agent photographs, so she does not type the amount and borrower ID by hand. The build can be small. The hard part is knowing whether the output is right, and noticing when it gets worse. Our post on reading forms and receipts with vision models goes into where that accuracy breaks.
Settle four things before anyone writes code:
- What is the task, and what does a wrong answer cost the borrower?
- Who checks the output, and can the agent correct it on the spot?
- What personal data goes to a third party, and has the compliance team agreed?
- What does each call cost, and what happens when usage grows?
A misread amount on a collection receipt is a dispute at the branch next week. So the app should show the extracted amount on screen and make the agent confirm it, and the photo should stay attached to the record. On a cheap phone with a smudged camera lens in poor light, the model will get some receipts wrong; design for that rather than hoping.
Cost needs its own line in the plan. A feature that calls a model on every screen load behaves very differently with ten agents than with two thousand, so set a limit per user and decide what the app shows when it is reached. Our post on cost controls for an LLM feature covers caching and per-user budgets.
And when there is no signal, the receipt reader cannot run on a server. Either the photo waits in the queue on the device and the agent types the amount for now, or a small model runs on the phone. Pick one before the build starts.
Offline is a decision per feature
Patchy networks are not an edge case for a collections team. Offline-first answers that, but not for every screen. Split the features into three groups: those that only read cached data, those that let the user edit and sync later, and those that cannot work without a connection, such as a live UPI payment.
- 01List features
- 02Needs live data?UPI payment, live status
- 03Read-only cacheborrower list, dues
- 04Editable offlinevisit notes, receipts
Only the last group needs conflict rules, and it is the expensive one.
Editable-offline is the expensive group because it needs conflict rules. The agent records a cash collection offline at 11 am. The branch posts a cheque for the same borrower at noon. Both reach the server in the evening when her phone finds signal at the petrol pump. Which balance is right is a business rule, not a sync setting, and somebody at the NBFC has to write it down before anyone writes the sync code.
Then test it the way the agent will meet it. Airplane mode on, change the same record on the phone and in the branch system, reconnect, and check the result against the rule. Do it again with the phone restarted in between, because the queue on the device has to survive a reboot and a dead battery.
A super app works only when users overlap
Bundling loans, insurance and payments into one customer app can save people a few installs. It works when the services share an audience and an account. It is much harder when they belong to different teams with their own release plans, and in an NBFC the lending, insurance and collections teams usually do.
Businesses like super apps because they keep customers inside one place. That is also a dependency. A fault in the shared login or the shell takes every service down with it, so each module needs a way to be switched off from the server without a new release. Our post on how a mobile app is structured so it can keep growing shows where those boundaries sit. Shell decisions are hard to reverse, so agree on the interface between module and shell before the second module starts.
Where these projects come apart
AI gets added as a feature with no plan to measure whether it helps. Offline gets promised for the whole app and then quietly limited to a few screens late in the project. Sync conflicts get discovered by users, as lost edits, and in a collections app a lost edit is a borrower who paid and is still marked overdue. A super app gets built by bundling existing apps without a common login. And each service keeps its own release process, so the shell can never be released safely.
Order of work
- Pick the single user task that most needs improving. For the NBFC, that is recording a collection.
- Decide whether AI, offline support or a shared shell is the best way to improve it, or whether none is.
- Write the failure behaviour first: what the agent sees when the model is wrong, the network is down, or a module is switched off.
- Build the smallest version and test it on the cheapest phone your agents carry, in the field, not the office.
- Add the next capability only when the first one is stable.
Do step three before anything else. What the agent sees when things fail decides how much each of these three actually costs to build.
