ToolNaka @ Scale — 1000 Vendors + 1000 Factories: Real-Life Benefits & Issues

ToolNaka at Scale: 1000 Vendors + 1000 Factories

Real-life benefit & issue analysis · evidence from live load tests on toolsnaka.store + full codebase audit · 2026-09-08

The one-line verdict: the product concept and workflows are genuinely valuable and reads are fast enough today (measured 260–530 req/s, zero errors) — but at 1000+1000 users the platform would hit 5 hard walls within weeks: no real payments, demo-mode OTP registration, unbounded list APIs, laptop-as-server downtime, and zero database indexes on the product catalog.

1 · Measured Performance (real load tests, not guesses)

Test	Result	Meaning
GET / (landing page), 50 concurrent	422 req/s, avg 117 ms, 0 errors (8,462 req in 20s)	Page serving is fine
GET /api/products (browse), 50 concurrent	261 req/s, avg 191 ms, 0 errors	Catalog reads OK at current data size
GET /api/products (authed), 50 concurrent	278 req/s, avg 32 ms (1 spike to 9.5 s)	Fast, but spikes appear under load
GET /api/health, 100 concurrent	529 req/s, 0 errors	Server overhead is low
SQLite writes: 16 parallel writers × 40 (DB copy)	640/640 succeeded, 180 writes/s, 0 lock errors	In-app writes serialize safely via Prisma

Test

Result

Meaning

GET / (landing page), 50 concurrent

422 req/s, avg 117 ms, 0 errors (8,462 req in 20s)

Page serving is fine

GET /api/products (browse), 50 concurrent

261 req/s, avg 191 ms, 0 errors

Catalog reads OK at current data size

GET /api/products (authed), 50 concurrent

278 req/s, avg 32 ms (1 spike to 9.5 s)

Fast, but spikes appear under load

GET /api/health, 100 concurrent

529 req/s, 0 errors

Server overhead is low

SQLite writes: 16 parallel writers × 40 (DB copy)

640/640 succeeded, 180 writes/s, 0 lock errors

In-app writes serialize safely via Prisma

Read capacity is enough for ~2000 users (real traffic peaks at a few req/s per 1000 users). The walls are elsewhere — below, in break order.

2 · What Breaks First (the realistic break-order)

#	When	What breaks	Evidence	What users see
1	Day 1	CRITICALAnyone can register with ANY phone number	With no SMS provider configured, `src/lib/sms.ts` returns `demoCode` in the API response when provider = mock. 2Factor.in key still pending (bot-blocked signup)	Fake vendors/factories flood in; phone numbers are unverifiable; spam & fraud become trivial
2	Day 1	CRITICALNo real payment rails — all money is offline	`/api/payments/route.ts` header: "SCAFFOLD — no real gateway is called here". All payments = manual bank/UPI recording	1000 factories × monthly bills = 1000+ manual UPI/bank verifications. Nobody can prove a payment was made inside the platform. Disputes have no arbiter
3	Week 1–2	HIGHProduct search degrades & misses	Search = single-field `name contains` (case-sensitive on SQLite), 0 indexes on Product table (whole schema has only 6). At 50k products every search is a full table scan	"6204 bearing" won't find "SKF 6204-2RS". Searches get slower every week. Factories give up and phone their old supplier
4	Week 2–4	HIGHList APIs return everything	`products GET` and `orders GET` have no take/skip pagination; deep includes on every row	A factory with 500 past orders waits seconds for its order list; product browse payload grows toward multi-MB; cheap Android phones choke
5	Any day (random)	HIGHLaptop-as-server downtime	3 outages in 3 days (Sep 6/7/8 evenings), each ~5 min recovery via watchdog; logged in watchdog.log. Laptop sleep/reboot/network = site down	A buyer placing a ₹2L order at 9pm sees Cloudflare error 1033. First impression destroyed. This is THE adoption killer for real users
6	Month 1	MEDIUMMulti-process SQLite lock risk	`db.ts` sets no WAL mode / busy_timeout. In-app writes serialize, but the monthly-bills scheduled task runs as a SECOND process — concurrent with live traffic	Rare "database is locked" errors exactly when month-end bills generate — the worst possible moment
7	Month 1	MEDIUMEmail limits silently block notifications	Gmail SMTP ~500/day. Order + invoice + vendor-alert emails at 1000 orders/day = hard cap hit	Vendors stop getting order emails mid-day, silently. Orders still exist but vendors "never saw it"
8	Month 2+	MEDIUMNo backups = one disk failure loses everything	Last DB backup is manual, Sep 1. No scheduled backup task	Laptop disk dies → 1000 businesses' order/billing history gone. Unrecoverable reputation damage
9	Month 2+	MEDIUMHeavy single-file dashboards	FactoryDashboard.tsx = 3,446 lines, VendorDashboard = 2,745 lines, no code-splitting evidence	Slow first load on ₹10k Android phones + weak 4G in factory sheds
10	Month 6	LOWNo reputation system	No reviews/ratings models in schema	After 6 months of transactions, still no way to know which vendor delivers on time. Trust stays offline

