mmitech
Own-brand build Visit live site ↗

Last updated

Hero image for the Mendmyi case study

mendmyi - service and retail under one roof, on one backend

The founder’s own UK device-repair business: a single site that takes repair enquiries, sells refurbished phones and accessories, and tracks every order and every ticket against the same live data the counter sees on the in-shop tablet. Built by the studio as the dogfood case for everything else - the proof that one backend can carry both the service side and the retail side of a local business without the spreadsheet shadowing the live data.

Live: mendmyi.com


The brief

mendmyi is two businesses sharing a counter. One is service: customer walks in with a cracked iPhone screen, leaves a deposit, comes back at the end of the day. The other is retail: customer walks in for an iPad cable, browses the refurbished phones in the case, and leaves with a used Pixel and a screen protector. The website needed to do both without one swallowing the other. Most repair shops bolt a Shopify on the side and call it a website; the result is either a service page nobody can find behind a product grid, or a product catalogue buried under a “book a repair” hero that converts neither.

The constraint we built against was the one every multi-rail local business hits: every product price, every repair price, every availability check, every order, and every ticket had to read from the same source the in-shop tablet reads. No second source of truth. No spreadsheet shadowing the product catalogue. No “oh, the website’s saying it’s in stock but it isn’t” moment at the counter. One backend, two consumers - the in-shop view and the public storefront - both looking at the same row of the same table.

The mendmyi shopfront - repair counter on one side, refurbished devices in the glass case on the other

What it actually does

One site, two front doors. The shop and the service surface live under the same brand and the same navigation. Repair customers land on a clear “how much to fix” path with live pricing and turnaround windows by device and fault. Retail customers land on a clear “what’s in stock” path with search, filter, product detail, cart, and checkout. Neither swallows the other - the homepage gives each the space it needs.

Live pricing, live stock, live tickets - one backend. The product catalogue, the repair-service catalogue, and the per-ticket status are read live from the same workshop platform the counter uses. When a refurbished Pixel sells on the website, it disappears from the counter view in the same breath. When the counter staff books in a new ticket, the customer’s portal page is live before they get back to the car. The “do you have a Pixel 8 in stock” question has a real answer because the answer comes from the live data.

The per-ticket portal. Every repair customer gets a private link by SMS that opens a page showing the live status of their device - received, diagnosed, quoted, parts on order, ready for collection - with photos of the work, a one-tap approve / decline for the quote when it lands, and the “ready for collection” notification with shop opening hours. No account to make, no password to remember, no app to install. The “is my phone ready” phone call closes itself before it gets dialled.

The bookkeeping bridge - the part most multi-channel shops get wrong. A normal Tuesday at mendmyi has four revenue rails running side by side: D2C orders from the storefront, walk-in retail at the counter, marketplace listings (eBay refurb), and the service-side repair income. A daily-cadence reconciliation consolidates all four into the books, with per-channel revenue split, per-channel fee deduction, VAT on the right margin scheme, refunds matched, gift-card liability tracked, and every transaction tagged with its source so the year-end isn’t a forensic exercise. The bookkeeper opens the books in the morning and sees yesterday already done.

Structured intake, not a free-text form. The repair-enquiry form is built the way a counter conversation is built: device, model, fault description, photo upload of the existing condition, customer contact, preferred drop-off slot. The submission creates a draft ticket with a quote band already attached, the customer gets the portal link, and the counter staff see a new entry in the dashboard. The friction between “customer’s website enquiry” and “customer’s phone is on the bench” drops to one tap.

The counter view at mendmyi - staff with the in-shop tablet, customer dropping off a device

The outcome

The website carries the load that used to live in the counter conversation. On a normal week mendmyi processes its inbound repair enquiries, its refurbished retail orders, and its consumable accessories sales through a single backend, with the books reconciled daily and no spreadsheet shadowing the live data. The counter staff opens one tab; the customer opens one URL. The “let me just check” answer to “do you have one of these in stock” doesn’t get said any more - the answer is on screen.

It’s also where every other studio build gets used in production first. The workshop platform is RepairMinder; the inbound AI receptionist on the phone and the web chat is mendbuddy; the device-repair social cadence - before-and-after photos to Instagram and Facebook on a recurring schedule - runs on PlanPost. When we tell a new client “we’d build this for you”, the proof is that we built it for ourselves and it’s running on a real shop with real customers, every day. The split-website pattern (a Shopify on the side, a brochure on top, neither talking to the other) is what we explicitly avoided; the single-backend pattern is what we’d build for a new client in the same shape.

Tuesday morning at mendmyi - owner glancing at yesterday's reconciled books on a tablet

Which verticals this fits

The reference for any local service business that also sells parts, refurbished stock, or product accessories under the same brand:

Local service shops with a retail line

Producers with a customer-facing shop

Trades and retailers who carry a small product line

Which problems this solves

mendmyi is the live example for the solutions where one backend has to feed both a service surface and a retail surface:

Want a service-plus-retail site like mendmyi for your business?

Tell us what you sell, what you service, and where the spreadsheet currently shadows the live data. Tell us what the counter conversation sounds like when a customer asks “do you have one of these in stock” and the answer is currently “let me just check”. We’ll come back with a sketch of what we’d build, what would live behind the same backend, and what the books-reconciliation bridge would look like for your channel mix. No demo, no calendar widget - email reply, scoped sketch, you decide.

Tell us what's slowing the business down

Send an enquiry - what you do, what's slowing you down, what you've already tried. We'll come back with a sketch of what we'd build and what it would cost. No calendar, no demo to sit through.

No calendar widgets. Email reply, scoped sketch.

Tell us what's slowing the business down

Email reply, scoped sketch, you decide. No calendar widgets, no demo to sit through.

No calendar widgets. Email reply, scoped sketch.