Revea is a production headless-commerce system designed by Softech for a premium brand selling single, one-of-a-kind pieces. Instead of treating every product as repeatable stock, the architecture includes an explicit lifecycle for availability, reservation, locking, checkout and sale finalization. Next.js handles the storefront and experience layer, Medusa provides the commerce model, while payment, fulfillment and communication integrations remain independent modules. The case study shows how composable commerce can support a demanding inventory model without attributing undocumented percentage conversion gains or cost savings to the implementation.
Business context and the situation before implementation
In premium resale and one-of-a-kind inventory, the product layer is simultaneously a catalogue, brand content and a single sale opportunity. The same piece cannot be promised to two customers, and its state needs to remain consistent across storefront, checkout and the commerce backend.
- Each piece can have singular availability rather than repeatable stock.
- Collections and storytelling are part of the sales experience rather than an add-on to the catalogue.
- Product reservation needs to reduce the risk of two customers finalizing the same item.
- Payment, order and fulfillment need to complete the lifecycle of a specific piece.
- The architecture needs to let experience and commerce logic evolve independently.
Before state
Turnkey SaaS platforms can launch a typical store quickly, but their default product, variant, checkout and extension models are designed for a broad market. Revea needed more control over one-of-a-kind inventory and premium experience than a model based only on a ready-made theme and marketplace apps would provide.
- A default stock model does not describe a single non-repeatable piece well.
- Locks and reservations require consistency between storefront and backend.
- Premium UX changes should not depend on the constraints of a ready-made theme.
- Checkout and integrations need room for further extension.
- A sold piece should quickly stop appearing as actively available inventory.
Goals, success criteria and constraints
Discovery focused not on selecting a ready-made theme but on the domain model: when an item is available, when it becomes reserved, what a lock means, when an order takes responsibility for the item, and how to separate storefront, commerce and integrations.
Product goals
- Design a domain model for one-of-a-kind products.
- Separate the experience layer from the commerce backend.
- Reduce overselling risk for a single unique piece.
- Build a checkout ready for payment and delivery integrations.
- Keep full control over collections, content and PDP.
- Enable new modules without rebuilding the entire storefront.
Success criteria
- The state of a unique product is explicit through key purchase stages.
- The storefront can evolve independently from commerce core.
- Concurrent attempts to buy the same item follow a controlled path.
- Payment finalization leads to consistent order and availability updates.
- Delivery and communication integrations are not embedded in presentation logic.
- New collections and content modules can evolve without changing the order model.
Single unique piece
Availability can be exactly one, so a synchronization error has direct business impact: the same product cannot be successfully sold twice.
Checkout consistency
Cart, lock, payment and order are one process and need to handle interruption or failed finalization without leaving the item in an ambiguous state.
Premium experience
The brand, collection and content layer needs more freedom than a typical template-based product catalogue.
External integrations
Payments, fulfillment, carriers and communication have their own failure and latency states, so they cannot be treated as always-available synchronous dependencies.
Analysis and product decisions
- We mapped the lifecycle of a single unique item.
- We separated presentation state from commerce state.
- We defined reservation, locking and release points.
- We established responsibility boundaries for checkout and payment.
- We designed fulfillment and communication integrations as separate modules.
- We treated SEO and storefront speed as part of the experience architecture.
Solution architecture
Revea uses a layered headless architecture: Next.js renders the customer experience, Medusa provides commerce core, PostgreSQL stores persistent state, Redis supports fast-changing processes, and payments, fulfillment and communication remain separate integrations.
- 0101
Next.js storefront
Collections, storytelling, PDP, cart and checkout form an independent experience layer.
- 0202
Medusa commerce core
Products, orders and commerce extensions are maintained outside storefront presentation.
- 0303
Inventory and locking
Dedicated logic controls availability, reservation and finalization of a single unique piece.
- 0404
Data layer
PostgreSQL stores persistent state while Redis can support temporary locks and fast-changing context.
- 0505
Payments
Payment integrations are separated from the storefront and communicate finalization results to the order flow.
- 0606
Fulfillment and communication
Delivery, fulfillment and email/SMS are handled as replaceable integrations around a stable order model.
Problems, decisions and implemented capabilities
Several customers can be interested in the same unique piece at the same time.
Introduce explicit reservation and locking state.
Cart and checkout can temporarily protect a single product from competing finalization.
The system reduces overselling risk for one-of-a-kind inventory.
Premium storytelling should not be constrained by a ready-made theme.
Separate the storefront from the commerce backend.
Next.js can evolve collections, PDP and content independently from Medusa.
The brand layer can change without rewriting the order model.
Payment and product availability can diverge when finalization fails.
Treat checkout, payment and product-state update as a controlled lifecycle.
The system has explicit states before and after payment confirmation.
Order and item state can remain consistent even when the process is interrupted.
Delivery and communication integrations evolve independently from the storefront.
Place them behind modular integration contracts.
Fulfillment, carriers and communication can evolve as separate components.
Changing a provider does not require redesigning the entire purchase experience.
A turnkey SaaS can tie product logic to the platform vendor's roadmap.
Build a custom composable stack on an extensible commerce backend.
Softech can build custom modules and integrations without depending on an app marketplace.
The product roadmap remains under the implementation owner's control.
A sold unique piece should not continue to behave like active stock.
Connect order finalization with product availability state.
After sale, the product moves to an unavailable state rather than returning to standard stock.
The catalogue reflects the singular nature of inventory.
Technology decisions
| Technology | Role | Rationale | Trade-off |
|---|---|---|---|
| Next.js | Storefront, rendering and experience layer | Supports custom collections, PDP and checkout in React while retaining control over rendering and SEO. | Greater freedom means owning components, caching and integration with commerce APIs. |
| Medusa | Headless commerce core | Provides an extensible product, order and workflow model without imposing a single storefront. | Custom one-of-a-kind logic requires deliberate backend extensions rather than point-and-click SaaS configuration. |
| PostgreSQL | Persistent commerce state | A relational model suits consistent relationships between products, orders, payments and fulfillment. | Short-lived state or locking needs a separate strategy rather than overloading the persistent model. |
| Redis | Cache and short-lived state | Fits data requiring fast TTL, caching or temporary coordination around availability. | Redis cannot be the only source of truth for persistent order or sale state. |
| TypeScript / Node.js | Contracts and backend extensions | A shared type language simplifies integration between storefront, commerce backend and extension modules. | Contracts need maintenance as integrations and domain extensions evolve. |
| Vercel / AWS / Docker | Deployment and infrastructure | Allows storefront needs to be separated from backend services and deployment environments to evolve independently. | A composable stack requires observing multiple layers rather than relying on one closed SaaS control panel. |
Integrations and data flows
Stripe / PayU / Przelewy24 / BLIK
Checkout ↔ providerHandle payment and finalization of the financial part of an order.
Payment confirmation needs to be treated as integration state rather than only a client-interface result.
InPost / DPD / Furgonetka
Order → deliveryPass the data needed for delivery and order fulfillment.
Carrier failure or delay must not change the item sale state and requires separate operational handling.
SendGrid / Resend / Twilio
System → customerCommunication about the order, payment and subsequent service stages.
A notification is a communication channel rather than the source of truth for order status.
Commerce API
Storefront ↔ MedusaSynchronize products, availability, cart, checkout and orders between experience and commerce core.
The client layer needs to distinguish an API failure from a valid unavailable-product state.
AI, security and reliability
Inventory consistency
A unique item's status needs a persistent source of truth in commerce, while cache and locks must not independently define final sale state.
Idempotent finalization
Repeated payment callbacks or retries should not create duplicate orders or sell the same item again.
Integration isolation
Communication, fulfillment or carrier failure should remain a separate operational issue rather than corrupt core commerce state.
Controlled caching
The fast storefront layer needs to respect availability changes so a sold item does not remain purchasable because of stale cache.
Backend validation
Critical availability cannot depend only on UI; the backend re-checks process conditions at finalization points.
Implementation, testing and release
- 101 · Discovery
Define one-of-a-kind commerce as a domain model
- Product lifecycle
- Reservation and locking points
- Storefront / commerce / integration boundaries
Result: A process model was established that distinguishes a unique piece from typical repeatable stock.
- 202 · Headless foundation
Separate experience and commerce core
- Next.js storefront
- Medusa backend
- API contracts and persistent data model
Result: Brand experience and commerce can evolve independently while keeping explicit contracts.
- 303 · Unique inventory
Protect a single piece through the purchase flow
- Availability model
- Reservation and lock
- Release and sold-state handling
Result: Cart and checkout gained logic tailored to an item that cannot be sold twice.
- 404 · Checkout and fulfillment
Connect payment, order, delivery and communication
- Payment integrations
- Delivery / fulfillment
- Notifications and order finalization
Result: A completed purchase follows a consistent lifecycle from reservation to order fulfillment handoff.
- 505 · Optimization
Evolve experience, SEO and modules without destabilizing commerce core
- Rendering and cache optimization
- Collection and content evolution
- Integration monitoring
Result: Further changes can target specific layers rather than requiring a rebuild of the entire system.
Concurrent purchase tests
Test scenarios need to cover two customers attempting checkout for the same piece and correct lock release after an interrupted process.
Payment callback tests
Retry, delayed callback and repeated payment-provider responses should not create inconsistent orders or item states.
Checkout and integration tests
Checkout is tested together with payment methods, delivery and external dependency failure handling.
Storefront validation
Collections, PDP, routing and caching are checked for accurate current availability and performance.
Observable release
After release, checkout logs, integration failures and reconstructable order state matter without relying only on the customer interface.
What confirms the project description
Public materials confirm product scope, architecture and working screens but do not include a complete methodology that would allow previous percentage claims about conversion or development cost to be attributed to the implementation. P1-H therefore keeps those figures unpublished until a baseline, measurement period and source are available.
| Scope | Basis | Reference | Confirmation | Interpretation boundary |
|---|---|---|---|---|
| Revea has a custom storefront presenting unique products and premium content. | Real product screen | RV-01 · PDP / product screen | Confirmed | The screen confirms the product layer but does not prove conversion uplift. |
| Collections and storytelling form an independent storefront experience layer. | Real product screen | RV-02 · homepage / collections | Confirmed | The material shows the interface, not the full CMS or editorial workflow. |
| Revea has a dedicated checkout connected to payment and delivery. | Real product screen | RV-03 · checkout screen | Confirmed | The screen does not prove availability of every integration in every environment or method. |
| The architecture separates storefront, commerce core, data and integrations. | Architecture diagram based on project scope | RV-04 · composable architecture | Confirmed in the product | The diagram is a logical public description and does not disclose complete production infrastructure. |
| The product model includes availability, reservation, lock and sold state for a single piece. | Lifecycle diagram | RV-05 · unique-item lifecycle | Confirmed in the product | The diagram describes the domain model rather than every timeout configuration. |
| Checkout passes the finalized order through payment, fulfillment and communication. | Process diagram | RV-06 · checkout and fulfillment | Confirmed in the product | Individual integrations can have their own conditions and configuration-dependent availability. |
| Locking reduces competing finalization of the same unique piece. | Concurrency diagram | RV-07 · locking and concurrency | Confirmed in the product | The mechanism reduces overselling risk but is not presented as a formal proof that errors are mathematically impossible. |
| Headless architecture allows experience, commerce and integrations to evolve as separate layers. | Architecture evolution diagram | RV-08 · headless evolution | Confirmed in the product | Modularity reduces coupling but still requires maintained contracts between layers. |
How to read this information
- Product screens confirm implemented functions, not revenue impact.
- Avoiding a closed SaaS subscription does not mean infrastructure or external services have zero cost.
- Integration lists describe project scope, while availability of a specific method can depend on configuration and market.
- Conversion uplift requires comparable before-and-after data.
- Development-cost comparisons require equivalent feature scope and maintenance periods.
Process change, decision consequences and lessons
| Area | Before | After | Business impact |
|---|---|---|---|
| Product model | Typical repeatable stock and variants. | Explicit one-of-a-kind inventory lifecycle. | The system better reflects the real sale of unique pieces. |
| Storefront | Experience layer tied to constraints of a ready-made solution. | Independent Next.js storefront. | Collections, content and PDP can evolve without changing commerce core. |
| Concurrent purchase | No model designed specifically for a single unique item. | Reservation and locking in cart and checkout. | Lower risk of conflicting finalization attempts for the same item. |
| Integrations | Extensions dependent on one platform ecosystem. | Modular payments, fulfillment and communication. | A specific integration can change without rebuilding the storefront. |
| Roadmap | Evolution constrained by what a turnkey platform and its marketplace provide. | Custom stack and extensible commerce backend. | Product priorities can follow brand needs rather than only a vendor roadmap. |
| Sold item | Risk of treating a unique item like ordinary stock. | Finalization changes its availability to unavailable. | The catalogue stays aligned with the singular nature of inventory. |
Headless instead of turnkey SaaS storefront
- Alternative
- Shopify, Shoper, IdoSell or a similar closed platform
- Trade-off
- More ownership of development and operations in exchange for greater control over the product model.
- Rationale
- One-of-a-kind inventory and premium experience mattered more than minimizing custom development.
Dedicated locking
- Alternative
- Rely only on standard stock decrement
- Trade-off
- Additional state and retries require concurrency testing and lock-release handling.
- Rationale
- A single unique item needs protection before final stock decrement.
Modular integrations
- Alternative
- Embed providers directly in UI and checkout logic
- Trade-off
- Explicit adapters and contracts are needed, but provider changes have a smaller blast radius.
- Rationale
- Payments, shipping and communication have independent lifecycles and can change.
Custom Next.js storefront
- Alternative
- Ready-made commerce platform theme
- Trade-off
- More component and QA work in exchange for full control over experience and rendering.
- Rationale
- Premium presentation and editorial commerce were part of the product, not only decoration.
Key lessons learned
- One-of-a-kind inventory should be modeled as a domain rather than an exception added to standard stock.
- Locking is effective only when TTL, release and final source of truth are explicitly defined.
- Headless creates real value when layer separation follows product needs rather than technology fashion.
- Checkout needs to treat payment as an asynchronous integration with retries and repeated callbacks.
- Stale cache for a unique item is a business problem, not only a technical issue.
- Avoiding a platform subscription does not mean zero cost; a custom stack shifts some cost to development, hosting and maintenance.
Which organisations this model is relevant for
Premium resale and vintage
Brands selling single pieces that cannot be treated like repeatable stock.
Luxury and curated commerce
Stores where storytelling, collections and distinctive product presentation are part of the sales model.
Marketplaces with singular inventory
Platforms where a specific listing or item can be successfully sold only once.
Companies outgrowing turnkey SaaS
Teams needing custom commerce logic, integrations or experience that are difficult to maintain inside a closed ecosystem.
Related expertise and services
eCommerce development
Design and development of commerce stores and platforms with custom logic and integrations.
Web app development
Web systems, backends and workflows for custom digital products.
Next.js
React storefronts and applications with control over rendering, performance and SEO.
Node.js
Backends, integrations and domain logic for commerce systems.
KILOGRAM — marketplace and AI
A different commerce model combining marketplace BUY/SELL, mobile and a controlled AI layer.
Zamów Pellet — custom ecommerce
Custom online commerce for a different product, logistics and customer model.
Building commerce around a non-standard product model?
We can design a custom storefront, commerce core, availability, checkout and integrations when a turnkey platform constrains product logic or brand experience.
Key confirmed facts
The following statements summarise the confirmed product scope and contain no unapproved growth data.
- 1
Softech designed and built a headless-commerce system for Revea using Next.js and Medusa.
- 2
Revea sells products in a one-of-a-kind model where a specific piece can be available only once.
- 3
The Revea architecture separates the storefront from the commerce backend.
- 4
The Revea product model includes availability, reservation, locking and a final sold state.
- 5
The Revea storefront was built with Next.js.
- 6
The Revea commerce backend uses Medusa.
- 7
The project includes a dedicated checkout connected to payment and delivery.
- 8
Project integrations include payment providers, carriers or fulfillment, and email/SMS communication.
- 9
Locking in Revea reduces the risk of concurrent finalization of the same unique piece.
- 10
A sold piece should not remain active as an available product in the storefront.
- 11
The Revea case study does not publish previous percentage business claims without an approved baseline and measurement source.
- 12
Revea is a production ecommerce implementation described by Softech as composable/headless commerce.
Visual evidence
The diagrams present confirmed product scope and workflows described in this material. They are not mock-ups or claims of undocumented outcomes.
FAQ
Why did Revea use a headless architecture?
The project needed the brand and storefront layer to evolve independently from custom commerce logic for unique pieces. Next.js and Medusa separate those responsibilities.
How does the system reduce the risk of selling one item twice?
Availability for a unique piece is controlled through reservation and locking logic across cart and checkout. Finalization updates the product state so a sold item does not remain available for another purchase.
Is Revea a standard template-based online store?
No. The storefront, product logic and integrations were designed as a custom commerce system, with Medusa serving as an extensible backend rather than a closed store builder.
Which parts can evolve independently?
Collections and storytelling, PDP, availability rules, checkout, payments, fulfillment, communication and integrations can evolve as separate modules.
