# Marketplace MVP planning checklist

Template updated: 27 September 2026

Copy this file into your project brief. Complete the blanks, remove irrelevant rows, and assign an owner to each launch requirement. This is an ungated planning template; the hours, rates, and budget you enter are your estimates, not a Nomadic Soft quotation.

Companion guide: https://nomadicsoft.io/blog/how-to-build-an-online-marketplace

## 1. Define the first market

- Buyer and problem: [fill in]
- Seller and reason to participate: [fill in]
- Initial service/product category: [fill in]
- Region, language, and transaction currency: [fill in]
- Why the current alternative is inadequate: [fill in]
- How we will recruit the first buyers and sellers: [fill in]
- Revenue model and who pays: [fill in]
- Pilot owner, start date, and review date: [fill in]

What have we observed?

- Buyer interviews: [number/date]; repeated problem: [fill in]
- Seller interviews: [number/date]; willingness and capacity: [fill in]
- Manual pilot or other demand evidence: [fill in]
- Actual transactions or commitments, distinguished from expressions of interest: [fill in]
- Assumption most likely to invalidate the business: [fill in]
- Cheapest next test of that assumption: [fill in]

Decision: [ ] run a manual pilot first [ ] build a limited MVP [ ] revise the proposition.

## 2. Describe one complete transaction

**Hypothetical example: fixed-scope design services.** Choose one region, one currency, and one design category. Curate sellers manually and allow one seller per order. A buyer submits a brief; a seller accepts the scope; the agreed payment step happens; the seller delivers; the buyer completes the order or follows the cancellation/refund path.

This example is a scope exercise, not a claim about a Nomadic Soft client or a recommended payment arrangement.

Our first workflow: [entry point] → [request/selection] → [acceptance] → [payment step] → [delivery] → [completion].

Also decide what happens when:

- No seller accepts, or acceptance expires: [fill in]
- Payment fails or its status is uncertain: [fill in]
- Either party cancels or delivery is late: [fill in]
- Buyer requests revisions or a refund: [fill in]
- Support must intervene: [owner, evidence needed, next step]

## 3. Agree the pilot scope

Replace the example acceptance checks with checks someone can demonstrate before launch.

| Capability | Needed for pilot? | Acceptance check | Owner |
|---|---|---|---|
| Buyer request | [yes/no/manual] | Buyer submits the required brief and sees its status. | [name] |
| Seller onboarding | [yes/no/manual] | Only approved sellers can accept work; approval is recorded. | [name] |
| Seller acceptance | [yes/no/manual] | Seller sees scope, price, deadline, and can accept or decline. | [name] |
| Order record | [yes/no/manual] | Both parties see the agreed scope and current order status. | [name] |
| Payment | [yes/no/manual] | Success, failure, and pending states are handled without duplicating an order. | [name] |
| Delivery and completion | [yes/no/manual] | Delivery is recorded; completion follows the agreed acceptance rule. | [name] |
| Cancellation/refund | [yes/no/manual] | Support can follow the documented decision and record its outcome. | [name] |
| Admin/support | [yes/no/manual] | An authorized operator can find an order and review its history. | [name] |
| Notifications | [yes/no/manual] | Each party receives the essential next-action messages. | [name] |

Defer unless the pilot genuinely needs them: [ ] multi-seller cart [ ] native apps [ ] multiple currencies [ ] bidding [ ] complex AI features [ ] other: [fill in].

For every manual step, name its operator, record-keeping method, and expected time per order: [fill in].

## 4. Resolve operational decisions

- Seller information and approval checks required before trading: [fill in]
- Who charges the buyer, payment timing, and proposed provider: [fill in]
- Seller payment timing, platform fee, and reconciliation owner: [fill in]
- Provider support for the proposed countries and money flow confirmed by: [owner/date/evidence]
- Cancellation, revision, refund, and dispute rules visible before purchase: [location/owner]
- Prohibited listings, moderation process, and reporting route: [fill in]
- Support channel, operating hours, and response target: [fill in]
- Personal data needed, access roles, and retention/deletion decisions: [fill in]
- Integrations required now, and fallback if each fails: [fill in]
- Domain, repository, hosting, and provider account ownership: [fill in]
- Data export, backup restoration, credentials handover, and operating documentation demonstrated by: [owner/date]

If buyers or sellers are businesses, resolve these before estimating:

- Company accounts, employee roles, purchase approvals, and spending limits: [needed now/deferred; rule/owner]
- Fixed prices versus requests for quotes, negotiated terms, and quote expiry: [fill in]
- Purchase-order references, invoice ownership, tax information, credit/payment terms, and overdue-payment handling: [fill in]
- Supplier approval, catalogue/import ownership, and required accounting or procurement integrations: [fill in]

## 5. Build an estimate from the agreed scope

Enter low/high hours and the applicable rate for each workstream. Record assumptions beside uncertain items.

| Workstream | Low/high hours | Rate and currency | Assumption/owner |
|---|---|---|---|
| Discovery and design | [ / ] | [ ] | [ ] |
| Buyer/seller workflows | [ / ] | [ ] | [ ] |
| Payments and integrations | [ / ] | [ ] | [ ] |
| Admin and operations | [ / ] | [ ] | [ ] |
| QA, accessibility, and security checks | [ / ] | [ ] | [ ] |
| Deployment, documentation, and handover | [ / ] | [ ] | [ ] |
| Project coordination | [ / ] | [ ] | [ ] |