When

What breaks

Evidence

What users see

Day 1

CRITICALAnyone can register with ANY phone number

With no SMS provider configured, src/lib/sms.ts returns demoCode in the API response when provider = mock. 2Factor.in key still pending (bot-blocked signup)

Fake vendors/factories flood in; phone numbers are unverifiable; spam & fraud become trivial

Day 1

CRITICALNo real payment rails — all money is offline

/api/payments/route.ts header: "SCAFFOLD — no real gateway is called here". All payments = manual bank/UPI recording

1000 factories × monthly bills = 1000+ manual UPI/bank verifications. Nobody can prove a payment was made inside the platform. Disputes have no arbiter

Week 1–2

HIGHProduct search degrades & misses

Search = single-field name contains (case-sensitive on SQLite), 0 indexes on Product table (whole schema has only 6). At 50k products every search is a full table scan

"6204 bearing" won't find "SKF 6204-2RS". Searches get slower every week. Factories give up and phone their old supplier

Week 2–4

HIGHList APIs return everything

products GET and orders GET have no take/skip pagination; deep includes on every row

A factory with 500 past orders waits seconds for its order list; product browse payload grows toward multi-MB; cheap Android phones choke

Any day (random)

HIGHLaptop-as-server downtime

3 outages in 3 days (Sep 6/7/8 evenings), each ~5 min recovery via watchdog; logged in watchdog.log. Laptop sleep/reboot/network = site down

A buyer placing a ₹2L order at 9pm sees Cloudflare error 1033. First impression destroyed. This is THE adoption killer for real users

Month 1

MEDIUMMulti-process SQLite lock risk

db.ts sets no WAL mode / busy_timeout. In-app writes serialize, but the monthly-bills scheduled task runs as a SECOND process — concurrent with live traffic

Rare "database is locked" errors exactly when month-end bills generate — the worst possible moment

Month 1

MEDIUMEmail limits silently block notifications

Gmail SMTP ~500/day. Order + invoice + vendor-alert emails at 1000 orders/day = hard cap hit

Vendors stop getting order emails mid-day, silently. Orders still exist but vendors "never saw it"

Month 2+

MEDIUMNo backups = one disk failure loses everything

Last DB backup is manual, Sep 1. No scheduled backup task

Laptop disk dies → 1000 businesses' order/billing history gone. Unrecoverable reputation damage

Month 2+

MEDIUMHeavy single-file dashboards

FactoryDashboard.tsx = 3,446 lines, VendorDashboard = 2,745 lines, no code-splitting evidence

Slow first load on ₹10k Android phones + weak 4G in factory sheds

Month 6

LOWNo reputation system

No reviews/ratings models in schema

After 6 months of transactions, still no way to know which vendor delivers on time. Trust stays offline

3 · Real-Life Benefits (what users would genuinely gain)

For the 1000 vendors

Free digital storefront + catalog — a shop that never had a website now lists 50–2,000 SKUs (Excel/API stock sync built)
Leads beyond walk-ins — order requests, RFQ quotes and photo-based part requests arrive from factories they'd never cold-call
AMC/contract leads — factories post maintenance contracts; vendor offers → awarded contracts (live feature)
Structured order book — quotations → orders → challans → invoices instead of paper notebooks
Direct relationship kept — buyer calls/WhatsApp the vendor directly; platform doesn't come between them

For the 1000 factories

