Executive summary
Izložbica is a creator commerce platform for people who sell physical products through direct relationships rather than a traditional webshop.
The product has two main sides: a public tenant storefront — an izložbica — where customers browse products and place orders, and a private Pisarna backoffice where the creator manages products, orders, stock, payments, pickup, delivery, and settings.
The marketing site is live at izlozbica.si. A staging environment runs at demo.izlozbica.top. The codebase is private, but the platform architecture — multi-tenant Payload CMS, subdomain storefronts, and modular commerce modes — is documented and implemented.
The problem
Small creators often sell through Facebook posts, Instagram messages, markets, fairs, and personal pickup. The sales flow is personal, but the operational details quickly become messy.
The same creator has to answer which products are still available, where pickup is possible, when delivery or fair pickup happens, whether the buyer paid, what variant or quantity the customer wanted, and which customer belongs to which order — often across several chat threads and a notebook.
Izložbica tries to remove that mess without forcing the creator into a heavy ecommerce setup. A creator can use it as a simple catalogue with contact details, or as a full ordering flow with cart, checkout, payment instructions, delivery preferences, stock handling, and order management.
The thesis
The platform is built around tenant-specific storefronts. Each creator gets their own storefront and office context. Products, customers, orders, inventory, and settings must never leak between tenants.
The important product bet is flexibility. Not every creator needs full stock tracking or automated commerce from day one. The repo documents these tenant commerce modes:
- Listing mode — public catalogue and contact information, without cart or checkout
- Simple mode — cart, checkout, delivery or pickup preferences, and Pisarna order management
- Optional inventory mode — shared production-pool stock gates for creators who need stock control
- Optional auto-confirmation — orders can stay pending until the creator confirms them manually
That makes the product closer to a practical order desk than a generic marketplace clone.
Validation
What exists today:
- izlozbica.si — public marketing and positioning site
- demo.izlozbica.top — staging environment for product demos
- Creator onboarding — self-service multi-step wizard that publishes a tenant with products, variants, locations, delivery dates, payment settings, and optional stock
- Storefront — catalogue, PWA behaviour, cart, checkout links, customer account routes, share metadata
- Checkout — guest and authenticated flows with multiple fulfilment and payment paths
- Pisarna — creator backoffice for products, orders, attendance-style order management, and payment visibility
- E2E and Vitest coverage — Playwright and unit tests in the repo
What does not exist yet: documented paying customers, revenue, pricing validation, or formal user research in the repository.
What I built
Creator onboarding
A self-service multi-step onboarding wizard can publish a creator by creating the tenant, admin user, products, variants, locations, delivery dates, payment settings, and optional stable stock. The flow covers product setup, fulfilment setup, pickup or fair dates, payment settings, account creation, and optional stock-related steps.
Storefront
The storefront module covers the public product catalogue, product availability, PWA behaviour, onboarding helpers, tenant metadata, share URLs, cart integration, checkout links, newsletter actions, and customer account routes. Route files stay thin; product logic lives in modules.
Checkout
Checkout supports both guest and authenticated flows. Documented fulfilment paths include delivery by post, home pickup or personal delivery, and pickup at a fair or route location. Payment methods include COD, bank transfer, Flik, and Stripe, depending on tenant settings. Payment handling is separated from fulfilment.
Pisarna backoffice
Pisarna is the creator-facing management area: product editing, order management, stock visibility, manual orders, payment recording, tenant settings, and review/admin surfaces.
Inventory
Inventory is optional. When enabled, it shows a shared production-pool stock gate for creators who need stock control rather than forcing every tenant into inventory tracking from day one.
Architecture
The system is a multi-tenant Next.js and Payload CMS application. Each creator tenant gets a subdomain-based izložbica for the public storefront and a scoped Pisarna context for backoffice operations.
Marketing site (izlozbica.si)
→ Next.js + next-intl
Tenant storefront (subdomain per creator)
→ catalogue / cart / checkout
→ Payload CMS (tenant-scoped collections)
→ PostgreSQL + S3-compatible media
Pisarna backoffice
→ orders, products, stock, payments
→ role-based tenant access
→ same Payload backend
Payments
→ COD / bank transfer / Flik / Stripe per tenant config
Key technical choices: Payload CMS for multi-tenant data and admin; next-intl for locale-ready routing; TanStack Form + Zod for complex checkout and onboarding forms; Stripe where card payments are enabled; S3-compatible storage for product media.
Current status
Izložbica is shipped-private / demo-available. The marketing site and staging demo are public. The ordering platform runs as a private codebase with documented modules for onboarding, storefront, checkout, inventory, and Pisarna. There are no documented paying customers or revenue metrics in the repo.
Next steps to move forward: reference creator deployments on the marketing site, clearer cold-traffic demo path, and production tenant onboarding beyond staging — similar to how Farmica uses named reference farms as proof.
What I learned
Creators object to "webshop" language for the same reason farmers do. They sell through relationships and fairs first. A catalogue-plus-order-desk framing beats marketplace positioning.
Tenant scope is the hard invariant. Every feature — products, customers, orders, stock — must respect tenant boundaries from day one. Multi-tenant commerce fails quietly when scope leaks.
Mode flexibility beats feature completeness at launch. Listing-only tenants and optional inventory let creators adopt in stages instead of configuring a full shop before their first sale.