MVP in two weeks
On 4 September 2026 the founder decided not to wait for the six-week Phase 0 and the fourteen-week Phase 1 before anything real happens. Instead, a two-week sprint from Monday 7 September to Sunday 20 September 2026 builds a smaller product, and the first real gig is dispatched on Monday 21 September 2026. This page describes exactly what that smaller product is, what is deliberately left out, the blockers that could delay it, the day-by-day build, how the manual steps work, what "done" has to mean before launch, how the manual work gets automated afterwards, and the risks specific to moving this fast.
On this page
- 1. The decision
- 2. What is in and what is out
- 3. Why a web app and not native apps
- 4. Blockers and lead times
- 5. The sprint, day by day
- 6. How each manual step works at MVP
- 7. What "done" looks like on 20 September
- 8. Build-out after launch
- 9. Risks specific to the two-week plan
1. The decision
The earlier plan described Phase 0 (Foundations, six weeks) and Phase 1 (MVP build, fourteen weeks) as the path to a working product. The founder's decision on 4 September 2026 is to compress the useful part of both into two weeks, sprinting from Monday 7 September to Sunday 20 September 2026, and to dispatch the first real gig on Monday 21 September 2026. Everything the longer plan would still build, automated review, automated view reads, native apps, automatic posting, does not disappear. It becomes build-out work that happens while the product is already live, rather than work that happens before anyone can use it. Phase 0 and Phase 1 are relabelled to match: "MVP sprint" for 7 to 20 September 2026, and "Build-out while live" for 21 September 2026 to 22 January 2027. The later phases keep their dates as fixed points: open creator beta on 25 January 2027 and self-serve public launch on 29 March 2027 are unchanged, as the Timeline page shows.
"MVP" on this page means something specific: real dispatch, real money, and everything else by hand. Real dispatch means offers actually go out to real creators through a working candidate list and wave system, with a real 30-minute expiry and real accept and decline buttons, not a demonstration. Real money means a real fund deposited by a real brand, a real double-entry ledger, and real payouts landing in a real bank account on the 1st of the month, starting 1 October 2026. Everything else, the parts of the full product that would normally be a language model scoring a checklist, an API reading a view count, or an app store listing, is done by a person using a plain form instead, mostly the founder in the first weeks. The next sections spell out exactly where that line sits.
2. What is in and what is out
The list below follows the founder's own two-week scope (brief section 28). Nothing here is invented for speed; it is the same product described elsewhere on this site, with the automation stripped out and a person put in its place.
In the two-week MVP:
- A web app, installable to a phone's home screen, not native iOS or Android apps.
- Sign-in with Google or a phone number and a one-time code.
- Creators type in their platform handles by hand; there is no OAuth connection yet.
- Dispatch is real and automatic from day one: a candidate list, offer waves, a 30-minute expiry, and real accept and decline actions.
- The founder checks every submission by hand against the brand's checklist, item by item; AI verification is the target (section 6.2).
- Posting is creator-posted, with the founder running the four link checks by hand (section 6.3).
- Views are read by hand once a day for every live post, and pay releases on each read (section 6.4).
- The wallet and the double-entry ledger are real from day one.
- Payouts run on the 1st of every month, with the first run on 1 October 2026.
- Brands get a campaign form with four inputs only: product (URL first: the brand enters the product URL, AI drafts the campaign name, brief, key message and checklist from the site, and the brand edits them; plus the destination link, an optional promo code and assets), budget (the deposit, minimum $100, from steps of $100, $500, $1,000, $2,500, $4,000, $6,000, $8,000 and $10,000, with the platform's 20% share stated on the form), audience (an audience picker, for example "US developers," not a country or city list, and one of the ten V1 categories: AI tools, SaaS and web apps, developer tools, productivity apps, fitness apps, health apps, lifestyle apps, education apps, kids apps, games) and distribution preference ("more posts", "fewer, bigger posts", or "auto"). There is no city targeting in the V1 form. The platforms and formats, the deadline and the sample flow are chosen by the platform with sensible defaults, sitting under "advanced options" if a brand wants to change them; the checklist itself is the brand's own, AI-drafted and brand-edited, up to 10 items.
- Before funding, the planner shows an expected range, for example "Expected: 400,000 to 500,000 views" for the budget typed in, never a single promised number (assumption; the range is 80% to 100% of the sum of the matched creators' expected views).
- Brands get a results dashboard: Fund, Spent, Pending, Balance and Reserved, posts live with links, views, clicks, and cost per 1,000 views for the campaign, per platform and per post, updated on every daily read. Campaigns are draft, live or paused; everything else is a banner.
- Verification is core at MVP, not an add-on: every posted link is put through the four checks by hand (public; ad label; campaign hashtag and brand tag; video matches the approved submission) before its floor pays out, and only views reported by the platform's official API are ever paid for or reported (section 6.4).
- Ops gets a plain table of gigs and submissions with actions, working before the first dispatch.
V1 pilot brands are indie developers and small SaaS companies, not general consumer or local brands (brief section 50 item 1). The running example on this page is Acme Notes, a note-taking app for developers made by a solo indie developer in Berlin, funding a campaign for the audience "US developers" in the "developer tools" category.
Out of the two-week MVP, landing later in the build-out (section 8):
- Native iOS and Android apps.
- OAuth connections to Instagram, YouTube, TikTok and X.
- AI verification of each submission against the brand's checklist, by a vision and language model.
- Frame perceptual-hash matching to verify a posted video against the approved file.
- Automatic posting through each platform's publishing API.
- Automatic payment of the $5 referral reward; the referral link itself does exist.
- Instant payout at a 2% fee.
- Volume pricing and managed campaigns; only the pay as you go price exists at launch.
- Clipping (repurposing brand-provided footage).
3. Why a web app and not native apps
Native apps do not fit inside a two-week sprint, for reasons that come from the app stores themselves rather than from anything Distribution Club controls. A new personal Google Play account must run a closed test with 12 testers for 14 days before it can publish to production; that window alone is as long as the whole sprint. This rule applies to personal accounts, reportedly those created after November 2023 (assumption; verify against current documentation). An organisation account skips the closed test, but needs a D-U-N-S number and a verification step that takes about 1 to 2 weeks on its own. Apple is faster but still too slow for two weeks: Developer Program enrollment takes 1 to 3 days for an individual or 3 to 10 days for an organisation, and the first submission then waits 2 to 5 days for review, with about 40% of first submissions rejected outright and needing a fix and a second review.
Because none of that fits, the MVP is a web app that works in a mobile browser and can be added to a phone's home screen, so it behaves like an app for the people using it without going through either store. Both the Google Play and Apple applications still start in week 1, in the background, because they take weeks either way and the native apps are wanted for the build-out (section 8). Starting them on day 1 means the store gates are further along by the time the founder is ready to build the native apps, instead of only starting the clock once that work begins.
4. Blockers and lead times
The sprint's biggest risk is not the software, which is a known, bounded build. It is the list of outside approvals and accounts that Distribution Club does not control the timing of. Every item below starts on 7 September 2026, the first day of the sprint, and every lead time should be checked against current documentation before it is relied on.
| Item | Start by | Expected time | Needed for |
|---|---|---|---|
| Company and bank | 7 September 2026 | 7 to 15 working days | Any brand fund deposit |
| GST registration | Once incorporation is filed | 3 to 7 working days after incorporation | The first brand invoice |
| Razorpay account (pay-in) | 7 September 2026 | 1 to 3 working days after KYC | Collecting brand payments |
| Razorpay Route | 7 September 2026, during onboarding | 1 to 2 weeks | Launch blocker: holding and splitting brand funds to creators without the platform touching the money, and keeping GST on the platform's 20% cut only instead of on the full price (see Payments) |
| RazorpayX (Cashfree Payouts is closed to proprietorships, confirmed 12 September 2026) | 7 September 2026 | 2 to 5 working days | Paying Indian creators by UPI, IMPS or NEFT |
| Karbon or PayPal, one payment at a time (Payoneer India is receive-only and PayPal India has no bulk Payouts, confirmed 16 and 17 September 2026) | 7 September 2026 | Self-serve signup; sales reply outstanding | Paying creators outside India above a fee threshold |
| WhatsApp Business API | 7 September 2026 | 1 to 2 weeks for verification, then 1 to 3 days for the API | Offer delivery by WhatsApp (SMS and email work from day one) |
| Google Play | 7 September 2026 | 1 to 2 weeks for an organisation account, or a 12-tester, 14-day closed test for a personal account | The native Android app, in the build-out |
| Apple Developer Program | 7 September 2026 | 1 to 3 days (individual) or 3 to 10 days (organisation) to enrol, then 2 to 5 days for first review | The native iOS app, in the build-out |
| Platform APIs (Meta, Google, TikTok, X) | 7 September 2026 | 2 to 8 weeks | Automated posting and view reads, in the build-out; not needed for the two-week launch |
| Legal papers | 7 September 2026 | About a week | Must be live before the first dispatch |
| Chartered accountant | 7 September 2026 | Ongoing; confirmed before the first payout | TDS treatment and GST on the platform's 20% cut before 1 October 2026 |
The critical path runs through three of these in order: the company and its bank account first, then the Razorpay pay-in account, then a way to pay creators, either Razorpay Route or its dated fallback, RazorpayX paying from the entity's own account. Razorpay Route is itself a launch blocker, not just a convenience: with it approved, Distribution Club launches as a marketplace with GST on its 20% cut only; without it, the fallback runs the first gigs as the principal, with GST on the full price of those gigs, until Route clears (see Payments). Everything else on the list matters, but nothing else stops the first dispatch on 21 September 2026. If the entity is not ready by then, the launch still happens: only dogfood gigs are dispatched, paid from the founder's own account, and no brand deposits are collected until the entity and the Razorpay pay-in account are both working. See Payments for how the Indian-entity rails fit together.
5. The sprint, day by day
The fourteen days of the sprint fall into five blocks of building work, plus a dogfood day and a launch-readiness day. Weekend days (12, 13, 19 and 20 September) carry lighter build targets so the founder is not burned out before launch.
| Day | Date | Build | Also start |
|---|---|---|---|
| 1 | 7 September 2026 | Data model and the double-entry ledger | Every blocker in section 4 (company and bank, Razorpay, WhatsApp, Google Play, Apple, platform APIs, legal papers, accountant) |
| 2 | 8 September 2026 | Auth: Google sign-in and phone one-time code | Validate the payment flow end to end with one real small transfer, before the ledger is relied on for real money: a brand pays through Cashfree or Razorpay, funds are held (Route or the dated fallback), one creator is paid through RazorpayX, and one creator abroad through Payoneer if it is already available (assumption, brief section 49 item 7) |
| 3 | 9 September 2026 | Creator sign-up and handle entry | - |
| 4 | 10 September 2026 | Availability hours and the league-by-hand tool for ops | - |
| 5 | 11 September 2026 | Brand campaign creation form (product URL first, AI draft, brand edits) and fund deposit | Redirect service for tracked short links (assumption) |
| 6 | 12 September 2026 | Dispatch engine core: candidate list and matching (lighter, weekend) | - |
| 7 | 13 September 2026 | Dispatch waves and the 30-minute offer expiry (lighter, weekend) | - |
| 8 | 14 September 2026 | Offer notifications: WhatsApp or SMS and email with an accept link, plus web push | - |
| 9 | 15 September 2026 | Submission upload and the review form (checklist as pass or fail) | - |
| 10 | 16 September 2026 | Approved package, the four link checks, floor and daily-refresh release logic | - |
| 11 | 17 September 2026 | Wallet and the payout batch export | - |
| 12 | 18 September 2026 | Brand dashboard and the ops console table | Legal papers should be finalised and ready to publish |
| 13 | 19 September 2026 | Dogfood on the founder's own account and the 20 friendly-creator accounts (lighter, weekend) | - |
| 14 | 20 September 2026 | Fix bugs found in dogfood; fund the first pilot brand campaign (lighter, weekend) | Confirm entity and Razorpay status for 21 September; fall back to dogfood-only if not ready |
The day-by-day split is the founder's own plan and is treated as an assumption on the level of detail, since the brief groups several days under one heading rather than naming a build for each single day. The payment-flow validation on day 2 is placed there as an assumption too: the brief only says it happens before the ledger is relied on for real money, not on which exact day, and day 2 or 3 fits before any real fund is deposited on day 5. The first pilot brand's campaign is funded on day 14 so that the first real gig can be dispatched the next morning, Monday 21 September 2026.
6. How each manual step works at MVP
Six parts of the full product are done by a person at MVP instead of by software. In every case the underlying rule (the league table, the checklist, the CPM by league, the payout cycle) is exactly the same as the full product described elsewhere on this site; only the method of doing it changes.
6.1 Setting a league and CPM by hand
There is no OAuth connection at MVP, so the system cannot read a creator's post history itself. Instead, a creator types in their handle for each platform they use. Ops (in the first weeks, the founder or whoever is covering that role) opens each handle, looks at the creator's last 10 public posts, and works out the median number of views across them. That median is checked against the league table: 5,000 to 9,999 median views is Bronze 1; 10,000 to 14,999 is Bronze 2; 15,000 to 24,999 is Silver 1; 25,000 to 49,999 is Silver 2; 50,000 to 99,999 is Gold 1; 100,000 to 149,999 is Gold 2; 150,000 to 499,999 is Ruby; and 500,000 and above is Diamond. Below 5,000 median views, the creator is not eligible on that platform. A creator can sit in a different league on each platform they connect, exactly as in the full product; only the way the median is found, a person looking instead of an API call, is different.
The creator's CPM also depends on their audience geography, which the full product reads from the platform's own audience insights screen. At MVP there is no API access to that screen, so ops instead asks the creator for a screenshot of it and reads off the tier by hand: a screenshot showing most of the audience in the United States, Canada, the United Kingdom or Australia sets Tier 1; Western Europe, Japan, Korea, Singapore or the Gulf states sets Tier 2; Brazil, Mexico, Turkey, Eastern Europe or South East Asia except Indonesia sets Tier 3; India, Indonesia, Pakistan, Bangladesh, the Philippines, Nigeria or Egypt sets Tier 4. This tier, together with the platform, the campaign's category and the league factor, sets the CPM; see Rate cards for the full formula and factor tables. For example, Acme Notes funds a campaign for the audience "US developers" in the developer tools category; a creator whose own audience screenshot shows mostly United States viewers, such as Priya, who makes developer-productivity content, Bronze 1, 10,000 median views, matches that audience segment regardless of which country Priya herself lives in. The brand campaign form built on day 5 uses this CPM to work out how many gigs, and how many expected views, a brand's fund buys: what one gig takes from the fund is expected earnings plus a $2.00 running cost, divided by 0.8 (assumption; see Business model). The running cost is inside that one number and is never shown to the brand as a separate line.
6.2 Reviewing a submission
Every submission at MVP is checked by the founder by hand, at an estimated 50 to 100 a day once a campaign is running. The checklist is the brand's own, up to 10 items, presented as a form: the founder watches the video, reads the caption, and marks each item pass or fail, with a one-line reason for any failure. Every item must pass for approval. A submission that fails gets one revision round with a 48-hour deadline; a second failure cancels the gig with $0 paid, and the fee returns to the campaign's fund. The founder aims for a decision within 48 hours of submission, the same target the full product sets for its human review step. AI verification, which checks each item the same way and returns pass or fail with a reason, is the target; it is build-out work, added once daily volume passes roughly 100 submissions a day, the amount one person can no longer check inside 48 hours.
6.3 Verifying a posted link
Posting stays creator-posted at MVP, the same as the full product's default: the creator gets the exact approved video and caption, posts it themselves within 24 hours of approval, and pastes the link back into the app. At MVP the founder runs the four checks by hand instead of by software: the post is public; it carries the ad label ("#ad" and the platform's paid-partnership or branded-content label); it carries the campaign hashtag and the brand tag; and the posted video matches the approved submission, watched side by side. Passing all four is what verified means: the floor (20% of expected earnings, released as Pending) pays out, and the 14-day earning window starts from the post's own publish time.
6.4 Reading views once a day
The full product refreshes views from each platform's API once a day for every live post, for the 14 days a post earns, with up to 5 extra refreshes a day per campaign on a brand's request, on every platform including X. At MVP there is no API read access yet, so ops reads the public view count by hand once a day for each live post, or asks the creator to send a screenshot if the count is not public on that platform; a brand's extra-refresh request reaches ops as a task. Each read computes pay directly: views divided by 1,000, times the creator's CPM, minus whatever was already released, is the amount released into the wallet as Pending, then moved to Available after the usual 48-hour fraud-check hold. The maximum payout is the creator's expected earnings (their median views times the CPM), unless the brand has switched on an optional bonus of up to 1.5 times expected; views beyond the median do not add more to this gig but raise the creator's median for future gigs. Only the method of reading, a person looking instead of an API call, is different; the arithmetic is identical to the full product.
Only views reported by the platform's official API are ever paid for or reported to a brand, and at MVP the pay-hold check is a hand check on samples, not on every post: ops looks by hand at every post that shows a velocity or geography anomaly, plus another 10% chosen at random, checking for bot-like view patterns, an audience geography that does not match the creator's usual audience, and content that looks recycled from another post (brief section 49 item 5). Automated fraud checks, perceptual hashing and anomaly rules, are build-out work (section 8). Bot traffic runs an estimated 20 to 30% of views in Tier 3 and Tier 4 markets, so ops treats posts from those audiences as needing a closer look, checking a larger share of them by hand than the 10% random sample used elsewhere (assumption).
6.5 Running the payout on the 1st
Payouts still run on the 1st of every month, and the first run is 1 October 2026. At MVP the founder runs it by hand: export every creator's Available balance from the ledger where it is at least $20 and payout setup is complete, upload that list to RazorpayX, or pay from the entity's own Razorpay account and bank if Route is not yet approved, and once the transfers clear, mark each one Paid in the ledger. Balances under $20 roll over to the next month. This is the one place where the two-week plan insists on precision from day one: the wallet and the ledger are real and double-entry, because money is the part that must never be approximate.
6.6 Paying a referral reward by hand
The referral link exists from day one; every creator has one, and dogfood videos carry it in their caption. What is not built yet is the automatic $5 reward. At MVP, when a referred creator completes their first gig and its post goes live (the floor releases), the founder looks up who referred them and adds $5 to the referrer's wallet by hand in the ops console, the same amount and the same trigger as the full automated version. Because dogfood campaigns do not start until day 13 of the sprint, 19 September 2026, the first referral rewards are unlikely to happen before then.
7. What "done" looks like on 20 September
Before the first real gig is dispatched on 21 September 2026, all of the following must be true:
- The web app is live, works on mobile browsers, and can be added to a phone's home screen.
- Sign-in works with Google and with a phone number and a one-time code.
- A creator can sign up, enter their handles, and have ops set their league by hand from the median of their last 10 posts.
- Availability hours can be set, defaulting to always available.
- A brand can complete the campaign form with its four inputs, product, budget, audience (the audience picker, one of the ten V1 categories, no city filter) and distribution preference, and deposit a fund of at least $100, from the budget steps up to $10,000; the campaign name, brief, key message and checklist are drafted by AI from the product URL and edited by the brand, up to 10 items; the planner shows an expected range of views for the budget chosen.
- The dispatch engine sends real offers in waves, each expiring after 30 minutes, delivered by WhatsApp or SMS and email with an accept link.
- The founder's review form works: the brand's checklist as pass or fail with a reason for every failure, and the approved package generated on approval.
- The four link checks are written down and someone knows how to carry them out.
- The process for reading views once a day for every live post is agreed and someone is assigned to do it.
- The wallet and the double-entry ledger work, including the 48-hour fraud hold on each release.
- The ops console exists as a plain table of gigs and submissions with actions.
- Creator terms, brand terms, the privacy policy and the disclosure policy are live, and the entity's payment status for 21 September, full brand deposits, or dogfood-only from the founder's own account, is confirmed.
- Razorpay Route is approved, or the RazorpayX fallback is signed off by the lawyer, so it is known from day one whether the first gigs launch as a marketplace with GST on the platform's 20% cut only, or as the dated fallback with GST on the full price of those gigs.
- The payment flow has been validated end to end with one real small transfer: a brand payment collected, funds held, one creator paid through RazorpayX and, if available, one creator abroad paid through Karbon (assumption, brief section 49 item 7).
- The team knows what the MVP success test is and can track it once the first pilot brand's 14-day window runs: a $1,000 deposit producing at least ten posts live and 200,000 to 250,000 views for a US developer audience, within 14 days, with clicks reported (assumption).
8. Build-out after launch
Nothing on the "out" list in section 2 is skipped forever. Each manual step is automated in turn, once a specific trigger is reached, while the product keeps running live in the meantime.
- AI verification of submissions against the brand's checklist: added once submissions pass about 100 a day, the volume one person can no longer check inside 48 hours.
- Automatic daily view refreshes from each platform's API: added once that platform's read permission is approved, expected 2 to 8 weeks from the application in section 4; this replaces the daily manual reads.
- OAuth social connect and automatic league calculation: added alongside the API read permissions, replacing handles entered by hand.
- Automatic posting through each platform's publishing API: switched on per platform once that platform approves the publishing permission, targeted for Phase 3; creator-posted mode stays as a permanent fallback either way.
- Frame-hash matching and automated label, hashtag and tag checks for link verification: built during the build-out, targeted by 22 January 2027 and well before automatic posting, replacing the founder's manual four checks.
- Native apps: added once the store gates clear, the Google Play closed test finishes or an organisation account's verification completes, and the Apple enrollment and first review pass.
- Razorpay Route: once approved, brand funds move from the entity's own Razorpay account to Route's held, split-settlement structure.
- Bulk payouts to creators outside India: Payoneer India turned out to be receive-only, so this now waits on RazorpayX Global Payouts or a foreign subsidiary with Trolley or Stripe Global Payouts; Karbon or PayPal pay larger balances one at a time and wallets hold the rest in the meantime.
- Referral automation: the $5 reward pays itself once manual lookups become impractical at volume.
- Volume pricing: follows the wider Phase 3 self-serve launch, alongside clipping and, in Phase 4, instant payout and managed campaigns.
Through all of this, the Timeline page keeps the original phase dates, open creator beta on 25 January 2027, self-serve public launch on 29 March 2027, scale from 1 July 2027, as fixed points for how far the build-out should have reached, even though the product itself went live two weeks after the sprint started rather than after the original Phase 0 and Phase 1.
9. Risks specific to the two-week plan
Moving this fast trades the risks of a slow launch for a different, shorter list. Each one has a plain fix built into the plan.
| Risk | Fix |
|---|---|
| The entity or bank account is not ready by 21 September 2026 | Launch anyway with dogfood gigs only, paid from the founder's own account; no brand deposits until the entity and the Razorpay pay-in account are both live |
| Razorpay Route is not approved in time | Collect into the entity's own Razorpay account and pay creators from the entity's bank account through RazorpayX at MVP volumes, with the lawyer's sign-off, moving to Route once it clears. This dated fallback runs as the principal, so GST applies to the full price of those gigs rather than just the platform's 20% cut, until the switch |
| The founder's time is split between reviewing 50 to 100 submissions a day and running everything else | Keep the first pilot brand's campaign small enough that daily submissions stay well under the roughly 100-a-day threshold that triggers automated review; treat review as the first job of the day |
| Creators outside India sign up but cannot be paid yet | Let them keep earning; their wallet holds the Available balance and they are told plainly when payouts open, once a bulk rail open to an Indian payer is confirmed; larger balances go by Karbon or PayPal, one at a time, in the meantime |
| A manually recorded daily view count is disputed | Ask the creator for a screenshot with a visible timestamp to check against the recorded number, and treat a genuine mismatch as an ops review before any money moves (assumption on the screenshot check itself) |
| A blocker such as WhatsApp verification, legal papers, Google Play or Apple review slips past 20 September | None of these sit on the critical path to the first dispatch; WhatsApp falls back to SMS and email, native apps and automatic posting are already build-out work, so a slip delays a later feature rather than the 21 September launch |