This is a manifesto. A set of non-negotiable principles for anyone building technology for India's real economy — the street vendors, small shops, and chaos-driven counters that serve 80% of the population.
These rules emerged from watching technology fail. From seeing expensive tablets gather dust. From hearing shop owners say "yeh sab hamare liye nahi hai" (this isn't for people like us).
If your technology violates any of these rules, it will fail. Not might fail. Will fail.
Rule 1: Zero Hardware Dependence
If your solution requires buying new hardware, you've already failed.
The moment you say "you'll need a tablet" or "we'll install a kiosk," you've lost 90% of your potential users. Not because they can't afford it — though many can't — but because hardware is:
- A capital expense that feels like a gamble
- Something that can break, be stolen, or become obsolete
- A dependency on technical support they don't have access to
- A signal that "this is complicated tech stuff"
The smartphone revolution already happened. 750+ million Indians have devices in their pockets. UPI works. Browsers work. Use what exists.
If the customer has a phone, that's your hardware. If the owner has a phone, that's your dashboard. If neither has a phone, your market isn't ready — but that's increasingly rare.
Test: Can someone use your system with devices they already own? If not, go back to the drawing board.
Rule 2: Zero Training Required
If your system requires a training session, it's too complicated.
"Easy to use after a 30-minute tutorial" is not easy to use. It's 30 minutes of friction that most people will never complete.
Real India doesn't have time for tutorials. The shop owner is busy. The staff is untrained. The customer is impatient. Everyone has 10 seconds of attention, maximum.
Your interface must be obvious. Not "intuitive after explanation" — actually obvious. A first-time user should understand what to do within 5 seconds of looking at the screen.
How to achieve this:
- Use patterns people already know (WhatsApp, Swiggy, UPI)
- Minimize options. Three choices, not thirty.
- Use visual language. Icons over text. Colors over labels.
- Make the default action the right action.
Test: Can a complete stranger use your system correctly on the first try, without any explanation? If not, simplify further.
Rule 3: Solve for Chaos, Not Data
The goal is not to capture data. The goal is to stabilize the environment.
Traditional tech thinking: "We need to digitize records for better analytics."
Reality: The shop owner doesn't care about analytics. He cares about surviving rush hour without losing his mind.
Data is a byproduct of a stable workflow, not a goal. When chaos is reduced, accurate records naturally emerge. When chaos persists, no amount of data entry discipline will save you.
Ask not "How do we capture this information?" Ask "How do we eliminate the chaos that makes information unreliable?"
- Reduce shouting → information becomes clearer
- Reduce memory load → errors decrease
- Reduce handoffs → nothing gets lost
- Reduce cognitive overhead → staff can focus on their actual job
Test: Does your system reduce environmental chaos, or just add a digital layer on top of existing chaos?
Rule 4: Human-in-the-Loop Always
Never fully automate. Always leave space for human judgment and override.
Fully automated systems break in ways that humans can't fix. They create dependencies on technical support that doesn't exist at 7 PM in a tier-3 town.
The right model: Automation handles the routine. Humans handle the exceptions.
Examples:
- Order is captured automatically, but human confirms "done" when prepared
- Payment is tracked automatically, but human can mark "paid at counter"
- Queue is managed automatically, but human can adjust priority
This isn't a limitation — it's a feature. The human-in-the-loop provides:
- Fallback when technology fails
- Flexibility for edge cases the system didn't anticipate
- Accountability and trust
- Psychological comfort for users who don't fully trust automation
Test: If your system breaks completely, can the business still function? If the answer is "no," you've created a dangerous dependency.
Rule 5: Graceful Degradation
When things go wrong — and they will — the system should fail soft, not hard.
Internet drops. Phones die. Batteries run out. Printers jam. These aren't exceptions — they're the daily reality of operating in India.
Your system must handle failure gracefully:
- Network down? Queue orders locally, sync when connection returns.
- Payment failed? Still issue token. Collect at counter.
- Printer jammed? Show token on screen. Verbal backup.
- Phone died? Process should still work for other customers.
The cardinal sin is blocking the workflow. A customer standing at the counter cannot wait for "technical difficulties." The chai must flow.
Design for the worst case, not the demo case. The demo always has perfect WiFi. The real world has neither.
Test: Unplug the internet. Kill the printer. Does the system still enable orders to be taken and fulfilled? If not, you're not ready.
The Anti-POS Commitment
We reject:
- Expensive hardware requirements
- Complex dashboards for simple needs
- Training sessions and onboarding
- Data-first thinking that ignores human chaos
- Brittle systems that break under pressure
We embrace:
- Using devices people already own
- Interfaces that explain themselves
- Workflow design over software features
- Human-in-the-loop resilience
- Graceful degradation under failure
This is not a compromise. This is a design philosophy. Technology for real India must be built differently — not as a watered-down version of Silicon Valley products, but as a fundamentally different approach to the problem.
The bottom of the pyramid doesn't need "simpler enterprise software." It needs purpose-built solutions that respect the physics of chaos, the limits of infrastructure, and the dignity of people who've been told technology isn't for them.
It is. We just need to build it right.