CASE STUDY · RETAIL & E-COMMERCE
A three-sided alterations platform, production-ready in six weeks
A UAE founder came to us a year into a build, with nothing they could put in front of a user. The product had to serve three groups who each want something different — customers, tailors and retailers. Six weeks later it was in production and onboarding real people.
Dubai, UAE
Retail & e-commerce
Custom app
iPhone & Android, one shared codebase
Client stage
Founder with a stalled build
Twelve months into development elsewhere, with no version stable enough to onboard a real customer.
Engagement
Six-week MVP build
Planned as six weekly deliverables, from first strategy session to deployment.
6 weeks
Kickoff to a production-ready MVP
From the first strategy session to a stable build that could onboard real users.
12 months
Spent before, with nothing testable
Where the project stood when it reached us — core flows unfinished, no stable version.
3 user types
Customers, tailors and retailers, one platform
Three sets of flows and permissions that all have to agree with each other.
The client
A UAE founder building for the clothing alterations trade — not a fashion label, but the layer underneath one: the tailors and the retailers who handle the work after a garment is sold.
The idea was a single platform where a customer can book an alteration, a tailor can manage the work, and a retailer can offer the service under their own name. Three groups, one product, and a market that still runs largely on phone calls and paper tickets.
The situation
The brief was not complicated to describe. It was difficult to build, for three separate reasons.
Three users, one product
Customers want simplicity — book it, track it, know what it costs. Tailors want structure — a clear queue and a schedule they can manage. Retailers want something reliable enough to put their own brand on. Every one of those is a different set of screens, and a product that serves two of them well and the third badly does not work at all.
A year in, with nothing to test
The founder arrived after roughly twelve months of development elsewhere. Core flows were unfinished, the architecture had no clear shape, and there was no stable version that could be put in front of a real customer. The time was gone and the product still did not exist — which is the position that makes the next decision feel risky rather than exciting.
Production-ready, not a prototype
A clickable demo would not have helped. What was needed was something real users could be onboarded onto, that could take initial traffic and run its core flows without falling over — and it was needed in six weeks, not six months. That constraint shaped every decision that followed.
How we approached it
Six weeks is not a matter of working faster. It is a matter of deciding, before any code is written, what will not be in the first version — and then not revisiting that decision.
1
We spent the first stretch researching, not building
Before a line of code, we worked through what already existed: services that could handle the parts of the product that are not its own value, integrations that would remove development days rather than add them, and tools that would sit cleanly inside the main workflows rather than fighting them.
Anything a proven service already solved, we used. That left the development time for the part nobody else can supply — the way this particular three-sided product actually works.
2
We cut every feature back to its purpose
Complexity is the usual reason products arrive late. So each feature was put through the same three questions: does it directly serve what the MVP has to prove, can the flow be simpler than this, and is it needed for the first real customers?
Most things did not survive, and the product was better for it — a smaller surface, clearer flows, and screens a first-time user can read without being taught.
3
We built on our own delivery framework
The repetitive parts of a build — environment setup, standards, checks, deployment — run on a framework our team has refined across projects. It handles the work that would otherwise take the first week and produce nothing a user can see.
The six weeks were then planned as six weekly deliverables, so at no point was there a question about what to build next, or a week that ended without something finished.
What we built
Six weeks, planned as six deliverables.
WEEK 1
Strategy, research and architecture
Working through the founder's vision and what the MVP had to prove
Cleaning up the scope to a lean feature list
Mapping the user journeys for all three sides
Selecting the third-party systems
WEEKS 2–3
The core flows
User onboarding for each of the three roles
Customer to tailor — request, quote, accept
Tailor to retailer — the work that sits behind a retailer's own offer
Booking and alteration tracking end to end
WEEKS 4–5
Interface and functional testing
Layouts, buttons and navigation refined against the real flows
Page load behaviour
Error handling for the cases a real user will hit
WEEK 6
Testing and deployment
Quality assurance across all three roles
Real-device testing
Stability checks under initial load
Deployment and preparation for real user onboarding
"Production-ready": not a mockup, not an early alpha, not a half-built idea. A stable platform that could onboard real users, take initial traffic, run its core flows properly, and carry the next phase of work without being rewritten.
The research week is what bought the other five. Every function handed to a proven third-party service was a function we did not build, did not debug and do not maintain — which is how six weeks was possible without taking anything out of the quality.
Measurements by camera: a guided body scan, as an alternative to entering them by hand. The face is blurred.
The customer shows the fit they want in whichever way is easiest: photos of a pinned garment, a garment that already fits, or measurements.
The results
A production-ready MVP in six weeks
After twelve months elsewhere had produced no version that could be tested.
Real users could be onboarded
Not a demo account and not a staging link — the platform was ready to take actual customers.
All three sides running end to end
Customer, tailor and retailer flows working together rather than as three separate halves of an idea.
A foundation, not a throwaway
Built so the next phase extends it rather than replaces it — which is the difference between an MVP and a prototype.
Something to show investors
A working product in the room changes that conversation more than any deck does.
The founder owns the code
Code, IP and infrastructure, in full. No lock-in, and nothing that has to be negotiated later.
The app looks amazing. I appreciate your work and how quick you have done it. Looking forward to work on other part.
Founder, UAE alterations platform
If you’re building something similar
Very little of what made this project hard is specific to alterations. If any of these describe where you are, it is the same problem with different screens.
A build that stalled with someone else
Months in, no stable version, and a decision to make about whether to repair it or start properly.
A marketplace with more than two sides
Any product where a third role — an operator, an agent, a franchise, a clinic — sits between supply and demand.
A service business moving off phone calls and paper
Booking, quoting, tracking and handover, in a trade that has always run on messages.
A first version that has to be real
Something users can be put on and investors can open — on a date you have already committed to.
Questions people ask us
Before you build something like this
What does it cost to run once it's built?
Running cost comes from four places: hosting and database load, the third-party services the product depends on, app store and compliance overheads, and the pace at which you keep shipping. Leaning on proven third-party services for non-core functions — as we did here — lowers what you build and what you maintain. We size all four with you before the build rather than after it.
Can you take over a build another agency started?
Yes, and it is one of the most common reasons founders come to us. We start by working out what is worth keeping and what is faster to rebuild, then agree a scope you can see the end of. Here the fastest route was a clean build on a lean feature set rather than repairing an unfinished architecture.
How can an MVP be production-ready in six weeks?
Not by working faster. By deciding, before any code is written, what will not be in the first version — and by using proven third-party services for everything that is not the product's own value. The six weeks here were planned as six weekly deliverables, so at no point was there a question about what to build next.
What does "production-ready" actually mean?
It means real users can be onboarded onto it. Not a clickable mockup and not an early alpha — a stable build that handles initial traffic, runs its core flows end to end, and can carry the next phase of work without being rewritten.
What happens after launch?
An MVP is the start of the information, not the end of the project. Most clients continue on a monthly partnership where features ship on a fixed cycle, each sprint scoped and agreed before it starts, shaped by what real usage shows.
Building something similar?
Message us on WhatsApp — we'll tell you whether we're the right team for it, and what the first phase would need to cover.
More of our work
Other builds in this space
Case Study · Wellness & Healthtech
A GCC wellness marketplace, live on both stores in eight weeks
Case Study · Wellness & Healthtech
