DEV Community

Daniel Ioni
Daniel Ioni

Posted on

Building a Free-First Marketplace: How MyZubster Plans to Connect Zorgax, Sellers and Payments

#zorgax #payments #seller #marketplace

Building a Free-First Marketplace: How MyZubster Plans to Connect Zorgax, Sellers and Payments

Building a marketplace is not only a payment problem.

Before asking people for cards, bank details or payment onboarding, there is a more fundamental question:

Can we make it easy enough for people to join, create useful listings, interact with others and experience the Marketplace first?

This is the direction we are now defining for MyZubster.

Our public roadmap follows a simple principle:

Free first. Activity first. Payments when payments are actually needed.

And Zorgax, our AI-assisted interface, is intended to become an important part of that experience.

1. Seller should not automatically mean “payment account”

One of the architectural decisions we want to preserve is:

Seller Account
!=
Payment Account
!=
Seller Pro
!=
Verified Seller
Enter fullscreen mode Exit fullscreen mode

These are different states.

Someone should be able to become a basic MyZubster Seller without immediately providing financial information.

Our target flow is:

Create account
      ↓
SELLER_FREE
      ↓
Create listings
      ↓
Receive requests
      ↓
Interact with the Marketplace
      ↓
Configure payments only when needed
Enter fullscreen mode Exit fullscreen mode

The initial target in our roadmap is up to 5 active commercial listings for a Free Seller.

Reaching that limit should not silently start a subscription.

It should not automatically request a card.

And it definitely should not be interpreted as authorization to charge the user.

2. Why we don't want Stripe in the first Seller experience

Payment infrastructure is useful when there is something to pay for.

But asking for financial onboarding before a person has even created their first listing creates unnecessary friction.

So our intended architecture separates:

Marketplace participation
Enter fullscreen mode Exit fullscreen mode

from:

Financial onboarding
Enter fullscreen mode Exit fullscreen mode

A Seller should initially be able to:

  • create a Seller profile;
  • publish eligible listings;
  • manage those listings;
  • receive Marketplace requests;
  • communicate with other participants;
  • build Marketplace activity.

Without configuring payments.

Later, if that Seller wants to receive platform-managed payments, we can introduce a separate action:

Activate Payments
Enter fullscreen mode Exit fullscreen mode

That is the moment when payment-provider onboarding becomes relevant.

3. Zorgax Listing Assistant

Removing payment friction is only half of the problem.

Creating a good marketplace listing can itself be difficult.

People have to decide:

  • What should the title be?
  • Which category should I choose?
  • How should I describe what I'm offering?
  • Should I specify a price?
  • Is it FREE or BARTER?
  • What information is missing?
  • Are there special Marketplace rules for this category?

This is where we want Zorgax to help.

Instead of making Zorgax just another generic chatbot popup, we are planning a contextual:

Zorgax Listing Assistant

The target experience looks like this:

Seller clicks:
"Create listing"

        ↓

Zorgax opens

        ↓

"What would you like to offer?"

        ↓

Seller describes the item/service

        ↓

Zorgax creates a structured draft

        ↓

Missing fields and Marketplace rules are checked

        ↓

Editable preview

        ↓

Seller confirms

        ↓

Publish
Enter fullscreen mode Exit fullscreen mode

The goal is simple:

reduce the distance between “I have something to offer” and “my listing is published.”

4. AI should assist — not manufacture facts

This is especially important for MyZubster.

Zorgax should be able to improve structure and wording.

It can suggest a title.

It can help organize a description.

It can detect missing fields.

It can explain Marketplace rules.

But it should not invent facts.

For example, Zorgax should never invent:

  • certifications;
  • measurements;
  • product condition;
  • ownership;
  • availability;
  • business status;
  • verification status;
  • environmental claims;
  • safety claims.

Our evidence-first rule for AI-assisted listings is therefore:

ZORGAX_DRAFT
!=
SELLER_CONFIRMED
!=
PUBLISHED
Enter fullscreen mode Exit fullscreen mode

A generated draft is only a draft.

The Seller remains responsible for reviewing and confirming the information before publication.

5. The first five listings become an experimentation layer

This changes how we think about the Free Seller account.

Instead of:

Register
↓
Pay
↓
Try the Marketplace
Enter fullscreen mode Exit fullscreen mode

we want:

Register
↓
SELLER_FREE
↓
Zorgax helps create the first listing
↓
Publish
↓
Experiment
↓
Receive requests
↓
Learn how the Marketplace works
Enter fullscreen mode Exit fullscreen mode

The first listings are therefore not simply “free inventory slots.”

They are an onboarding and experimentation layer.

Zorgax can also explain the current state:

Free Seller

Active listings: 2 / 5

Payments configured: No
Enter fullscreen mode Exit fullscreen mode

without turning that information into a payment prompt.

6. Then we measure whether the Marketplace creates value

Before deciding how aggressively to monetize Sellers, we want evidence.

Some of the metrics we want to observe include:

SELLER_FREE activations

1st listing published

Sellers reaching 3 listings

Sellers reaching 5 listings

Marketplace requests

Accepted requests

Completed exchanges

Repeat Seller activity

Seller retention
Enter fullscreen mode Exit fullscreen mode

And with Zorgax:

Listing Assistant opened

Draft generated

Draft confirmed

Draft abandoned

Time to first listing

