Recycling App Development: Pincode-Level Architecture Inside Epicircle

Recycling app development in India fails at the pincode, not the city. Scrap rates, accepted material categories, collection partners and vehicle types change street by street, so a national recycling marketplace needs configuration at the pincode level from day one rather than a city dropdown bolted on later.

Epicircle is a circular economy platform we built at AY Technologies: a customer app on iOS and Android, a partner app for collection agents, an admin web panel and a public website at epicircle.earth. The interesting part of that build was never the pickup screen. It was the decision to make the pincode, not the city, the unit of configuration. This post explains what that means, what it costs you in engineering effort, and what the Indian tax and payments rules force you to build alongside it.

Why a recycling marketplace is a pincode problem

An Indian PIN code is not a flat label. India Post’s six-digit scheme encodes a hierarchy: the first digit is the postal zone, the first two identify the sub-zone, the first three identify the sorting district, the fourth is the delivery route, and the last two identify the delivery office. India Post publishes the full state-wise lists in its RTI pincode directory. That hierarchy is a gift to anyone building logistics software, because it gives you a ready-made way to roll up and roll down coverage without inventing your own geography.

The reason it matters for scrap is economics. What a collection partner can pay for a kilogram of cardboard is set by three things: the gate rate at the aggregator who will buy it from him, the distance his vehicle travels to reach you, and whether he can fill a load in one trip. All three change inside a single metro. Delhi NCR alone spans Delhi (110 series), Faridabad (121 series), Gurugram (122 series) and Noida (201 series), sitting across three states and a union territory, each with different aggregators, different traffic and different municipal rules. A single “Delhi NCR” rate card is wrong in every one of those places.

City-level modelling breaks in three predictable ways. Partners refuse low-value jobs at the city rate and your cancellation numbers climb. Categories that no local aggregator buys stay visible in the app, so customers book pickups that nobody wants. And when you expand, you cannot switch on half a city, which is exactly what a careful launch requires.

What pincode-level architecture means in practice

It means one table, keyed by pincode, that every other service reads before it decides anything. Not a feature flag. A serviceability record that carries the rate card version, the active category set, the partner pool, the slot template and the commercial terms for that pincode.

The serviceability check has to be fast and honest

The first screen a user sees asks for a pincode, and the answer has to arrive in well under a second because everything else depends on it. Keep the lookup in a cache keyed by the six digits, fall back to the sorting district prefix when a new pincode has not been mapped yet, and never guess. If a pincode is not served, say so and capture the request. Those unserved-pincode requests become the single most useful expansion dataset the business owns, and they cost nothing to collect.

Two rules we would enforce on any similar build. First, rate cards are versioned and immutable once used: you never edit a rate that a live order was quoted against. Second, every pincode belongs to a group, and operators edit groups, not individual pincodes, or your ops team will be maintaining thousands of rows by hand within a quarter.

Modules recycling app development actually needs

A scrap marketplace looks like a two-sided marketplace with a heavier operational tail. The customer app is the smallest part of the system. On Epicircle the surfaces were a customer app for iOS and Android, a partner app for collection agents on Android, and an admin panel for the operations team. The full breakdown is in our Epicircle recycling app case study.

• Customer app: pincode check, category selection with indicative rates, slot booking, live tracking, weighing confirmation, payout status, order history.
• Partner app: job queue, route order, on-site weight entry with photographs, category correction, customer acceptance capture, collection summary, settlement view.
• Rate engine: category rates, pincode groups, versioning, scheduled changes, live commodity feeds for metals.
• Dispatch: ranked partner assignment per pincode, acceptance windows, reassignment on decline, capacity limits per partner per slot.
• Reconciliation: quoted value against weighed value, variance thresholds, evidence photographs, approval trail.
• Payouts: customer payment, partner settlement, deductions, failed transfer retries.
• Compliance and reporting: tonnage by category and pincode, tax documents, audit logs.
• Support: dispute queue, refunds or top-ups, partner blacklisting, customer contact history.

Teams new to this consistently underestimate the last four. If you are scoping the build, our note on building a two-sided marketplace covers the supply-side problems that show up before you have any real volume, and the mobile app development cost breakdown gives you realistic ranges for the app layer.

Rate cards, live metal prices and the trust problem

Scrap pricing has a structural trust gap. The customer is quoted a rate in the app, then a stranger arrives with a weighing scale. Every complaint in this category traces back to the gap between the quote and the final number, and no amount of design polish fixes it. Product mechanics do.

Three mechanics we would build into any platform of this type. Quote lock: the rate shown at booking is held for a defined window, and if the window expires the app re-quotes before the trip is scheduled. Evidence capture: the partner app records the weight reading and photographs at the doorstep, and the customer approves the final line items on the partner’s screen before payment is released. Variance thresholds: an order where weighed value differs from the quote beyond a set percentage routes to a human before it settles, rather than silently paying out.

