LOOM
A two-sided sustainable fashion marketplace. From concept to live platform connecting customers with garment redesign designers in 21 weeks.
What We Delivered
The Situation
Every year, billions of garments are thrown away that could have been something else entirely. Not because people do not care. Not because the skills to transform them do not exist. But because there was no structured, trusted way to connect the person holding the old jacket with the person who could make it worth keeping.
LOOM is a government-backed sustainable fashion platform with a specific mission: give old garments a second life by connecting customers who want their clothes redesigned with skilled designers who can do it. The concept sounds elegant. A customer uploads a garment as a project. Designers review it, submit quotes. The customer selects one. Collaboration begins through controlled chat until the transformation is complete. Simple to describe. Genuinely complex to build.
-
No structured discovery channel
Customers who owned clothes worth redesigning had no way to find the right designer. The closest alternative was social media DMs and hoping someone responded.
-
No professional platform for designers
Skilled fashion designers had no dedicated platform for upcycling work. Their options were Etsy, Instagram, or word of mouth. None gave them a structured project pipeline or the professional recognition their craft deserved.
-
No structured brief system
Designers received vague messages instead of project briefs, making quoting inconsistent and time-consuming. The sound of a notification meant another hour spent deciphering what the customer actually wanted.
-
Trust gap on both sides
Customers needed to feel confident in designer quality. Designers needed to sense the platform would bring real work. Neither side would commit without the platform creating conditions for that trust to take hold.
-
Three-party complexity
The platform had three user types, not two: customers, designers, and the admin system managing disputes, verification, and quality. Building for two creates a marketplace that breaks the moment something goes wrong.
-
Circular dependency in design
The admin system could not be defined until customer and designer flows were finalised. But those flows depended on understanding what data the admin team needed. This knot had to be untied at the design stage.
The market existed in theory but functioned poorly in practice. Talent on one side, need on the other, and no reliable bridge between them.
The Approach
Phase 1
Product Strategy and UX Research
Before a single wireframe was drawn, Empyreal mapped the full journey for each user type. Not just the happy path. The edge cases. The moment a customer feels uneasy about a quote. The moment a designer senses a brief is unclear. The moment the admin team needs to step in.
Three-party journey mappingCustomer, designer, and admin journeys mapped simultaneously, revealing product decisions that had to be resolved at the design stage. How much information should a customer provide? Should designers see each other's quotes? What triggers the chat system? Each answered before code began.
Three-party design reviewsEmpyreal brought the LOOM team into conversations mapping customer flow, designer flow, and admin implications simultaneously. Slower at the start. It prevented the kind of rework that sounds like a small fix and feels like rebuilding the foundations.
With the product logic mapped across all three user types, the interface design had a foundation that would hold under the weight of real users.Phase 2
UI/UX Design in Figma
The design phase produced distinct interface experiences for each user type. Not just different screens. Different information architectures reflecting different goals.
Customer experience built around confidenceUpload a garment, describe the vision, receive structured quotes, choose a designer, follow progress. Every step designed to quiet the uncertainty that currently stops people before they start.
Designer experience built around professionalismA clean portfolio system. Structured briefs with enough information to quote accurately. A clear pipeline showing incoming, active, and completed work. When designers hear the platform described, they should feel it was built by someone who understands their day.
Admin dashboard as management toolFull visibility into users, designers, projects, and platform activity. The ability to act quickly when needed. Not an afterthought bolted onto the back of a marketplace.
The design system established the emotional register the product needed. Every technical decision that followed served that register.Phase 3
Flutter Mobile App Development
In a community-driven marketplace, the mobile experience is the product. There is no tolerance for a UI that feels like a compromise. Flutter delivered native performance on both iOS and Android from a single codebase. A designer who has a worse experience on Android than their iOS counterpart is a designer who notices. And designers talk to each other.
Cross-platform consistencyIdentical behaviour on both platforms. For a marketplace that depends on community trust, the consistency of the experience is not a nice-to-have.
Real-time chat via WebSocketThe chat was project-scoped, accessible only within an active project and after a designer was formally selected. A delayed message in a marketplace chat is not just a bad experience. It is a trust erosion event. Real-time was not a premium feature. It was a trust requirement.
Phase 4
Backend Architecture
Node.js for its event-driven architecture, handling the kind of concurrent activity a marketplace generates. When multiple designers review the same project and submit quotes simultaneously, the backend handles that gracefully. MongoDB provided the flexible document structure needed for a platform where projects, garments, quotes, and designer profiles all carry different shapes.
Scalable foundationBackend architecture that can grow with user numbers without requiring a rebuild at the next traffic threshold.
Firebase integrationAuthentication, storage, and the real-time data sync that keeps both parties informed without manual refresh.
The Numbers
LOOM launched as a complete, operational marketplace. Empyreal continues to manage it, which is itself a statement about the kind of relationship this project produced.
Mohit's Take
"The first question we asked was not 'how many screens do you need?' It was: 'which side of the marketplace do you need to win first, and what does winning look like for them?' That question reshaped the entire brief. The designer community needed to be built with enough care that they would actively recommend the platform to each other. A professional environment is self-reinforcing. Get that right, and the other side follows."
— Mohit Ramani, Founder & Lead Architect, Empyreal Infotech
Tech Stack
The toolchain behind the LOOM platform.
Start a Conversation About Your Product
You have a marketplace concept, or something close to one. You know who it connects. You can picture how it works when it works. What you might not have is a clear view of how to build both sides simultaneously.
A discovery call with Empyreal is thirty minutes. You explain your platform. Empyreal listens, asks the questions that reveal the structural decisions you have not made yet, and gives you an honest read on what it would take to build it correctly.