Every used handset is one of a kind
Pre-owned stock has no clean model catalogue behind it. Condition, storage and colour vary unit by unit, and a generic product template flattens exactly the detail a buyer needs.
A phone shop that owns its storefront.
NextGen Mobile sells handsets in Rajshahi. Instead of renting a store on someone else's platform, we built them one: a custom storefront, a search engine written for their catalogue, cash-on-delivery checkout, and an order console. No subscription, no cut of every sale.
The build
One Worker. The whole shop.
Storefront, checkout and admin, built from scratch
The work
The work, up close.
15 pieces of the build, every one a real screen from the live site.
Storefront
A shop window that opens instantly
Every page is assembled in a Cloudflare Worker at the edge and sent as finished HTML. There is no client framework to download and parse before a customer sees a phone, which matters on the mobile connections most of this traffic arrives on.
Server rendered at the edge, no client framework
Real stock, front and centre
The inventory is the homepage
Pre-owned handsets are what the shop actually moves, so they get a row on the front page with price, colour options and a direct buy action. A customer can go from landing to a product page in 1 tap, without opening a menu.
Buy action on every card
Catalogue
8 categories, filtered without a reload
One catalogue page handles category filters, text queries and sorting by price or discount. Each combination is a real URL, so a filtered view can be shared in a message or linked from a Facebook post and still land correctly.
Every filter state is a shareable URL
Pre-owned
Where the business actually lives
25 pre-owned handsets, each with its own colour options and condition-appropriate pricing. Second-hand stock is the hardest thing to sell online because every unit is different, so each one gets a full product page rather than a line in a list.
25 handsets, each individually listed
Search
It finds the phone they meant, not the one they typed
This is a real query. The customer typed "ifone" and the overlay returned every iPhone in stock. The relevance engine was written for this catalogue: edit-distance typo tolerance, a synonym table covering the words Bangladeshi buyers actually use, and tokenization that handles Bengali script alongside English.
Typo tolerant, synonym aware, built for this shop
Results
Search results keep the filters
A query lands on the same catalogue surface as a category, so the customer keeps the filter chips and the sort control instead of being dropped into a stripped-down results list. Weighted scoring puts exact matches first and prefix matches next.
Search and browse share one interface
Product page
Enough detail to decide, nothing to wade through
Price, key specifications, colour choice, quantity, and 2 clear actions. Buy Now goes straight to checkout for a customer who has already decided; Add to cart is there for the one who has not. Structured data on every product page means the listing can surface correctly in search results.
Product schema on every listing
Variants
Colour is part of the order, not a note in the comments
Selecting a finish changes what goes into the cart, and the same handset in 2 colours becomes 2 separate lines. The shop packs exactly what was ordered instead of calling the customer back to ask, which is where cash-on-delivery orders usually go wrong.
Colour carried through cart, order and email
Cart drawer
Adding to the cart never costs you your place
The drawer slides in over the product page and the customer keeps browsing. Rapid taps are queued and applied in order, so a customer on a slow connection who taps twice does not end up with a cart that disagrees with itself.
Requests serialized to survive slow connections
Cart
A cart that survives the week
The cart lives in a signed cookie that lasts 14 days, with no account and no database write. Every key and quantity is revalidated against the real catalogue on each read, so a stale or tampered cookie can never produce an order the shop cannot fulfil.
14 day cart, revalidated on every read
Checkout
Built around cash on delivery, not adapted to it
Navigation is stripped out so there is one path forward. The phone field accepts Bengali numerals and the +880 and 880 prefixes, folding them all to the format the shop can actually dial. Choosing a delivery zone updates the total in place, with amounts grouped the Bangladeshi way.
Bengali numeral input, +880 normalization
Order tracking
The phone number is the account
Nobody registers, nobody sets a password, and nobody forgets one. A customer enters the number they ordered with and sees their orders, statuses and totals, timestamped in Dhaka time. It removes the single most common reason a customer calls the shop.
No accounts, no passwords, no signup step
Admin
A locked door in front of the order book
The console sits behind a token gate. Tokens are compared in constant time so the check cannot be probed by timing it, the session cookie is scoped to the admin path alone, and every order screen is excluded from search engines. This is the public side of that door.
Constant-time token check, admin-scoped session
Trust
The objection gets answered before it is raised
Buying a used phone from an unfamiliar website is an act of faith. Authenticity, delivery speed, paying on arrival and a human to call are stated plainly on the homepage, because for this category those 4 answers decide the sale long before the specifications do.
4 guarantees, stated on the front page
FAQ
The questions that stall an order, answered on the page
Delivery time, cash on delivery, authenticity, how to order and how to track it. Keeping them on the homepage rather than a policy page means a hesitant buyer resolves the doubt without leaving. The same content is marked up so search engines can read it as questions.
FAQ structured data, no extra page to visit
The client.
NextGen Mobile is a Rajshahi phone retailer built on buy, sell and exchange, trading brand new and pre-owned handsets with 100% genuine stock and cash on delivery anywhere in Bangladesh.
At a glance
The engagement, on paper.
- Client
- NextGen Mobile, a mobile phone retailer in Rajshahi, Bangladesh.
- Trade
- Brand new and pre-owned handsets, plus buy, sell and exchange in store.
- Scope
- Storefront, catalogue, search engine, cart, cash-on-delivery checkout, order tracking, admin console, and transactional email.
- Stack
- A single Cloudflare Worker rendering HTML at the edge. No framework and no runtime dependencies.
- Data
- Cloudflare D1. Orders are the only records stored, so a product view never touches the database.
- Search
- A custom relevance engine written for this catalogue, not a plugin.
- Ownership
- The shop owns the code, the orders and the customer data. No platform account sits in the middle.
The challenge
Used phones. Cash on delivery. A Facebook page for a shop window.
Selling handsets online in Bangladesh breaks most of the assumptions built into an off-the-shelf store.
Cash on delivery puts the risk on the shop
Nothing is paid until a courier is at the door. A wrong number or a vague address is not a support ticket, it is a handset that travelled across the country and came back.
Prices move faster than a catalogue
Handset pricing shifts week to week. Anything that makes a price change slow or awkward means the site is quietly wrong for days at a time.
Demand arrives from social, not search
Customers come from a Facebook page and word of mouth. They land expecting to see stock immediately, not to be introduced to a brand they already know.
Platform fees bite hardware margins
Phone retail runs on thin margins. A monthly subscription and a cut of every sale take a meaningful share of the profit on each handset sold.
Nobody types the official model name
Customers search in a mix of English and Bangla, shorten names, and misspell them. A search box that only matches exact strings returns nothing and loses the sale.
The goals
7 goals, in order.
Agreed before a line of code, and the order matters as much as the list.
01
Put the stock in front of them
A visitor arriving from Facebook should see real handsets and real prices in the first screen, with no brand introduction in the way.
02
Answer the trust question first
Authenticity, delivery and payment on arrival are the decision. State them on the homepage rather than burying them in a policy page.
03
Keep the path to an order short
From landing to a placed order in as few steps as possible, with no account, no password and no page that exists only to collect an email.
04
Match how people actually search
Handle misspellings, shortened names and mixed Bangla and English, because the alternative is an empty results page.
05
Make cash on delivery safe to run
Capture a dialable phone number and a real address at the point of order, so the shop can confirm before anything is dispatched.
06
Give the shop one place to work
Every order in one console, with a status that moves forward and tells the customer automatically when it does.
07
Keep the platform theirs
No subscription, no cut of each sale, and no third party holding the customer list. The shop owns what it paid for.
Our strategy
The decisions behind the build.
Why we built it this way, and what each choice was a trade against.
Render at the edge and keep the catalogue out of the database
The product list is compiled into the Worker itself, so browsing never queries anything. Only checkout, tracking and the admin touch storage. It removes the slowest part of a typical store and the most common thing to fall over under load.
Ship zero runtime dependencies
Nothing from the package ecosystem runs in production. That is a deliberate trade: we wrote more ourselves, and in exchange the shop has no plugin to update, no supply chain to audit, and nothing that breaks because a maintainer pushed a release.
Keep the cart in a cookie, not an account
Requiring registration to hold a cart loses buyers who were 1 tap from ordering. A signed cookie holds it for 14 days with no database write, and every read is revalidated against the live catalogue so it can never be trusted blindly.
Treat the phone number as the account
In a cash-on-delivery market the phone number is already the identity: it is how the shop confirms, how the courier calls, and what the customer remembers. Building accounts on top of that would add a password to forget and nothing else.
Write the search engine instead of installing one
Off-the-shelf search assumes customers type catalogue English. This one handles edit-distance typos, a synonym table of the words buyers here actually use, and Bengali script in the same query. It is more work, and it is the difference between results and an empty page.
Make the shop the owner, not the tenant
On a rented platform the storefront stops the month the billing does, and the customer list belongs to someone else. Building it as owned software means the code, the orders and the data stay with the business.
The commerce engine
What runs underneath.
The systems a customer never sees, and the reason the ones they do see behave.
Running the shop
How the shop manages it.
4 systems the owner works with, and exactly what each one covers.
01 · The admin console
- A private order console, reachable only with the shop's admin token
- Tokens compared in constant time, so the check cannot be probed by measuring it
- A session cookie scoped to the admin path alone and expiring after 7 days
- Every order, with customer, items, colour, total and current status on 1 screen
- Excluded from search engines and from the sitemap by default
02 · The order workflow
- 5 states covering the real life of an order: pending, confirmed, shipped, delivered, cancelled
- Status changes from a dropdown that saves on selection, no separate edit screen
- Orders arrive as pending so nothing dispatches before the shop phones to confirm
- Each line keeps the price it was ordered at, so a later price change never rewrites history
- Timestamps rendered in Dhaka time rather than server time
03 · Automated customer email
- 3 templates: an alert to the shop, a receipt to the customer, and a status update
- Itemised tables with product thumbnails, totals and a status badge, in HTML and plain text
- Moving an order to confirmed, shipped, delivered or cancelled emails the customer automatically
- Sent after the response, so a slow mail provider can never delay a checkout
- Keyed for idempotency and retried once on a transient failure, so no duplicate receipts
- A local preview harness renders every template and fails the build on a broken variable
04 · The content layer
- Products, categories and colour options held in 1 structured catalogue file
- Banners, promotions and FAQ copy separated out from page code
- Policy pages kept as their own content, editable without touching layout
- Adding a product means 1 entry: name, category, price, colours and specifications
- Sitemap, category pages and structured data all regenerate from that catalogue automatically
The comparison
Renting a store, or owning one.
What the same shop looks like on a subscription platform against the one we built.
Rented platformWhat we built
Running costA subscription every month, indefinitelyNo ecommerce platform subscription
Per saleA percentage of every orderThe full margin stays with the shop
Cash on deliveryAdded on through a pluginThe default the checkout was designed around
Phone numbersGeneric international validationBengali numerals and +880 folded to a dialable number
Delivery pricingBroad zones set by the platformRajshahi and nationwide, priced and timed separately
SearchWhatever the theme ships withA relevance engine written for this catalogue
Page weightA theme plus its plugin stack1 Worker, no client framework, no runtime dependencies
Customer dataHeld inside a platform accountIn the shop's own database
TrackingThird-party pixels by defaultNo third-party trackers at all
OwnershipAccess ends when billing stopsThe code and the data belong to the business
What was built
The platform, by the numbers.
These describe the scope of what was delivered. They are counts from the build, not traffic or revenue figures.
47Crawlable pages
25Handsets listed
0Runtime dependencies
0Third-party trackers
Business impact
What owning it changes.
These describe how the build changes the way the business runs. They are not separately measured outcomes.
The margin stays in the shop
No monthly platform fee and no percentage of each sale, which on thin hardware margins is the difference between a channel that pays and one that does not.
Orders confirm themselves
Every status change emails the customer without anyone remembering to. The shop moves a dropdown and the communication has already happened.
Fewer calls asking where it is
Customers check their own order with the number they ordered on, which removes the most common reason the shop phone rings.
Searches end in a product, not a blank page
A misspelled model name still returns the right handset, so demand that arrives with imperfect spelling still reaches something buyable.
Nothing follows the customer
No advertising pixels and no third-party analytics, so the site carries no tracking baggage and needs no consent banner in front of the stock.
The platform is an asset
The code, the orders and the customer list are the shop's property. Nothing switches off because an invoice went unpaid.
Questions
The short version.
What did Rizer build for NextGen Mobile?
A complete commerce platform, not a theme on top of an existing one:
- Storefront: homepage, catalogue with filters and sorting, 8 category views, and a product page for every handset.
- Search: a custom relevance engine with typo tolerance, a synonym table, and Bengali and English tokenization.
- Buying: a slide-in cart drawer, a signed 14 day cart cookie, and a cash-on-delivery checkout built for Bangladeshi phone numbers and delivery zones.
- After the order: phone-number order tracking, and 3 transactional email templates covering the shop alert, the customer receipt, and status updates.
- Operations: a token-gated admin console with a 5 state order workflow.
Why not just use Shopify or WooCommerce?
They are good products. They are a poor fit for this particular shop:
- The cost lands in the wrong place: a monthly fee plus a cut of each sale is painful against handset margins.
- Cash on delivery is an afterthought: both are designed around card payment, with COD added through a plugin rather than assumed.
- The local details are wrong by default: Bengali numeral input, +880 handling, Bangladeshi digit grouping and Rajshahi delivery zones all need working around.
- Search cannot be fixed: platform search matches strings, and this catalogue needed a relevance model of its own.
- The honest trade: a custom platform costs more to build and needs a developer to add a product. In exchange there is no rent, no transaction cut, and no landlord.
How does cash on delivery work on the site?
Nothing is charged online. The site's job is to capture an order the shop can safely dispatch against:
- A dialable number: Bengali numerals and the +880 and 880 prefixes are folded into a single valid Bangladeshi mobile format before the order is accepted.
- A real address: name, address and delivery area are validated at checkout, and errors come back with every field still filled in.
- A zone and a timeframe: Rajshahi and the rest of the country are priced separately, each with its own stated arrival window, and the total updates as the customer chooses.
- Confirmation before dispatch: orders arrive as pending, and the shop phones to confirm before anything is sent.
How does the shop manage orders day to day?
Through a private console, in a single screen:
- Getting in: an admin token, compared in constant time, with a session scoped to the admin path and expiring after 7 days.
- The order book: every order with customer, items, colour, total and status listed together.
- Moving an order on: 5 states from pending to delivered or cancelled, changed from a dropdown that saves on selection.
- The customer is told automatically: confirmed, shipped, delivered and cancelled each send a branded email without anyone writing one.
- Adding stock: products are held in a structured catalogue and published by us, so a new handset is a request to Rizer rather than a form in the console.
Can Rizer build this for my shop?
Yes, and this is the model we would recommend for most product businesses selling locally:
- Best fit: shops with real margin pressure, a cash-on-delivery or local-payment market, and enough order volume that platform fees are noticeable.
- What you get: the storefront, the checkout, the order system and the admin, built around how your market actually buys.
- What you own: the code, the orders and the customer data, on infrastructure in your own name.
- What to weigh: a custom platform is a larger upfront build than installing a theme, and it pays back through fees you stop paying.
- Next step: book a free call and tell us what you sell.
Keep exploring
View all
More case studies.
Your turn
Paying rent on your own storefront? You do not have to.
If platform fees and transaction cuts are eating the margin on every sale, a platform you own pays for itself and then keeps paying.