The situation
Nisha Telecom has traded pre-owned flagships out of Prangan Market, near the Mohana bus terminus in Berhampore, for eleven years. Apple, Samsung, Vivo, Oppo, Motorola. Two outlets, six or seven staff, and a customer base that reaches well past the town: police officials and local administrators, businessmen driving in from Malda, Nadia and South 24 Parganas because the deal is worth the journey. The owner, Siraj Islam, came to us to put the shop online.
The specific problem was timing. Stock changed daily, and the shop announced it through videos on its Facebook page. Someone in Malda would watch a video, decide on a handset, and drive two hours to buy it. By the time they reached the counter the phone had often gone. In pre-owned trade there is no second unit: every device is one device. A customer who makes that journey twice does not make it a third time.
So the brief was a well-designed, mobile-first site where the day's stock could be checked before setting out, with staff updating it hourly from the shop floor.
One decision followed from who the customers are rather than from the brief. Promotional copy runs in the mix of Bengali and English that people in Berhampore actually speak and read, not in translated formal Bengali and not in English alone. A site for four districts of West Bengal should sound like the shop counter, and the shop counter does not speak in either language exclusively.
What we found
The stock problem was real and we built for it. But sitting with the counter for a while surfaced something the brief had not mentioned, and it turned out to be the larger opportunity.
Nisha Telecom also buys. Customers bring in an old handset and either exchange it against something from the shelf or take cash. The catch was that a valuation required a physical visit. Someone in Nadia wondering what their two-year-old flagship was worth had no way to find out except to drive to Berhampore and ask, which meant most of them never asked.
- The buying side of the business was invisible online, though it feeds the selling side directly: every trade-in becomes tomorrow's stock.
- Valuation was gated behind travel, filtering out everyone who was merely curious.
- The shop had no record of the people who considered selling and did not follow through, so there was nothing to call back.
What we built
The live catalogue
A mobile-first storefront listing every handset currently on the shelf, with condition, storage, colour and price. Staff update it from the floor as devices arrive and sell, so the site reflects the counter within the hour rather than within the day. A buyer in Malda now checks before starting the car.
The detail that does the real work is the unit count. Every listing shows how many are left, graded by condition, with a bar that turns from green to amber to red as stock falls away. Two units of an iPhone 17 Pro Max reads differently from six units of an iPhone 16 Pro, and it should: the whole problem was that customers could not tell the difference until they arrived. A card that says two units left is telling the truth about a two-hour drive.
Alongside it runs a live feed of what has just sold, by handset and by town. It is honest merchandising rather than manufactured urgency. In this trade the scarcity is real, and the site is simply reporting it.
Remote trade-in valuation
A seller picks the device type, brand, model and variant, states its age, and ticks off what they still have: bill, box, charger. Those boxes are not administrative. In pre-owned trade the accessories and the original bill move the price materially, and a valuation that ignores them is a valuation the shop has to walk back later.
The form then asks for the IMEI, verifiable by the seller on their own handset, and up to three photographs. The system returns an indicative valuation immediately, along with the better rate available if the seller exchanges against a pre-owned handset rather than taking cash. Staff review each submission and confirm or adjust the figure before anything is committed.
The valuation queue as a pipeline
Every submission is a person who owns a device and is thinking about parting with it. The system holds them as a working list, and staff call after the quote goes out. A page that was built to answer a question turned into the shop's most reliable source of incoming stock.
How it is put together
The storefront and the staff dashboard are one Next.js application, server-rendered, deployed on Vercel with CI/CD from the repository. The business logic sits behind it in a Laravel API on ordinary cPanel shared hosting.
Splitting it this way was a cost decision as much as an engineering one. The catalogue needed to be fast and indexable, because a buyer in Malda searching for a handset should find Nisha Telecom rather than a marketplace, and server-rendered pages behind a CDN do that. The API did not need any of it, so it runs on hosting the shop already pays for. The client gets the performance where it is visible and pays nothing extra where it is not.
| Frontend | Next.js 15, React 19, TypeScript, Tailwind CSS. React Context for state, Axios and Fetch for data. |
|---|---|
| Rendering | SSR, SSG and CSR applied per route. Code splitting, image optimisation, lazy loading and route-based optimisation. |
| Backend | PHP 8.2 and Laravel 11, exposing REST APIs consumed by the frontend. |
| Database | MySQL |
| Authentication | Laravel Sanctum, session-based across the staff dashboard and the customer portal. |
| File storage | Server-side, outside the public web root. Trade-in photographs are never publicly addressable. |
| Notifications | SMS through a client-provided DLT-registered gateway, email through client SMTP. |
| SEO | Structured metadata, sitemap and robots.txt, with server-rendered product pages. |
| Hosting | Frontend on Vercel with CDN-backed assets and CI/CD from Git. Laravel API on cPanel shared hosting, deployed by File Manager or FTP with Composer dependencies bundled, no SSH required. |
The hard part
We got the staff dashboard wrong, and it is worth saying plainly because the mistake was a failure of observation rather than of engineering.
We designed the customer-facing site mobile-first, correctly, and then designed the staff dashboard for a desktop screen. That is the conventional split and it was the wrong one here. Staff do not update stock at a desk. They update it standing at a counter with a customer in front of them and a phone in one hand, between transactions. On a desktop layout squeezed onto a handset, updating a listing took long enough that updates slipped, and a catalogue that slips is the exact problem we had been hired to solve.
We rebuilt the dashboard for mobile. Hourly updates only became realistic after that, which means the headline outcome of this project depended on a correction we should not have needed to make. The lesson we took, and now apply at the start of engagements, is to design for where the work physically happens rather than for who the user is.
Where it landed
The site found its audience immediately. Nisha Telecom already had eleven years of local reputation and an active Facebook following; the site gave that audience somewhere to go. We paired the launch with local SEO work and organic promotion through the shop's existing page, and the server-rendered product pages meant individual handsets were indexable rather than trapped behind a client-side render.
The trade-in flow changed the shape of the business rather than just its traffic. Valuations that previously required a journey now happen from a sofa in another district, and the shop has a standing list of people to call.
The measure that matters most to us sits on the staff side. Six or seven people with no technical background operate the platform daily, without training material and without calling us.
Managing a tech platform used to feel like a massive headache waiting to happen, but Team QueryLabs completely changed the game. The dashboard they created is so intuitive that my team was navigating it seamlessly right away, even without any tech or billing background.
They bridged the gap between complex tech and everyday usability for our staff and customers alike. We get compliments on the platform constantly, and every single time someone asks who built it, I proudly name QueryLabs. They brought real magic to our business, and this is only the beginning of our work together.
What's next
The valuation flow rests on an assumption worth naming. The IMEI field and the photographs are both proxies for a question the form cannot actually ask: is the person filling this in holding the device they are describing? An IMEI can be read off a listing. Photographs can be borrowed, and increasingly they can be generated. Today the assumption holds because staff call before anything is paid, and the call does the verifying. As volume grows, the call stops scaling before the submissions do.
That is the problem our lab works on. A valuation flow that can establish a person is present, with the device they are photographing, is the natural next layer here, and Nisha Telecom is the kind of deployment where it would earn its place rather than being bolted on.