Commodities add a second layer. Epicircle carries live market rates for gold and silver, and anything indexed to a live feed needs the feed timestamp stored against the quote, a stale-data rule that falls back to the last operator-approved rate, and a hard cap on how far an automatic rate may move in one step. A pricing engine that blindly trusts an upstream feed will eventually quote a number that ruins a day of margin.

Payouts, escrow and GST for recycling app development

This is the part that surprises founders. A recycling marketplace collects goods from unregistered households and sells them to registered buyers, which puts it squarely inside two sets of Indian rules.

Money movement. The Reserve Bank issued the Regulation of Payment Aggregators Directions, 2025 on 15 September 2025, consolidating the earlier payment aggregator rules. Non-bank aggregators must run a designated escrow account with a scheduled commercial bank, the day-end balance may not fall below the amount collected and still owed to merchants, and merchant due diligence follows the KYC Master Direction, with a lighter route for small merchants below a stated turnover threshold. In practice this means your platform does not hold customer money in its own current account. You integrate a licensed aggregator, and your payout ledger has to reconcile against their settlement files rather than your own optimism.

Tax. Two changes from October 2024 govern scrap. Metal scrap supplied by an unregistered person to a registered recipient came under reverse charge, and Notification No. 25/2024-Central Tax introduced a 2 percent TDS deduction by registered recipients on metal scrap supplies where the taxable value exceeds ₹2,50,000 per transaction, covering scrap under Chapters 72 to 81 of the Customs Tariff, effective 10 October 2024 (notification summary). Verify current thresholds with your CA before you hard-code anything, because these numbers move.

What this means for the software is concrete. You need self-invoicing for purchases from unregistered sellers, a transaction-level test for the TDS threshold rather than a monthly one, HSN mapping on every material category, and a document store that can produce the paperwork per pincode and per state. Retrofitting this after launch is a rewrite of the order and settlement models, which is the expensive kind.

DPDP, addresses and pickup photographs

A scrap platform holds home addresses, phone numbers, entry instructions and photographs taken inside people’s doorways. That is a meaningful personal data footprint. The Digital Personal Data Protection Rules were notified on 14 November 2025 with a phased compliance window of 18 months, requiring standalone plain-language consent notices, breach notification to affected individuals, and a response to access, correction and erasure requests within a maximum of 90 days.

Four things to build rather than promise. Scope the partner app so an agent sees a customer’s full address and phone only within the active job window, not forever. Set a retention schedule for pickup photographs and weight evidence and actually run the deletion job. Make erasure a real workflow that reaches order history, support tickets and analytics exports, not just the profile row. And log consent with a version, so you can prove what a user agreed to on the date they agreed to it.

A build order that works

If we were starting a comparable platform today, this is the sequence.

1. Pincode and serviceability model first. Before any screen. Groups, rate card versioning, on and off states, waitlist capture.
2. Admin panel second. Operations needs to configure a pincode before anyone can book in it. Teams that build the customer app first spend the next month adding admin screens under time pressure.
3. Partner app third. Supply is the constraint in every scrap market. A partner who cannot complete a job cleanly will stop accepting them.
4. Customer app fourth, limited to a pilot set of pincodes in one sorting district.
5. Reconciliation and payouts, including the reverse charge and TDS logic, before the second city.
6. Live commodity pricing only after the manual rate card is stable and operators trust it.
7. Auctions, badges and content modules last. They are retention features, and retention is not your problem in month three.

On the app layer itself, a shared cross-platform codebase for the customer app with a leaner partner app is usually the right trade for this category. We set out how we make that call in our comparison of Flutter, React Native and native builds.

Five things we would design differently

1. Model the partner’s day, not the customer’s order. Acceptance rates rise when jobs are grouped into routes rather than pushed one at a time.
2. Treat the weighing step as a payment step. It is where trust is won or lost, and it deserves the same engineering care as a checkout.
3. Store the reason for every rate change. Six months later, nobody remembers why a pincode group was repriced, and the audit trail is what settles partner disputes.
4. Keep the catalogue small at launch. Every extra material category multiplies the rate card, the HSN mapping and the training burden on collection agents.
5. Instrument unserved pincodes from day one. Demand you turned away is the cheapest expansion research available.

Planning a build like this

Recycling app development is less about the pickup flow than about the configuration model underneath it, the settlement rules around it and the compliance work nobody budgets for. If you are scoping a collection, recycling or circular economy platform for the Indian market, our mobile app development team in New Delhi can walk you through the architecture and give you a realistic scope and timeline. Send us the problem you are solving and we will tell you what we would build first.