Vendor discovery — find new suppliers beyond the 3 known ones; compare prices via RFQ quotes
Procurement discipline — approval workflow (dept manager ≤ ₹50k, plant head above), photo-based part requests, emergency search
Billing that closes the loop — challan verification → monthly consolidated GST bills → disputes → partial payments → vendor-wise outstanding (fully built & tested)
Full trace — order → approvals → challan → invoice → payment chain in one view; audit-proof
Planner & repeat ordering — monthly purchase planning, quick reorder

4 · Real-Life Issues Users Will Complain About (beyond tech)

5 · What To Do Before Inviting 1000+1000 (priority order)

Priority	Fix	Effort
P0	Buy the VPS (~₹500/mo) and migrate — the deploy kit (Dockerfile, docker-compose, Caddyfile, deploy.sh) is ready in the package. Kills the outage problem entirely.	½ day (user buys VPS, provide SSH)
P0	Finish 2Factor.in signup (manual, bot-blocked for automation) and set the API key — kills demo OTP.	10 min manual
P1	Wire Razorpay/Cashfree (needs merchant KYC — scaffold comment in code already marks the spot): at minimum payment-intent links on invoices so payments get PROVEN inside the platform.	2–3 days + KYC
P1	Pagination + indexes: take/skip on products & orders, @@index on Product(name), Product(vendorId, category), Order(factoryId, status), Order(vendorId, status), multi-word search split.	1 day
P1	Automated daily DB backup (scheduled task → cloud storage), enable WAL mode + busy_timeout in db.ts.	2 hours
P2	GSTIN verification + vendor verification badge; reviews after delivered orders.	2–4 days
P2	Code-split the dashboards; lazy-load tabs; compress product photos.	2–3 days
P3	City-by-city launch plan (Rajkot cluster first): hand-onboard 50 vendors with real prices before inviting factories — never launch empty.	Ongoing

Priority

Fix

Effort

Buy the VPS (~₹500/mo) and migrate — the deploy kit (Dockerfile, docker-compose, Caddyfile, deploy.sh) is ready in the package. Kills the outage problem entirely.

½ day (user buys VPS, provide SSH)

Finish 2Factor.in signup (manual, bot-blocked for automation) and set the API key — kills demo OTP.

10 min manual

Wire Razorpay/Cashfree (needs merchant KYC — scaffold comment in code already marks the spot): at minimum payment-intent links on invoices so payments get PROVEN inside the platform.

2–3 days + KYC

Pagination + indexes: take/skip on products & orders, @@index on Product(name), Product(vendorId, category), Order(factoryId, status), Order(vendorId, status), multi-word search split.

1 day

Automated daily DB backup (scheduled task → cloud storage), enable WAL mode + busy_timeout in db.ts.

2 hours

GSTIN verification + vendor verification badge; reviews after delivered orders.

2–4 days

Code-split the dashboards; lazy-load tabs; compress product photos.

2–3 days

City-by-city launch plan (Rajkot cluster first): hand-onboard 50 vendors with real prices before inviting factories — never launch empty.

Ongoing

6 · Honest Bottom Line

At 20 vendors + 50 factories (today): the platform works, feels useful, and the billing/AMC/approval flows are genuinely better than WhatsApp + notebooks. No user will notice the tech limits yet.

At 1000 + 1000 (the question asked): the value proposition is real — both sides gain discoverability, discipline, and records they can't get on WhatsApp. But the platform as deployed today would suffer: fake registrations (demo OTP), payment chaos (manual recording of ~1000 monthly settlements), a worsening search experience (no indexes + single-field search), multi-MB list payloads, and random 5-minute outages every time the laptop blinks. It would survive, but trust would bleed out through exactly the things B2B buyers care about most: reliability and payment certainty.

The gap between "works for 100 users" and "works for 2000 users" is about 8–10 focused days of work (VPS migration, real OTP, payments scaffold→real, pagination+indexes, backups, WAL) — all with clear paths already prepared in this codebase.

Method: live load tests via autocannon against the production server (reads) and a DB copy (16-writer concurrency test) · static audit of every API route, both dashboards, auth/OTP/SMS/mail libs, schema indexes, payments scaffold, watchdog + ops logs · 2026-09-08 · toolsnaka.store