iSell Back is a device recommerce platform for India. People sell their MacBook or iPad from home: they get a price in seconds, an agent collects the device at their door, and the payout is transferred after inspection.
This page is the engineering and product record behind it. Every number below is
countable in the source repository — it is not a pitch deck estimate.
The Android app is still listed on Google Play as
BuyBack Elite:
that listing and the package id com.buybackelite.app are deliberately
preserved so existing installs keep updating, while the product name moved to
iSell Back.
iSell Back started as a single-business prototype with one Android app and a basic sell flow. It was rebuilt through AI-assisted, spec-driven development, and the system is now six shipped surfaces — three web applications and three Android applications — on a backend of 47 database migrations, ~77 tables, 119 Postgres functions and 139 row-level-security policies, with 116 hand-written test files and a 6-job CI pipeline that gates every push. Pricing became fully server-authoritative, the schema became multi-tenant, and the customer bundle dropped from 297 KB to 134.8 KB gzipped. The current focus is launch infrastructure for the India rollout.
The most useful way to read this project is as a delta. Here is the state of the system at the end of the prototype phase, against the state of the system today.
| Dimension | Prototype phase | Today |
|---|---|---|
| Shipped surfaces | 1 Android app + prototype web | 3 web apps + 3 Android apps + 1 shared package |
| Tenancy model | Single business, hard-coded | Multi-tenant, business_id + additive RLS |
| Who decides the price | Device could compute and display its own price | Server only — 14 canonical_* RPCs |
| Database | Base schema | 47 migrations, ~77 tables, 119 functions |
| Access control | Partial RLS | 139 policies, RLS enabled on 87 tables |
| Automated tests | None in CI | 116 test files, 6-job pipeline on every push |
| Customer first-load JS | 297 KB gz, one chunk, 0 split points | 134.8 KB gz, budget-gated at 250 KB |
| Product scope | Sell your device to us | + multi-store discovery, offer comparison, refurb marketplace |
| Payouts | Manual | Razorpay, fail-closed webhook, idempotent reservation |
Every figure here is a direct count from the repository — migration files, SQL statements, route declarations, test files. They are reproducible, not rounded up.
Three sides of the business each need their own interface: the customer selling a device, the field agent collecting it, and the operator running pricing and payouts. Each exists on both web and Android.
isellback.com · Android
About 30 routes on web. A 7-step sell wizard, store discovery by pincode, offer comparison across stores, refurbished listings and per-request lifecycle tracking.
com.buybackelite.app v1.0.4agent.isellback.com · Android
8 pages for the person at the customer's door: assigned pickups, on-site condition verification, photo capture, customer signature and history.
com.buyback.agent v1.0.1control.isellback.com · Android
22 pages of back office: the price engine and its governance, condition deductions, competitor price sync, agent management, fraud alerts, payout administration and store verification.
com.buyback.app v1.0.1
The customer picks a model, storage and condition. The server — never the device
—
calculates the price through canonical_calculate_pricing and issues a
quote.
A pincode resolves which stores actually serve that area, and each returns a fresh server-issued offer. Customers never see a pre-deduction headline number that later shrinks.
An agent self-assigns the pickup, verifies the device on site, captures photos and a signature, and the inspection result produces a revised quote the customer accepts or declines.
Payout is reserved in SQL with an idempotency key, executed via Razorpay, and confirmed by a fail-closed webhook that re-fetches the authoritative record from the provider.
The credits funded AI-assisted development in Kiro, and specifically its spec workflow:
requirements first, then a design, then a task list that gets worked through and checked off.
Six specs live in the repository under .kiro/specs/, each with a requirements
document, a design document and a tracked task list. That is where the money went, and the
artifacts are auditable.
| Spec | Scope | Tasks done | Progress |
|---|---|---|---|
| ui-overhaul | Presentation and delivery only. Forbidden from touching pricing, RLS or payments. | 54 / 54 | |
| multi-tenant-marketplace | Turn a single-business system into a marketplace, purely additively. | 52 / 75 | |
| production-hardening | Server-owned command boundaries, private media lifecycle, authoritative pricing. | 61 / 92 | |
| india-launch-audit | Drive every finding from the internal audit to closure. | 27 / 37 | |
| store-discovery-launch | The five items standing between the product and marketing spend. | In progress | |
| mobile-launch-readiness | Android release readiness across all three apps. | Scoped |
Spec tasks closed across the four specs that carry task lists.
Every spec was written before its implementation, not reverse-engineered afterwards.
A full internal audit in July 2026 reviewed the code against those specs and logged 11 findings.
Anyone can ship screens. These are the invariants underneath, which is where a money-handling product either holds up or does not.
14 canonical_* database functions are the only thing allowed to produce a
number. The audit found one Flutter screen still recomputing a price locally and that
code was deleted. Clients display prices; they never derive them.
Every push spins up a throwaway PostgreSQL 16, applies all 47 migrations in order, verifies checksums and ordering, then runs a two-tenant harness that asserts one business cannot read another's rows.
The Razorpay webhook verifies a timing-safe HMAC over the raw body, de-duplicates events with payload-hash conflict detection, re-fetches the authoritative record from the provider, cross-checks amount, currency and fund account, and only permits monotonic status transitions.
Both web source trees were swept: no service-role key and no webhook secret is exposed through a browser-visible variable. Privileged work happens in serverless handlers, not the client.
ID proofs, verification photos and signatures move to a receipt-based private pipeline: an insert-only capability scoped to the uploader's own user id, with retention rules and an access audit trail. It ships behind a flag, currently off, ahead of the data cutover.
Request, pickup, inspection and inventory each own their state, coordinating through an outbox/inbox with idempotent command middleware. The customer lifecycle screen adds no authority of its own — labels and permitted actions come from a versioned server contract.
The customer site went from a single 1,112 KB bundle with zero code-split points to a route-split app at 134.8 KB gzipped on first load. CI fails the build if first-load JavaScript crosses 250 KB gzipped, so it cannot quietly regress.
This matters commercially: the audience is on Indian mobile networks, and the database currently sits in Seoul at roughly 150–250 ms per round trip.
Stated plainly, with no aspirational entries. This is what the system runs on today.
A platform that holds someone's device and their payout details cannot ship on optimism. Two habits keep this system honest with itself: nothing sensitive goes live until it has been reviewed, and anything not yet verified stays switched off rather than switched on and hoped for.
On the July 2026 audit: it was a static code review. The sandbox it ran in failed to start, so no build, linter or test runner was executed during that pass. It is cited here as a review, not as a green test run.
The build phase is largely done. The remaining distance to a marketed launch in India is mostly infrastructure and verification rather than new features, and here is exactly what that consists of, in priority order.
The single largest user-facing problem. Every request from an Indian customer currently crosses to Seoul and back at 150–250 ms. The designs already minimise round trips to compensate, but the real fix is regional. This means standing up a parallel environment, replaying all 47 migrations, migrating storage objects and cutting over.
The canonical-pricing and two-tenant isolation harnesses run green on ephemeral Postgres in CI on every push. Re-running them against the provisioned India environment is the sign-off step for the regional cutover.
Both are finished code sitting behind flags. Enabling them requires provisioned credentials, a storage migration for existing objects, and a reconciliation pass to confirm nothing was orphaned.
Route the eleven built marketplace screens, close out the mobile launch readiness spec, and get all three apps onto a repeatable release process rather than manual builds.
The multi-tenant schema, store verification flow and offer-comparison engine are built and currently exercised by fixtures. The next phase replaces fixtures with actual merchants, which is what turns this from a buyback shop into a marketplace.
Every item above is infrastructure and verification work. The product surface is built; what remains is putting it on the right regional footing, signing off the cutover, and replacing fixture data with real partner stores. That is the whole distance to a marketed launch in India.
Co-Founder & CEO
Business roadmap, store partnerships, pricing strategy and operations.
Co-Founder & CTO
System architecture, the web and Flutter applications, database schema and row-level security, payments integration and the CI pipeline.
The fastest way to check any claim on this page is to use the product. Get a quote on a MacBook or iPad without creating an account.