Neev

Bringing AI to an industry that still runs on WhatsApp.

Context

India has roughly 63 million MSMEs. Most of them (textile traders, regional distributors, small manufacturing units) operate on WhatsApp conversations, paper ledgers, a Tally install, and a few shared spreadsheets. This isn't backwardness. It's a pragmatic equilibrium built on trust relationships, cash-flow timing, and a low tolerance for software that doesn't survive contact with the day.

Any AI product aimed at this audience has to earn its place under that daily reality, not above it. That means the platform has to be useful before it's smart — and the smart parts have to be invisible enough that an operator who has never touched AI before doesn't have to think about them.

Problem

Distributors in the textile supply chain lose time and money at very specific seams: order capture (still mostly over WhatsApp), ledger reconciliation (still mostly by hand), GST-compliant invoicing (patchy), and memory of who owes whom what (fragile, relationship-dependent). Generic ERPs don't fit because they assume a workflow that doesn't exist in this business yet. Pure chatbot layers don't fit because they solve a symptom, not the operations below it.

The actual problem is building a platform with enough structural honesty that a real MSME can adopt it incrementally, then layering AI in where it removes friction rather than demanding new behavior.

Approach

The architecture reflects the operating environment, not a tech-stack wishlist. Four principles shaped it.

• Modular monolith with multi-tenant discipline. One deployable, clean module boundaries, tenant_id enforced at every persistence boundary. This trades early micro-service flexibility for operational sanity at the scale MSMEs actually operate. The wrong distributed system on a two-person team costs far more than modularizing later.
• Textile distribution as beachhead, not as a limit. The data models are designed so the platform generalizes to adjacent MSME verticals. The first release narrows to where there is direct operator input and real feedback.
• AI where it reduces typing and memory load, not where it replaces judgment. Order capture, reconciliation assistance, and narrative summarization over the operator's own ledger — not autonomous decisioning. The operator stays in control of the outcome.
• Engineering process as proof of intent. PRD, ADRs, roadmap, changelog, process-gate scripts. Not process theatre. Process that earns trust from any future technical buyer who looks under the hood.

What shipped

The first deployable version of the Neev platform is live. It ships a multi-tenant foundation with strict tenant_id invariants throughout the persistence layer, core domain models for the textile distribution workflow (orders, ledger, parties, items), and the first AI-assisted surfaces in the operator workflow. Public engineering artifacts (README, PRD, architectural decision records) are available alongside the build.

The stack is Next.js on the front end against a Postgres-backed monolith, with Neev's own process-gate scripts keeping the repo honest across builds.

(Abhishek to fill: first tenant onboarded, measured effect on at least one workflow, specific milestones from PRs shipped to date.)

Trade-offs

Monolith over microservices. Deliberately. A small team debugging a distributed tracing problem while onboarding a first paying customer is a bad place to be. The module boundaries are clean; the leap to separate services, if it ever makes sense, is a refactor, not a rebuild.

Vertical-first over horizontal-first. Textile distribution is the wedge. A horizontal "MSME platform" from day one would have drifted into genericism and served no vertical well. The constraint is the product.

Owner-operator UX over admin-console UX. The primary user sits on a chair in a shop, often on a phone. Desktop-dense dashboards aren't the frame. The UI is built around how a distributor actually moves through a working day.

Honest scope

(Abhishek to fill: name what's live vs. what's in progress, and where real operators are vs. aren't using it yet. Resist the urge to overstate — understated and true beats polished and inflated for this audience.)

The engineering artifacts are real and reviewable. The operator validation is in progress. That's the honest state of a system built correctly from the start, not retrofitted after the fact.

What I'd do next

(Placeholder — fill after v1 stabilizes. Candidates: vernacular-language input for WhatsApp order capture; offline-first mobile operator app; reconciliation assistant as the first full agent surface with audit-grade output.)