Designerex was founded in Sydney by Kirsten Kore and Costa Koulis to solve a problem most wardrobes already have: expensive occasion dresses that get worn once. The platform lets an owner list a dress and lets someone else rent it, which makes it a genuine two-sided marketplace rather than a shop. Demand was never the constraint. The platform had been built by an offshore team, and as the marketplace grew the distance began to cost more than it saved. Requirements lost detail in translation, release cycles stretched across time zones, and technical debt accumulated in a codebase nobody in the business could read.
An onshore rescue and replatform of a peer-to-peer designer dress-sharing marketplace, without taking a live marketplace offline.
From offshore drift to onshore control
Designerex is a peer-to-peer marketplace where women rent designer dresses directly from other women. PixelForce took the platform over from an offshore team, brought development onshore and replatformed it while the marketplace kept trading. After our onshore rescue and replatform, Designerex grew 650 percent since the pandemic and became the number one designer dress-sharing platform, with $40M+ in retail value listed.
Growth since the pandemic 650%
Retail value listed $40M+
Market position No. 1
The Problem
The Solution
PixelForce took the platform onshore. The engagement began with an audit of the existing codebase to work out what was sound, what had to be rebuilt and where the business logic actually lived, because on a rental marketplace that logic is the product: availability across rental periods, lender payouts, deposits and returns. From there we ran a staged modernisation rather than a rewrite, moving the platform onto a scalable architecture component by component so that discovery, booking and payouts could be improved independently while the marketplace stayed open.
The Outcome
After our onshore rescue and replatform, Designerex grew 650 percent since the pandemic and became the number one designer dress-sharing platform, with $40M+ in retail value listed. Development knowledge moved from an offshore contractor into a team the business could brief directly.
A marketplace outgrowing the way it was built
Designerex is a peer-to-peer designer dress-sharing platform founded in Sydney by Kirsten Kore and Costa Koulis. Members list designer dresses they already own, other members rent them for an occasion, and the platform handles discovery, identity verification, payment and the payout back to the lender. Supply and demand are both members of the public, and neither side turns up unless the other one is already there. That makes trust the product. A renter has to believe the dress will arrive, fit and be as described. A lender has to believe an expensive dress will come back and that the money will actually land.
By the time PixelForce was engaged, the commercial question had been answered and the engineering question had not. An offshore arrangement that had been reasonable for a small marketplace had become the limiting factor for a large one. Requests from both sides queued behind release cycles the business did not control, performance degraded during the browsing peaks that matter most on a rental platform, and accumulated debt made each change slower than the last. Designerex needed the platform brought onshore and modernised without a day of downtime, because on a marketplace an outage does not only cost bookings - it costs the confidence that brings both sides back.
A live marketplace, no maintenance window
Thousands of active users, dresses already out on rental and payouts already scheduled. The transition had to happen underneath a trading platform rather than during a pause in it.
Knowledge locked in an offshore codebase
The hardest logic on the platform, covering availability across rental periods, deposits, returns and lender payouts, existed only in code written by a team that was being transitioned out.
Two sides to keep happy at once
Every change served either a renter or a lender, and often traded one against the other. Deciding which side each shared behaviour served first was a scoping problem before it was a coding problem.
Peaks the platform had to absorb
Wedding season and formal season concentrate browsing and booking into short windows. Search across a large dress inventory had to stay fast exactly when the most people were using it.
Designerex operates from Sydney and PixelForce works from Adelaide, so the engagement was built to work without a shared office and without the time-zone gap that had caused the original problem. Being close to the same clock changed the texture of the work more than any single technical decision: a question about how deposits should behave was answered the same morning rather than the next release. Requirements were settled in focused workshops and written down before development started.
Hinney Lo Founder & CEO, PixelForce
Book a consultationTaking over someone else's platform is mostly an archaeology problem. The code tells you what the system does, but it does not tell you which behaviours are deliberate and which are accidents nobody has noticed yet. Scoping is where you separate the two. Skip it and you faithfully rebuild the bugs.
Swipe to explore
Rescue by transition, not by rewrite
Scoping and design always precedes development at PixelForce, and on a rescue that discipline does more work than usual. Phase 1 Scoping and Design started with a technical audit of the offshore platform, and its real output was documentation: the workflows, the edge cases and the business rules written down in a form the client owned. A rental marketplace is full of rules that only appear under load, such as what happens when a dress is returned late and the next booking has already been accepted. Recovering those rules on paper before touching the code is what allowed the transition to happen without a rewrite, and it is what turned an offshore dependency into a Business Requirements Document, a Product Requirements Document and a fixed-cost Statement of Work.
The replatform then ran component by component rather than as a single cutover. Discovery, booking, payments and notifications were separated so each could be modernised and scaled on its own, which is what made it possible to improve the platform while it was still trading. Search and filtering received the most attention, because on a rental marketplace discovery is the conversion step: a renter is looking for a specific size, in a specific style, available on a specific weekend, near enough to receive it in time. Caching the data that is read constantly and indexing for the queries members actually run is unglamorous work with a direct commercial effect, since a slow result set on a Thursday night in formal season is a booking that does not happen.
Trust mechanics were treated as product features rather than policy. Identity verification, the booking and return lifecycle, and payment and payout handling were rebuilt as first-class parts of the platform, so a lender can see where a dress is and when the money arrives. Every release moved through structured quality assurance before it reached members, which on a live marketplace is not a formality. The platform is delivered as a mobile-first web experience rather than a native app, so the whole marketplace is reachable from a shared link without an install standing between a member and a dress they have already decided they want.
List · Rent · Return
A wardrobe that earns instead of sitting still
A marketplace rebuilt underneath itself, without closing for the work.
- Search and discovery
- Availability and the rental lifecycle
- Identity verification
- Payments and lender payouts
- Component-by-component replatform
- Mobile-first web, not an app store
01 06
Search and discovery
A renter arrives with a fixed brief: a size, a style, a budget and a date that cannot move. Search and filtering were rebuilt around that reality, with availability treated as a first-class filter rather than something discovered at checkout. Indexing and caching were tuned for the queries members actually run, so results stay fast during the peaks around formal and wedding season.
02 06
Availability and the rental lifecycle
A dress is not simply in stock or out of stock. It is booked for a weekend, in transit, being returned, or being cleaned before the next booking. The platform models that full lifecycle so a listing shows what is genuinely available on the dates a renter needs, which is what prevents the double bookings that damage trust on both sides of a marketplace.
03 06
Identity verification
Lending an expensive dress to a stranger only works if the stranger is verified. Identity checking is built into joining and listing rather than bolted on afterwards, so the trust step happens before the transaction rather than after a dispute. On a peer-to-peer marketplace this is not compliance overhead - it is the reason supply exists at all.
04 06
Payments and lender payouts
Money moves in two directions on every rental: in from the renter, out to the lender. Payment handling, deposits and payout calculation were rebuilt as core platform functions with a visible status for the lender, because the single fastest way to lose supply on a marketplace is for a payout to be late and unexplained.
05 06
Component-by-component replatform
Discovery, booking, payments and notifications were separated so each could be modernised and scaled independently. That structure is what allowed the platform to be rebuilt while it was still trading, and it means a browsing peak in formal season can be absorbed where it lands rather than by over-provisioning the entire system.
06 06
Mobile-first web, not an app store
Designerex is delivered as a mobile-first web platform rather than a native app. A dress is usually found because someone sent a link, and a link that opens straight into the listing converts far better than one that asks for an install first.
Services on the Designerex build
Frequently Asked Questions
Designerex is a peer-to-peer designer dress-sharing platform founded in Sydney by Kirsten Kore and Costa Koulis. Members list dresses they own, other members rent them for an occasion, and the platform handles discovery, identity verification, payment and the lender payout. PixelForce brought the platform onshore from an offshore development team and replatformed it. After our onshore rescue and replatform, Designerex grew 650 percent since the pandemic and became the number one designer dress-sharing platform, with $40M+ in retail value listed.
PixelForce audited the existing offshore-built platform, documented the business logic behind it, then ran a staged replatform onto a modern, scalable architecture. Discovery, booking, payments and notifications were separated so each could be improved and scaled independently, and search and availability, identity verification and the payment and lender payout flow were rebuilt as core platform functions. The work was done while the marketplace continued to trade.
By transitioning rather than rewriting. The first step is a technical audit that recovers the business rules out of the existing code and into documentation the client owns, because the hardest logic on a marketplace only appears under load. The replatform then runs component by component instead of as a single cutover, so each part is modernised and released on its own while the rest keeps serving users. A rewrite forces a switchover date; a staged transition never needs one.
By treating trust as product features rather than a policy page. On a dress-rental marketplace that means identity verification built into joining and listing, availability modelled across the full rental lifecycle so bookings cannot collide, and payment, deposit and payout handling with a status the lender can see. Supply is the scarce side, so anything that makes a lender doubt the dress or the money will come back removes inventory faster than marketing can replace it.
Longer than a new build of the same feature set, because the first job is understanding a system somebody else wrote. PixelForce runs a free consultation, then Phase 1 Scoping and Design, which on a rescue includes a technical audit and produces a Business Requirements Document, UX/UI design, a Product Requirements Document and a fixed-cost Statement of Work, then Phase 2 Development, QA and Release, then Phase 3 Post Launch Support. The timeline is fixed at the end of Phase 1, once the existing platform is actually understood.
Scoping and development are priced separately. At PixelForce, Phase 1 Scoping and Design runs $35,000 to $65,000, and Phase 2 Development, QA and Release typically ranges from $100,000 to $350,000. A rescue usually carries more scoping than a greenfield build, because the audit and documentation of the existing system happen in Phase 1. The figure is fixed in a Statement of Work before development starts.
Not necessarily. Designerex is delivered as a mobile-first web platform rather than a native iOS or Android app. Rental discovery is overwhelmingly link-driven, so a listing that opens directly in a browser removes the install step between someone seeing a dress and booking it. A native app earns its place when a product depends on repeat daily use, offline behaviour or device features. For an occasion-led marketplace, reach usually matters more than installation.
Up next
More products we have designed, built and launched end to end.
Traininpink Onboarding The first five minutes
Rebuilding the first five minutes of a Pilates app, using the funnel data rather than an opinion.
Wave Ki Land training for better surfing
How we turned Brad Gerlach's surf training method into a subscription platform that releases it in the order he teaches it.