Manual vs Zorgax-assisted completion
Enter fullscreen mode Exit fullscreen mode

This can tell us something much more useful than simply asking:

“How much should we charge?”

It can tell us whether the Marketplace is actually helping people do something.

7. Payments become a separate capability

Once real Marketplace activity exists, we can introduce a payment state machine.

Conceptually:

PAYMENT_NOT_CONFIGURED
        ↓
PAYMENT_ONBOARDING
        ↓
PAYMENT_REVIEW
        ↓
PAYMENT_READY
Enter fullscreen mode Exit fullscreen mode

A Seller would explicitly choose:

Activate Payments
Enter fullscreen mode Exit fullscreen mode

Only then would the relevant payment-provider onboarding begin.

This means a MyZubster account could legitimately look like:

membership: SELLER_FREE
payment: PAYMENT_NOT_CONFIGURED
Enter fullscreen mode Exit fullscreen mode

and remain perfectly valid.

Another Seller could eventually be:

membership: SELLER_FREE
payment: PAYMENT_READY
Enter fullscreen mode Exit fullscreen mode

These states should not be mixed together.

8. Monetize economic activity, not experimentation

This also opens another possibility.

Instead of requiring every Seller to pay a monthly fee simply to participate, MyZubster could eventually monetize actual economic activity.

Conceptually:

Buyer payment
      ↓
Payment processor
      ↓
Processing costs
      ↓
Clearly disclosed MyZubster fee
      ↓
Seller balance / payout
Enter fullscreen mode Exit fullscreen mode

We are deliberately not fixing a commission percentage yet.

Before doing that, we need real information about transaction sizes, categories, payment costs, refunds, disputes and actual Marketplace usage.

The business model should follow evidence rather than assumptions.

9. Seller Pro can come later

A Free Seller does not prevent MyZubster from eventually having paid services.

A future SELLER_PRO could potentially include things such as:

More listing capacity

Advanced analytics

Advanced Zorgax tools

Automation

Business workflows

Promotional tools

Professional inventory features
Enter fullscreen mode Exit fullscreen mode

But Pro should be an additional capability.

It should not redefine the basic identity of a Seller.

Again:

SELLER_PRO != PAYMENT_READY
Enter fullscreen mode Exit fullscreen mode

A Pro user might not use integrated payments.

And a Free Seller might eventually use integrated payments.

10. Zorgax could eventually help with payments too

There is another interesting direction here.

The same Zorgax interface that helps someone create a listing could eventually explain payment states.

For example:

Seller:
"Why can't I receive payments yet?"

Zorgax:
"Your Seller account is active, but payment onboarding
has not been completed."
Enter fullscreen mode Exit fullscreen mode

Or:

Seller:
"Was this order paid?"

Zorgax:
"The order was authorized, but settlement has not
been confirmed yet."
Enter fullscreen mode Exit fullscreen mode

That requires Zorgax to respect the underlying evidence.

We want to preserve distinctions such as:

REQUESTED
!=
AUTHORIZED
!=
PAID
!=
SETTLED
Enter fullscreen mode Exit fullscreen mode

AI should navigate evidence.

It should not upgrade evidence.

11. The architecture we are aiming for

Putting everything together:

USER
 │
 ▼
FREE ACCOUNT
 │
 ▼
SELLER_FREE
 │
 ▼
ZORGAX LISTING ASSISTANT
 │
 ▼
DRAFT
 │
 ▼
SELLER CONFIRMATION
 │
 ▼
MARKETPLACE LISTING
 │
 ▼
REQUEST / INTERACTION
 │
 ▼
REAL MARKETPLACE ACTIVITY
 │
 ├───────────────┐
 │               │
 ▼               ▼
KEEP USING     ACTIVATE
FREE SELLER    PAYMENTS
                 │
                 ▼
           PAYMENT ONBOARDING
                 │
                 ▼
            PAYMENT_READY
                 │
                 ▼
          REAL TRANSACTIONS
Enter fullscreen mode Exit fullscreen mode

And independently:

SELLER_PRO
Enter fullscreen mode Exit fullscreen mode

can eventually become an optional professional layer.

12. What comes next

Our implementation priorities are now becoming clearer.

First:

SELLER_FREE
+
5-listing experimentation model
+
Zorgax Listing Assistant
+
Marketplace metrics
Enter fullscreen mode Exit fullscreen mode

Then:

Marketplace usage analysis
+
payment-state architecture
+
Activate Payments UX
+
sandbox payment testing
Enter fullscreen mode Exit fullscreen mode

And only after those stages:

production payment onboarding
+
real transaction processing
+
transparent marketplace fees
+
optional Seller Pro
Enter fullscreen mode Exit fullscreen mode

Build activity before building friction

The idea behind this roadmap is straightforward.

If somebody downloads MyZubster and wants to try selling something, the first experience should not be:

“Give us your banking information.”

It should be:

“What would you like to offer? Zorgax can help you create your first listing.”

Let people experiment.

Let them create.

Let the Marketplace develop activity.

Measure what actually happens.

Then introduce financial infrastructure when there is a genuine financial action to perform.

That is the direction behind our current MyZubster Marketplace roadmap:

Join for free. Let Zorgax help you create your first listing. Experiment for free. Build real Marketplace activity first. Financial onboarding starts only when payments are actually needed.

Public roadmap:
https://github.com/MyZubster-Ecosystem/myzubster/blob/main/

Top comments (0)