Building MyZubster: Turning a Marketplace Demo Into a Real Product Experience
Over the last few development sessions, I’ve been working on a major evolution of MyZubster, especially around the Marketplace, demo experience, payments, subscriptions, and deployment workflow.
What started as a simple marketplace demonstration is gradually becoming a much more structured product.
Here’s what we’ve been building.
From a Few Demo Listings to Full Marketplace Coverage
One of the first problems was simple: the Marketplace supported more categories than the demo actually showed.
We fixed that.
The MyZubster Marketplace Demo now covers 12/12 marketplace categories, including:
Seeds
Plants
Produce
Clothing
Accessories
Event Equipment
Tools
Services
Volunteering
Pet Adoption
Lost & Found Pets
Pet Services
This matters because a marketplace demo should represent the real structure of the platform, not just a small subset of it.
We also added regression coverage so that introducing a new category without a corresponding demo becomes easier to detect.
Marketplace Demo v2
The next step was turning those examples into something people could actually explore.
Marketplace Demo v2 now includes category, location, text and payment-type filtering, richer listing details, category-specific information and a simulated request flow.
The simulation is deliberately separated from real commerce.
A demo interaction must never accidentally create:
an order, a payment, a message or personal data.
That distinction became an important architectural principle for the project.
Not Everything in a Marketplace Is a Product
Another interesting problem appeared when working on categories such as volunteering and pets.
A volunteer opportunity shouldn't behave like a T-shirt listing.
A lost-pet alert isn't a product.
And pet adoption should never look like we're selling an animal.
So the demo started introducing category-specific semantics.
For example, volunteering can describe activities and commitment, while adoption can describe the animal, association and adoption procedure. Lost & Found can communicate an approximate area while avoiding unnecessary exposure of an exact location.
The goal is to make the Marketplace flexible without forcing every type of interaction into the same e-commerce model.
Building the Visual Demo Layer
We also started moving beyond emoji-only demo cards.
We created dedicated MyZubster Marketplace visuals and integrated them into the demo experience.
One visual introduces Marketplace Demo v2, while another presents the broader category ecosystem.
The category visual isn't just decoration: the surrounding interface connects it with the actual category filters so visitors can move directly from discovery to exploring demo listings.
And this led to a very real deployment bug.
The PNG files existed in the repository, but the production application routing was intercepting /images/... requests and returning the SPA HTML instead of the image.
Classic case of:
“The file exists” does not mean “the browser can actually receive it.”
We traced the problem through GitHub and Vercel, corrected the delivery path, tested it in preview and moved the fix through the normal PR → deployment pipeline.
These small production problems are often where the most useful engineering lessons come from.
Payments: A Payment Is Not an Entitlement
We also spent significant time cleaning up MyZubster's monetization architecture.
One important discovery came from an account that had an active €9.90/month Stripe subscription, while Zorgax still displayed the Free plan.
At first glance that looked like a billing bug.
It wasn't.
The subscription belonged to Marketplace Seller, not Zorgax.
That exposed an important rule:
A successful payment doesn't automatically tell you what the user is entitled to access.
So we separated the concepts more clearly.
The architecture is moving toward:
Payment Intent → Purchase → Entitlement
with Stripe and BTC payments feeding the same entitlement model where appropriate.
Marketplace Seller and Zorgax are now treated as separate products with separate access rights.
The UI reflects that too: someone can legitimately have:
Zorgax: Free
while simultaneously having:
Marketplace: Seller active
That's not an error. That's the correct representation of two independent products.
One Demo, One Marketplace
We also consolidated the demo experience.
Instead of maintaining a disconnected demo page that could slowly drift away from the actual Marketplace, the demo now lives inside the real Marketplace experience.
A deep link such as:
/marketplace?demo=1
can take visitors directly into the demo area.
We added automatic focus/scroll behavior for that entry point and continued improving the mobile experience, responsive detail modal and interface translations.
Where MyZubster Is Going
The interesting part of this work isn't any single feature.
It's the boundaries we're establishing:
demo vs real transaction
payment vs entitlement
Seller vs Zorgax
generic listings vs category-specific behavior
frontend assets vs production routing
Those boundaries make the system easier to understand and much safer to extend.
MyZubster is still evolving, but the Marketplace is increasingly becoming something people can explore as a product rather than just look at as a prototype.
And we're continuing to build it in public.
MyZubster:
https://www.myzubster.com/
Marketplace Demo v2:
https://www.myzubster.com/marketplace?demo=1
Open-source repository:
https://github.com/MyZubster-Ecosystem/myzubster
