Back

MVP Submission Terms & Guidelines

Last updated 16 May 2026

These guidelines govern what gets listed on MVPHub.com. MVPHub is operated by Zealand Design Media, an Auckland, New Zealand software studio. Read this page before you start a submission — meeting the requirements below is what separates listings we publish from ones we reject.

By submitting an MVP, you confirm that the work meets every requirement in sections 1–4, that you have the rights described in section 5, and that you agree to the review, pricing, and delisting terms in sections 6–10. The general Terms of Service and Privacy Policy also apply.


1. A working demo URL is required

Every MVP must be demonstrable before a buyer pays. Buyers will not purchase what they cannot try. Accordingly:

  • You must provide a live demo URL that renders the MVP running against a working backend (real or seeded data).
  • The demo must be publicly reachable — no IP allow-lists, no one-time Basic Auth prompts. Password-protected Shopify previews are acceptable if the password is disclosed in the listing description.
  • The demo must stay online for as long as the MVP is listed on MVPHub. If your demo goes down or no longer matches the listing, MVPHub may hide the listing until it is fixed.
  • If you do not have hosting, you can request MVPHub setup or installation support. Hosting and rebuild automation are handled case by case and are not included unless confirmed in writing.
  • For mobile MVPs (React Native / Flutter), the demo URL may be an Expo preview link, a TestFlight link, or a publicly downloadable APK/IPA. Static screenshots do not count as a demo.

2. Performance metrics must be disclosed

Buyers deserve to know whether they're adopting a fast product or a future performance problem. For every submission:

Web MVPs

Include the following in your submission description (or attach a Lighthouse report screenshot):

  • Largest Contentful Paint (LCP) — measured on 4G or slower
  • Cumulative Layout Shift (CLS)
  • Interaction to Next Paint (INP) or, if unavailable, First Input Delay (FID)
  • Total page weight on a representative PDP and category page (first-byte JS + images)
  • Lighthouse mobile score (Performance, Accessibility, SEO — run against the live demo, not localhost)

We reserve the right to re-run Lighthouse against your live demo during review. Submissions whose real-world metrics contradict the disclosed numbers are rejected.

Mobile MVPs

  • Cold-start time on a mid-tier device (Pixel 6 / iPhone 12 reference)
  • App bundle size after release build (--release / production scheme)
  • 60 fps on a representative scroll-heavy screen (category grid, product carousel, feed) — attach a profiling screenshot if the claim is contested in review

If metrics don't apply

Backend-only templates (Medusa backend, API services) are exempt — instead, disclose p50 / p95 request latency under a representative seeded load and list the benchmark script's location in the repo.


3. The MVP must be battle-tested

We do not accept weekend prototypes. "Battle-tested" means:

  • At least one production deployment exists (yours, a client's, or a paying customer's — acceptable in any scale). Submissions with zero production history are rejected unless explicitly listed as template-only.
  • Automated test coverage: at minimum a green CI pipeline with unit tests for core business logic, plus one Playwright or Cypress end-to-end spec covering the happy path (sign-up → key action → payment/checkout if applicable).
  • A known-issues / limitations section in the README. Every product has limits; hiding them is a rejection reason. An honest Known Issues list builds more trust than pretending there are none.
  • Security hygiene: parameterized queries, no hardcoded secrets in the repo, auth on protected routes, HTTPS-only demo, dependencies free of unresolved critical CVEs at submission time (pnpm audit / npm audit output clean or explicitly triaged).
  • Data-handling compliance with the region you claim to target. GDPR (EU), CCPA (California), Privacy Act (NZ) — if the product collects personal data, its handling must match.

We run a brief review against these points during approval. A submission that passes our automated checks but fails our manual review of production readiness will be sent back with notes.


4. Documentation and screenshots are mandatory

The product listing is how a buyer decides. Bare listings don't convert and waste everyone's time.

Required documentation (in the repo)

  • README.md with: what it is, stack summary, quick-start (≤ 5 commands to reach a running dev server), environment variables list, deployment guide (self-host + one managed option), and a "Known Issues" section.
  • LICENSE file matching what you declare in the listing (MIT / Apache-2.0 / BSD / Commercial / etc.).
  • Architecture note — even a single-page docs/ARCHITECTURE.md explaining the major moving parts and why they were chosen.
  • Setup / onboarding guide for buyers who are not the original author. Assume zero context.

Required visual assets on the MVPHub listing

  • Cover image: 1200×630 (PNG or JPEG), under 500 KB. Not the Next.js default template screenshot.
  • At least 4 product screenshots at ≥ 1280×800: homepage, a category/feature page, a buyer flow in action (cart / checkout / booking / etc.), and the admin or configuration surface.
  • Optional but recommended: a 30–90 second Loom-style walkthrough video linked from the listing. Walkthroughs materially lift conversion.

Listings that ship without screenshots or with placeholder Lorem Ipsum content are rejected at first review. You can resubmit once the gaps are filled.