Development estimate = sum of each workstream's hours × its rate. Add an explicit uncertainty allowance: [amount/reason]. Separately budget recurring software/hosting, payment fees, seller recruitment, support, and marketing: [amounts/period]. Avoid counting the same work in two rows.

### Worked arithmetic example

These are **invented planning inputs**, not Nomadic Soft rates, a quotation, a market range, or an industry benchmark. The example uses the fixed-scope design-services scenario in section 2: one region, language, currency, and seller per order; manually curated sellers; a responsive website; and one payment provider whose support for the agreed money flow is confirmed before implementation.

| Workstream | Illustrative hours | Invented rate | Arithmetic |
|---|---:|---:|---:|
| Discovery and design | 70 | US$65/hour | US$4,550 |
| Buyer/seller workflows | 230 | US$65/hour | US$14,950 |
| Payments and integrations | 150 | US$65/hour | US$9,750 |
| Admin and operations | 100 | US$65/hour | US$6,500 |
| QA, accessibility, and security checks | 110 | US$65/hour | US$7,150 |
| Deployment, documentation, and handover | 50 | US$65/hour | US$3,250 |
| Project coordination | 90 | US$65/hour | US$5,850 |
| **Implementation subtotal** | **800** | | **US$52,000** |

- Implementation: 800 × US$65 = **US$52,000**.
- Illustrative uncertainty allowance: US$52,000 × 15% = **US$7,800**.
- Implementation plus allowance: **US$59,800**.
- The 15% allowance is an example planning choice, not a standard requirement or automatic fee. Avoid adding it again if uncertainty is already covered by your high estimate. New features require a scope decision.
- Developers' implementation checks are included in their workstream; the QA row covers separate cross-workflow verification, accessibility, and security checks.
- Excluded from this implementation example: multi-seller carts, native apps, escrow, cross-border expansion, bidding, subscriptions, automated dispute decisions, bulk historical migration, and ERP integration. Taxes, provider charges, ongoing operations, recruitment, and marketing need separate budgets.

At a hypothetical 80 combined project hours per week, 800 ÷ 80 = 10 capacity weeks. This is not an elapsed delivery commitment. Sequence dependencies, specialist availability, client reviews, provider approval, content, and testing separately; a budget allowance does not reserve calendar capacity.

### Complete the operating budget and compare proposals

| Cost category | Amount and currency | Billing period or usage basis | Source/assumption/owner |
|---|---|---|---|
| Hosting, storage, backup, and monitoring | [ ] | [ ] | [ ] |
| Software subscriptions and transactional messages | [ ] | [ ] | [ ] |
| Maintenance, incidents, and agreed support | [ ] | [ ] | [ ] |
| Payment/payout fees and relevant refund/dispute costs | [ ] | [ ] | [ ] |
| Seller onboarding, moderation, and order support | [ ] | [ ] | [ ] |
| Buyer/seller recruitment, content, and marketing | [ ] | [ ] | [ ] |

For operator effort, another invented example is 150 monthly orders × 12 minutes = 1,800 minutes = 30 hours. At an assumed internal cost of US$25/hour, that task costs US$750/month. Replace these inputs with observed effort and keep other support and platform costs separate.

Before comparing quotes, confirm:

- [ ] Suppliers estimate the same workflow, exclusions, provider assumptions, and acceptance checks.
- [ ] Payment uncertainty, cancellation/refund, permissions, and operator recovery are included.
- [ ] Integration, migration, content-entry, testing, environments, handover, and defect-support responsibilities are stated.
- [ ] Rates, currency, taxes, licenses, change pricing, and contingency treatment are explicit.
- [ ] Repository, infrastructure account, provider account, and data-export ownership are clear.
- [ ] Cost, effort, elapsed delivery dependencies, and recurring operating costs are separate.

Worked cost guide: https://nomadicsoft.io/blog/cost-of-building-a-marketplace-website
B2B scope guide: https://nomadicsoft.io/blog/b2b-marketplace-websites

## 6. Set pilot measures and a review decision

Choose the cohort and observation window: [fill in]. Set targets before launch; these are your decision thresholds, not industry benchmarks.

For each rate below, count both the numerator and denominator only within the same eligible cohort whose stated observation window has ended.

| Measure | Definition | Target |
|---|---|---|
| Acceptance rate | Requests accepted within [time] ÷ eligible submitted requests whose response window has ended. | [ ] |
| Paid-order rate | Accepted orders reaching successful payment ÷ accepted orders whose payment window has ended. | [ ] |
| Completion rate | Completed orders ÷ paid orders whose delivery/acceptance window has ended. | [ ] |
| Refund rate | Orders with any refund ÷ paid orders whose refund observation window has ended. | [ ] |
| Support effort | Total support minutes ÷ orders handled in the same cohort. | [ ] |

Also record absolute buyer, seller, and order counts; percentages from a handful of orders are weak evidence. Track revenue retained after refunds and variable costs, including operator time.

- [ ] The core workflow succeeds, including a failure/refund scenario.
- [ ] Supply, demand, and support capacity meet our stated thresholds.
- [ ] We know which assumptions remain untested and the cost of testing them.

Review outcome: [ ] expand [ ] continue the limited pilot [ ] change scope [ ] stop.

Evidence, decision owner, and next review date: [fill in].

Discuss an implementation brief: https://nomadicsoft.io/industries/marketplaces