The Marketflow Product Specification

The Feature

Marketflow needs a product specification that is precise enough to build from and small enough to ship in weeks, not months. This section defines every user role, every core entity, and the exact boundary between the free and paid tiers.

The Decision

The specification is deliberately minimal. Every feature included must pass one test: does a market organizer need this to run their next market day? Features that fail this test are deferred, even if they are obvious improvements. The goal is a product that one organizer can use to manage one market. Multi-market support, analytics dashboards, and automated stall assignments are paid-tier features that exist to justify the subscription, not to block the launch.

The Implementation

User Roles

Market Organizer. Creates and manages markets. Reviews vendor applications. Assigns stalls. Sets market day schedules. Collects vendor fees. Has full visibility into their market’s data and no visibility into any other market’s data.

Vendor. Applies to participate in a market. Uploads required documents (insurance certificates, health department permits, product photos). Views their stall assignments and upcoming market days. Pays booking fees through the platform.

Public Visitor. Views public market information: market name, location, schedule, and the list of participating vendors. No account required. This is the market’s public page, linked from the organizer’s website or social media.

Core Entities

Market. A named market with a location, description, operating schedule, and a list of stall positions. A market belongs to exactly one organizer. Examples: “Downtown Farmers Market,” “Riverside Artisan Fair.”

Stall. A physical position within a market. Has a label (“A1”, “B3”, “Corner Spot”), a size category (standard, double, corner), and optionally a price per market day. Stalls are the inventory that organizers sell to vendors.

Vendor Profile. A vendor’s business information: business name, product categories (produce, baked goods, crafts, prepared food), contact information, and uploaded documents. A vendor profile exists independently of any market. One vendor can apply to multiple markets.

Application. A vendor’s request to participate in a specific market. Contains the vendor’s profile reference, the market reference, a message from the vendor, and a status: pending, accepted, rejected, or waitlisted. Organizers review applications and change their status.

Booking. A confirmed stall assignment for a vendor on a specific market day or a recurring schedule. Created when an organizer accepts an application and assigns a stall. Tracks the fee amount and payment status.

Market Day. A specific date on which a market operates. Has a start time, end time, and a list of bookings (which vendors are in which stalls). Market days can be one-time or recurring (every Saturday, first Sunday of each month).

The Freemium Model

The free tier is not a trial. There is no expiration date. Markets with up to 20 active vendors use Marketflow without paying. This is a real product for small markets, not a teaser.

Free tier includes:

• One market
• Up to 20 active vendors
• Unlimited market days
• Vendor application management
• Stall assignments
• Public market page
• Email notifications for application decisions

Paid tier ($29/month) adds:

• Unlimited vendors
• Multiple markets under one account
• Vendor fee collection through Stripe (organizer connects their own Stripe account)
• Document storage for vendor permits and certificates
• Export market day reports as CSV
• Priority email support

The limit is enforced on active vendors, not total vendor profiles. A vendor who applied but was rejected does not count. A vendor who was accepted but has no upcoming bookings does not count. Only vendors with at least one booking in the current or next market day count toward the limit. This distinction matters because it prevents the limit from punishing organizers who receive many applications.

Minimum Viable Feature Set

The launch version of Marketflow requires exactly these features:

1. Organizer signup and login (Supabase Auth)
2. Create a market with name, location, and description
3. Define stalls within a market
4. Public vendor application page
5. Organizer reviews and accepts/rejects applications
6. Assign accepted vendors to stalls
7. Create market days (one-time, not recurring for v1)
8. Email notifications for application decisions (Resend)
9. Free tier enforcement (20 vendor limit)
10. Stripe subscription for paid tier upgrade

Recurring market days, vendor fee collection, document uploads, CSV exports, and multi-market support are post-launch features. They are designed into the data model (Chapter 4) so they can be added without schema changes, but they are not built until the core product is validated with real organizers.

The Trap

The trap is scope. Every feature in the “paid tier” list is a feature the developer wants to build before launching. Resist this. The paid tier features are the reason organizers upgrade. They are not the reason organizers sign up. Organizers sign up because managing vendor applications in Marketflow is less painful than managing them in a spreadsheet. The upgrade happens when the market grows past 20 vendors and the organizer is already dependent on the tool.

Building all paid features before launch delays the launch by months and provides no revenue during that time. Building the free tier and the subscription gate takes weeks and generates revenue from day one.

The Cost

The product specification costs nothing to write and saves weeks of building the wrong thing. The freemium model’s economics at various scales:

Scale	Paying Markets	Monthly Revenue	Infrastructure Cost	Margin
Launch	0	$0	€4.51	-€4.51
Early traction	5	$145	€4.51	~$140
Growing	20	$580	€8.79 (CX32 upgrade)	~$570
Tipping point	50	$1,450	~€20 (larger VPS)	~$1,425

The margins are attractive because the infrastructure cost stays nearly flat while revenue scales linearly with paying customers. This is the economics of SaaS on a bootstrapper’s budget. The product does not need thousands of customers to be profitable. It needs fifty.