5. Licensing, IP, and originality

  • You warrant that you own or have the right to list every line of code, asset, and document in the submission.
  • Third-party code must be under a commercial-use-compatible license (MIT, Apache-2.0, BSD, ISC, MPL-2.0). GPL / AGPL dependencies are permitted only if the listing license matches and the commercial implications are disclosed in the listing description.
  • No stolen, leaked, or re-uploaded work. Submissions found to violate third-party IP or duplicate an existing MVPHub listing are removed without refund.
  • Assets you did not create (stock photos, icon sets, fonts) must be either original, properly licensed for commercial redistribution, or replaceable on first run (documented in the README).
  • By submitting, you grant MVPHub a non-exclusive license to display the listing content (text, screenshots, demo URL, videos) on mvphub.com and across our marketing channels. You retain ownership of the code itself.

6. Pricing, revenue, and fees

  • One-time and subscription pricing are both supported via MvpVariant plans.
  • MVPHub may apply a platform fee to paid sales. The fee is calculated from your seller commercial tier, listing configuration, or platform settings and is shown or made available before selling. Stripe processing, currency conversion, dispute, and payout fees may also apply.
  • You may list free variants (priceCents = 0) alongside paid ones; free variants still go through the same review.
  • Framework ports not yet built should be submitted with onDemand = TRUE so they display as "On demand" placeholders. Buyers clicking them route to /request-mvp — real interest is how we prioritize builds.
  • Price changes take effect on submission; already-purchased orders retain their original price.
  • Refunds are handled per our Refund Policy. In brief: full refund within 48 hours of purchase if the code fails to deliver; no refund once the buyer has successfully downloaded and used the deliverable.

7. Review process and timeline

  • We aim to review every submission within 2 business days (Auckland time).
  • A first-pass review checks sections 1–4 mechanically: demo reachable, metrics disclosed, repo has README + LICENSE, screenshots present.
  • A second-pass review exercises the code against the stated claims — running the quick-start, hitting the demo, sanity-checking Lighthouse on the live URL.
  • If rejected, you receive specific reasons and a path to resubmit. Most rejections are fixable within a day.
  • If approved, your MVP becomes eligible for publishing. Some submissions are moved to Draft first so an admin or seller can finish pricing, visibility, deliverable readiness, and final copy before the listing is made public.
  • Once published, your MVP may appear on mvphub.com and in the next sitemap regeneration cycle.

Common rejection reasons

  • Demo URL is unreachable or returns errors
  • Disclosed performance numbers don't match our measurement
  • Submission is a renamed template with no original work
  • Screenshots are placeholders, theme defaults, or unrelated
  • Repo is private without a demo or meaningful description
  • License is unclear or GPL without disclosure

8. Updates, maintenance, and support

  • You commit to keeping the listing accurate — update the stack, demo URL, or pricing within 7 days of material change.
  • Security fixes for CVEs rated high or critical must ship within 30 days. MVPHub may temporarily delist products with unpatched critical CVEs.
  • You may optionally offer paid install / customization / support add-ons as additional MvpVariant rows flagged as 'service' kind. Install-service buyers expect a 5-business-day response SLA for initial contact.
  • MVPHub does not mandate a buyer-support SLA beyond the delivery of the code itself, but the listing description should clearly state what support (if any) is included.

9. Right to delist, edit, and terminate

  • MVPHub reserves the right to remove, unpublish, or edit any listing at any time if it violates these guidelines, the general Terms of Service, or applicable law.
  • You may manage or delist your own products through /account/my-mvps or /seller/products when your account has access. Already-purchased download grants remain honored where technically and legally possible, unless access must be revoked for refund, dispute, malware, abuse, licensing, or legal reasons.
  • Repeated violations (e.g. resubmitting rejected content without addressing the notes, submitting plagiarized work) may result in account suspension.

10. Governing law

These guidelines are governed by the laws of New Zealand. Any dispute arising from a submission that cannot be resolved via support (support@mvphub.com) will be heard in the courts of Auckland, New Zealand.


Quick-reference checklist

Before clicking submit, confirm you have all of these. If any box is unchecked, hold off — submitting incomplete listings wastes your review slot.

  • Live demo URL (or requested MVPHub hosting)
  • Performance metrics disclosed (web: LCP / CLS / INP / Lighthouse; mobile: cold-start / bundle / fps; backend: p50 / p95)
  • Production deployment evidence
  • Green CI with at least one E2E spec
  • README.md, LICENSE, architecture note, setup guide
  • 1200×630 cover image + ≥ 4 screenshots at ≥ 1280×800
  • You own the code or are licensed to redistribute it
  • No unresolved critical CVEs
  • Pricing set and accurate
  • Known-issues list is honest

Questions? Reach out at support@mvphub.com before you submit — we'd rather answer an "is this OK?" email than reject you.

Last updated: 2026-05-16.