External dependencies and services

The two-week MVP is a web app run mostly by hand: ops enters creator handles, reads views and reviews submissions itself, so almost none of the outside services this page describes are needed to dispatch the first gig on 21 September 2026. What is needed at MVP is an Indian entity and bank account, a payments partner, notifications, storage for uploads and the legal documents. Everything else, the four social platform APIs, native apps, automated AI review, is build-out work that starts in the background from day one but does not block launch. This page lists every outside service the product depends on, what we need from it, whether it is needed by the MVP or the build-out, and what happens if it is late.

Draft v0.1 · Last updated 19 September 2026

On this page

1. 1. Overview
2. 2. Social platform APIs
3. 3. Payments partner
4. 4. Notifications
5. 5. Media pipeline
6. 6. AI review
7. 7. App stores
8. 8. Auth
9. 9. Data and monitoring
10. 10. Accounting and tax
11. 11. Legal documents
12. 12. Critical path and lead times
13. 13. How we choose vendors

1. Overview

A dependency is a service, account or document we do not build ourselves and cannot run without. The founder wants the MVP live two weeks from 4 September 2026: the MVP sprint runs 7 to 20 September 2026 and the first real gig is dispatched on 21 September 2026, with everything in the longer plan still happening afterwards as build-out while the product is already live (21 September 2026 to 22 January 2027). That timing changes which dependencies matter now. Only a short list is on the two-week critical path: the Indian entity and its bank account, GST registration, the Razorpay pay-in and payout rails, notifications (SMS, email and web push), object storage for uploads, the ops console, and the legal documents. The two app stores are applied for from day one but are build-out work, not launch blockers, since the MVP is a web app.

Fraud and pay integrity (section 49 item 5 of the brief) is a core system, not an optional extra, so post checks, fraud detection and measurement are core dependencies from the first gig: reading a platform's own view count, reading a creator's audience geography from their insights screen, and counting clicks on a tracked link are all needed for every gig from day one. What changes between MVP and the build-out is only how each is done, not whether it is done. At MVP, this work runs by hand: the creator uploads a screenshot of their platform's audience insights screen so ops can read their audience geography (the tier of country most of their audience is in, which the CPM formula uses); ops reads or receives a screenshot of the public view count on day 3, day 7 and day 14; and the redirect service (below) counts clicks on the tracked link automatically from day one, since that one piece does not depend on a platform API at all. In the build-out, the same three checks move onto the platform APIs: audience geography is read from the API's own insights data instead of a screenshot, and view reads move from manual to automatic. The four social platform APIs are applied for from day one of the MVP sprint for this reason, even though a slow approval does not block the first gig.

Words on this page follow the Product spec. A brand pays; a creator makes and posts the video. A campaign is a brief, a 10-item checklist, a fund (the money deposited) and settings. A gig is one video by one creator inside a campaign. An offer is a gig notification the creator can accept or decline; dispatch is sending offers. A creator is paid a CPM (a rate per 1,000 real views) set by their audience geography, the platform, the campaign category and their league (see Rate cards); a floor of 20% of expected earnings releases into the creator's wallet at publish, and the rest follows the day 3, day 7 and day 14 view reads, up to the maximum payout of expected earnings unless the brand has switched on an optional bonus; a payout moves wallet money to the bank or payout method on the 1st of each month. Ops is our own operations function, which at MVP and until the hire triggers on the Rollout plan are crossed means the founder alone.

Dates: the MVP sprint runs 7 to 20 September 2026 (10 working days); the first gig is dispatched 21 September 2026; the build-out runs from 21 September 2026 to 22 January 2027, while the product is live; the open creator beta (worldwide) starts 25 January 2027; the public launch starts 29 March 2027. The first payout run is 1 October 2026.

2. Social platform APIs

An API (application programming interface) is a way for one piece of software to talk to another. OAuth is the standard way a person lets an app act on their account: the creator signs in on the platform's own page, sees the permissions we ask for, and taps Allow. The platform gives us an access token, a secret string that stands in for that permission. We never see the password.

The API connection itself is not needed for the MVP; the checks it will automate are needed from the first gig. At MVP a creator simply types in their handle for each platform they use; there is no OAuth and no connected account. Ops looks at the creator's last 10 posts on that handle and sets their league by hand from the median views (brief section 28, item 3), and reads the creator's audience geography by hand from a screenshot of the platform's audience insights, to set the audience tier the CPM formula uses; there is no city or creator-location input anywhere in this, since the CPM formula and the density rule both run on the audience's geography and league, not on where the creator lives. Once a post is live, ops reads the public view count on day 3, day 7 and day 14, or the creator sends a screenshot on those days, and records it; earnings release from the recorded number (brief section 28, item 7). Applications for read permissions still go in for all four platforms from day one of the MVP sprint, because the build-out replaces this manual work with API reads once each platform approves us, but a slow or refused application no longer delays the first gig, since the post checks and measurement work itself is already running by hand. Publishing permissions, which would let the platform post on the creator's behalf, are also applied for now but are further out still: the creator posts the approved package themselves at MVP and for as long as automatic posting is not yet switched on, targeted for after the beta.

What we will still need from each platform once the build-out replaces manual handles and manual view reads splits into two kinds of permission: read permissions, and publishing permissions, needed only once automatic posting is switched on for that platform.

Read permissions (build-out target):

• Sign-in through OAuth, asking only for the scopes (permission types) we use: read profile and posts, and read statistics.
• Read profile, posts and account age. Follower or subscriber count is not needed. What we read is the public posts of the last 90 days and their view counts, for the eligibility check (a median of 5,000 views per post over 90 days, 10 public posts in 90 days, account 90 days old), for the creator's league, and for expected earnings: the creator's median views per post over 90 days times their CPM (set by audience geography, platform, category and league), calculated at dispatch and shown in the offer along with the CPM and the maximum payout. Audience geography, which tier of country most of a creator's audience is in, is read from the platform's audience insights, by hand from a screenshot at MVP, and stored against the connected account.
• Read the post's view count on day 3, day 7 and day 14 of the 14-day window, using the platform's own view metric, never impressions, so earnings to date can be worked out and released. This works whether the post was published through our API or by the creator themselves, as long as we can read it back. Bot traffic can run 20% to 30% of views in Tier 3 and Tier 4 markets, so reading only the platform's own view count, rather than a third-party number, matters more for those audiences.
• Refresh tokens before they expire, so the creator does not sign in again for every gig.
• Disconnect: revoke the token when the creator removes the account. Active gigs must finish first.

Publishing permissions (needed only for automatic posting, further out in the build-out, switched on per platform once approved):

• Publish a video with a caption on the creator's behalf and get back the post ID and URL. At MVP, and for as long as this permission is not yet approved, the creator does this step themselves: they post the approved package (section 6) and paste the link, and ops verifies it by hand rather than reading it back through the API.

Once automatic posting is switched on for a platform, if publishing through its API fails, the posting job retries every 15 minutes for up to 6 hours. If it still has not succeeded after 6 hours, ops and the creator are alerted. The gig's deadline is not affected and the creator is not penalised for a posting failure that is not their fault.

All four platforms have a gate before an app may publish on real accounts; none of them gate reading in the same way. The publishing gates are applied for in the MVP sprint alongside the read permissions and take 2 to 8 weeks, but they only matter for switching on automatic posting later in the build-out, not for launch. The read permissions are useful for the build-out but sit off the MVP critical path entirely. The sprint also includes a posting spike against each API when time allows: a small working test that signs in, reads views and posts a private test video, which is what we show the reviewers for both kinds of permission.

2.1 Instagram (Reels)

Instagram's API only works with professional accounts, of type Creator or Business. A personal account is shown how to switch inside Instagram and connect again, once the build-out replaces manual handle entry with a connected account.

We ask for two permissions once we apply: insights (read views and recent posts) and content publishing (post a Reel with a caption). Both need Meta App Review, where Meta staff check what our app does with each permission, using a working app and a screen recording; verify against current documentation. Until content publishing passes, that permission only works for test accounts with a role on our app; this does not block the MVP, since creators post themselves and ops verifies by hand throughout the sprint and beyond, until automatic posting is switched on. Insights passing matters for the build-out, when it replaces ops reading view counts by hand.

Without the content publishing permission, a creator posts the approved package themselves from the Instagram app, adding the caption, "#ad" and the paid partnership label as instructed, and pastes the link; ops checks the post is live and matches the approved file by hand. This is the MVP flow, not a stop-gap: it still matches the post-check difference described on the Competitors page, since the platform checks the live post against the approved file, even while that check is done by a person rather than automatically.

The publishing limit is 100 API posts per account per 24 hours, which applies once automatic posting is on. A creator can have at most 3 active gigs, so this only matters if they also post through other tools.

Tokens expire after a set period and must be refreshed before then; verify against current documentation. Once the build-out connects accounts, a background job refreshes tokens close to expiry. If a refresh fails, for example because the creator changed their password or removed our app, the account is marked "reconnect needed", offers for that platform stop, and the creator is asked to connect again.

2.2 YouTube (Shorts)

A Short is a vertical YouTube video; YouTube decides from orientation and length, so the exact rule must be verified against current documentation. Checklist item 4 (vertical; 20 to 60 seconds for Preset A) is meant to fall inside it.

Reading, once applied for, will give us the YouTube Analytics API for view counts, and public channel and video data for posts and account age for eligibility and league calculation, once the build-out replaces manual entry. YouTube also gives public view counts on a video without needing the creator's connected account, which is a useful cross-check for the manual process at MVP as well.

Uploading through our app is needed only for automatic posting, further out in the build-out. Upload would go through the YouTube Data API v3 with OAuth. Before videos uploaded by our app can be public, Google requires the app to pass its API compliance audit, a check that we follow the API terms; until then, uploads made by our app are locked private. This does not affect the MVP: the creator uploads the approved package themselves from the YouTube app, adding the caption, "#ad" and the platform's paid-promotion label as instructed, and pastes the link; ops verifies it and reads views by hand, or later through the Analytics API once approved.

The Data API gives each app a daily allowance of quota units, and each request costs units. This matters once automatic posting is on, not before. We request a quota increase during the sprint with an estimate of uploads per day for later use; the unit costs and process must be verified against current documentation.

2.3 TikTok

Reading, once applied for and approved, comes through the TikTok Display API or the video query endpoint; verify against current documentation. At MVP, ops reads TikTok view counts by hand the same way as the other platforms.

TikTok's Content Posting API has a direct post mode: our server sends the video and caption and TikTok publishes on the creator's account without the creator opening TikTok. This is needed only for automatic posting, in the build-out. Before an app can post publicly it must pass TikTok's audit; until then its posts are private, visible only to the creator. This does not affect the MVP: the creator posts the approved package themselves from the TikTok app, with the caption, "#ad" and TikTok's own paid-partnership label (the branded-content disclosure toggle) turned on as instructed, and pastes the link for ops to verify and read views by hand.

Once automatic posting is on, the API supports a branded-content disclosure toggle that sets TikTok's own paid-partnership label. We always set it, together with "#ad" in the caption (checklist item 10). At MVP the creator turns this toggle on themselves, following the instructions in the approved package.

2.4 X

On X the same video is posted as a video post with the caption as the text. At MVP ops reads post views by hand; X also gives public view counts on a post without needing a connected account, which is a useful cross-check.

Posting through the API, needed only for automatic posting in the build-out, uses the X API v2: a media upload endpoint that accepts the video in chunks, and a post creation endpoint that attaches it; verify against current documentation. At MVP the creator posts the approved package themselves on X, with the caption as the text and the disclosure included as instructed, and pastes the link for ops to verify and read metrics by hand.

Access to the X API is paid, for reading metrics as much as for posting. It is sold in tiers, billed monthly, and each tier sets rate limits per app, not per creator. Because reading and posting through the API are both build-out work, paying for a tier is not on the MVP critical path; it is decided once the build-out schedule for API reads is set.

Video length limits on X depend on the creator's account type. Item 4 keeps videos short, 20 to 60 seconds for Preset A; ops checks the creator's account type by hand at MVP and warns them before they submit; verify against current documentation.

2.5 Summary

Instagram and TikTok captions do not carry a clickable link, so on those two platforms the creator relies on "link in bio" plus the campaign's promo code; YouTube descriptions and X post text can carry the link itself. This is why every campaign gets both a tracked short link and an optional promo code (Product spec), regardless of which platform the gig is on.

3. Payments partner

Distribution Club is an Indian entity, so the fund and payout rails run on Indian payment products, not the global marketplace product named earlier in the brief. In short: Razorpay collects brand payments (cards, UPI and net banking, with international cards after enablement), with Cashfree as the alternative; Razorpay Route holds and splits the creator pool (the 80% of each deposit that is not the platform's own revenue) and is launch-critical, since it is what keeps Distribution Club a marketplace with GST on its 20% cut only rather than the principal with GST on the whole price (Payments), with a dated fallback of collecting into the entity's own Razorpay account and paying through RazorpayX at MVP volumes, with the lawyer's sign-off, until Route is approved; RazorpayX or Cashfree Payouts pay Indian creators by UPI or bank on the 1st, with TDS deducted as the chartered accountant confirms; and Payoneer Mass Payouts, with PayPal as a second candidate, pays creators outside India once the entity's eligibility as a payer is confirmed, with a creator's wallet holding the balance until then. A merchant-of-record service such as Dodo Payments cannot carry any of this brand-to-creator flow; brands never pay a subscription to Distribution Club, so it has no other role either. GST at 18% applies to the platform's 20% cut on gigs sold to Indian brands, taken at deposit, and the cut on gigs sold to brands outside India can be zero-rated as an export under a Letter of Undertaking, to be confirmed by the chartered accountant.

The full reasoning, the fee table, the tax explanation and the two-week checklist for getting every rail working are on the Payments page; this page only lists what the payments partner must do and when it is needed. The fund a brand deposits is never held in Distribution Club's own operating account, matching the ledger design on Payments.

Order of work: the Razorpay pay-in account and the Route application start on 7 September 2026, alongside GST registration; RazorpayX or Cashfree Payouts KYC runs in parallel so Indian creators can be paid by the first payout run on 1 October 2026; Payoneer's sales-led onboarding also starts in the sprint but is not expected to finish inside it, so creators outside India earn into their wallet until it or PayPal is confirmed and live.

Before the ledger is relied on for real money, the sprint validates the whole payment flow end to end with one real small transfer, not a sandbox test: a brand pays through Cashfree or Razorpay, funds are held (Route or the RazorpayX fallback), one creator is paid through RazorpayX, and one creator abroad is paid through Payoneer if it is already available (assumption, brief section 49 item 7). See the MVP in two weeks page for where this sits in the day-by-day build.

4. Notifications

An offer expires 30 minutes after it is sent (15 minutes for rush dispatch). If the notification arrives late, the creator misses the gig, the slot goes to someone else, and their responsiveness score falls for an offer they never saw. Delivery speed matters more here than in most apps. Time zones matter too: a creator's availability windows are set in their own local time, so a message sent at 3 pm in New York can be the middle of a creator's evening window in India, and it must still land within the notification rules below.

At MVP, offers go out by SMS and email with an accept link, plus web push where the browser allows it, since the product is a web app installable to the home screen rather than a native app (brief section 28, items 1 and 4). WhatsApp Business API is added once Meta's business verification clears; verification can take 1 to 2 weeks and the API itself activates 1 to 3 days after that through a business solution provider, so SMS and email are the day-one channels and WhatsApp is added as soon as it is approved (assumption). Native push through Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM) waits for native apps in the build-out; web push covers the same purpose at MVP wherever the browser and device support it, which should be verified against current documentation since support varies.

SMS gateway, for example MSG91, Twilio or similar: the one-time passcode (OTP) at creator sign-in, and the offer channel from day one. Sender registration with carriers takes time and starts on 7 September 2026; verify against current documentation.

Delivery rules for an offer:

1. The offer goes by SMS, email and web push (where available) the moment the dispatch wave runs.
2. An "offer expiring" reminder is sent 5 minutes before the offer expires.
3. For rush dispatch, where the offer expires after 15 minutes instead of 30, the expiry reminder moves earlier in proportion (assumption).
4. Once WhatsApp Business API is approved, it becomes an additional channel alongside SMS and email rather than a replacement for either (assumption).
5. Once the offer expires or the slot is filled, nothing more is sent for it.

Wave 1 sends at least 2 offers per slot, up to 6 depending on that category and league's acceptance rate, so at least half of those creators do not win in the ordinary case.

Transactional email, for example Postmark or SendGrid, is for brands and creators alike at MVP: magic links, deposit receipts, brand-safety result, campaign live, first post live, and offer accept links. The sending domain must be set up so mail providers can confirm it is ours; verify against current documentation.

5. Media pipeline

Every gig produces one video of up to 500 MB, MP4 or MOV, uploaded from a phone through the web app. Storage has a small per-gig cost; verify current pricing against current documentation.

Object storage, provided by our cloud hosting, keeps each upload in a private location served only through short-lived signed links to the ops console.

Upload with resume: the app checks format, length and orientation on the device, then uploads in parts. If the connection drops, the upload continues from the last completed part. Creators may replace the upload until they tap Submit.

At MVP the founder watches the original upload directly to work through the checklist form; there is no automated transcoding or key-frame extraction step in the two-week sprint, since those exist to feed automatic posting and AI review, both build-out work (section 6). Transcoding to each platform's exact format, and key frames for AI review, are added once that work starts; this can use an open-source tool, for example ffmpeg, or a managed service.

Retention: video originals are kept for 180 days after the gig completes, then deleted. The post ID, URL and view snapshots are kept after that. The post must stay live 90 days and disputes can follow, so 180 days gives a margin. A deleted creator account has its files removed within the 30-day privacy window regardless.

6. AI review

At MVP the founder reviews every submission by hand against the 10-item checklist, as a form: pass or fail per item, with a reason recorded for each failure, and a decision within 48 hours (brief section 29). At 50 to 100 submissions a day, this is founder time, not automated scoring. The Business model page holds review cost at $1.00 per gig in every phase, a founder decision made on 4 September 2026; at MVP that dollar is the founder's own time, not cash spent on a vendor, and it stays $1.00 even once automated scoring and a hired reviewer take over most of the work.

Automated checklist scoring is build-out work, added once submission volume passes what the founder can review inside 48 hours, roughly 100 a day or about 3,000 a month (brief section 29). When it is built, the plan is the same shape described earlier in this spec: speech-to-text, for example Deepgram or AssemblyAI, turns the audio into a transcript for items that need spoken or written content; a multimodal language model, for example the model APIs from Anthropic or OpenAI, reads text and images together and returns pass, fail or unsure for each item with a one-line reason; and perceptual hashing, for example the open-source pHash library, checks for duplicate or recycled video across submissions and matches a posted link against the approved file. None of this exists at MVP. The founder's manual review is the whole review pipeline until the build-out replaces the heavy lifting, with a human still confirming the result.

Fraud and pay integrity is a core system, not an optional add-on to review: a view is simply what the platform's own API reports for the post, and nothing else is counted, but the checks behind pay still run from the first gig, whether by hand or by tool, to decide whether pay is withheld or clawed back: perceptual hashing against the platform's own library and the wider web, not just against our own earlier uploads, flags recycled or duplicate content; anomaly rules compare each post's view velocity, follower and view ratio, and audience geography against the creator's own normal range and insights; and device and account fingerprinting flags several creator profiles sharing one device or one payout account (brief section 49 item 5). Automating these three checks is build-out work, on the same timeline as automated checklist scoring, replacing the by-hand sampling described in section 9. At MVP none of the automation runs yet, but the check itself already does: ops checks by hand every post with a velocity or geography anomaly, plus a 10% random sample, with a larger sample for Tier 3 and Tier 4 audiences, where bot traffic is estimated at 20% to 30% of views (assumption). See the Challenges page for the full detail.

Data handled during manual review at MVP stays inside the product: the founder watches the original upload and reads the caption directly, rather than sending key frames, audio or captions to an outside AI service. Once automated scoring is built, the same data-minimisation rule applies as before: key frames, audio, caption, brief text and checklist items go to the AI vendor under a gig ID; the creator's name, phone, city, bank or tax details, balance or score do not.

7. App stores

The two-week MVP is a web app: mobile web, installable to the home screen, not a native app (brief section 28, item 1). Neither app store is on the MVP critical path, but both accounts should be applied for from day one because of how long each takes:

• Google Play. A personal developer account must run a closed test with 12 testers for 14 days before the app can go to production. An organisation account skips that rule but needs a D-U-N-S number (a business identifier) and verification, about 1 to 2 weeks. Either can be started now; the Android app itself lands in the build-out.
• Apple. Developer Program enrollment takes 1 to 3 days for an individual and 3 to 10 days for an organisation, then the first review takes 2 to 5 days, with about 40% of first submissions rejected (verify against current documentation). Start enrollment now; the iOS app lands in the build-out.

Reason these do not fit the two-week window: even the faster Google Play organisation path (1 to 2 weeks of verification) and the faster Apple path (a few days of enrollment plus a few days of review) do not comfortably clear inside a 10-working-day sprint that also has to build the product itself, and Google's 14-day closed test for a personal account does not fit at all. Once native apps are built in the build-out, the same reviewer questions apply as before: money paid for real-world work through a payments partner rather than in-app purchase, user content moderation, and account deletion within 30 days. Sign-in with Apple, which Apple requires once Google sign-in is offered, is only needed once a native iOS app exists (section 8); it is not part of the web app at MVP.

8. Auth

Authentication (auth) is how the product knows who is using it.

Creators at MVP: Google sign-in or a phone number with a one-time passcode (OTP) by SMS, the creator's choice (brief section 28, item 2). There is no Apple sign-in at MVP; Apple only requires it inside a native iOS app, so it waits until the build-out ships one. Google uses standard OAuth sign-in, so no password is created or stored by us for that path. For the phone path, the 6-digit code expires after 10 minutes and 5 wrong attempts lock the number for 1 hour (assumption). The web app keeps a session for 90 days of use, refreshed silently (assumption).

Brands: Google sign-in, or a work email and password, plus a magic link, an email containing a one-time sign-in link, as a passwordless alternative for either method. Web sessions expire after 30 days without use (assumption).

Ops console: email, password and a second step, a code from an authenticator app, at every sign-in (assumption). At MVP the founder holds the reviewer role directly; roles such as fraud, finance and admin are added only once the hire triggers on the Rollout plan are crossed (assumption).

Social handles at MVP are typed in by the creator, not connected through OAuth, so there are no social tokens to request, encrypt or revoke until the build-out adds account linking (section 2). Auth for sign-in itself can be built in-house or bought, for example from Auth0 or Clerk; the decision is made during the sprint. Google sign-in depends only on that provider being reachable; the phone OTP path depends on the SMS gateway.

9. Data and monitoring

Relational database, for example PostgreSQL: the system of record for creators, brands, campaigns, gigs, offers, submissions, posts, views, wallets and the ledger, real and double-entry from day one because money is the part that must never be approximate (brief section 28, item 8). Backups: daily full backup plus continuous point-in-time recovery, with a restore test once a month (assumption). Data is encrypted at rest.

Cache and job queue, for example Redis: a cache holds often-read data in memory; a job queue runs work in the background at the right time. Several rules in the spec are jobs even at MVP:

• Dispatch waves: send wave 1 only to creators inside their own time zone's availability windows, with a wave size of 2 to 6 offers per open slot that adapts to that category and league's recent acceptance rate (2 until there is enough data), run a 30-minute timer per offer (15 for rush), expire, send the next wave, stop at 48 hours and tell the brand.
• Fraud hold: Pending to Available after 48 hours, or a flag for ops within 3 business days. At MVP the flag comes from a person checking anomalies and a random sample by hand (section 6); the build-out replaces that with the fraud-check tooling described in section 6, perceptual hashing, anomaly rules and fingerprinting, running as a job each time a view read completes.
• Payout batch on the 1st: every Available balance of at least $20 or the equivalent.
• The SMS and email fallback, deadline expiry with re-dispatch, and the 90-day live check.

If the queue falls behind, offers arrive late and earnings release late, so queue lag is watched as closely as uptime.

Product analytics, for example Mixpanel or Amplitude, receives events under IDs only, never names or phone numbers. Error tracking, for example Sentry, groups every app crash and server error. Uptime monitoring checks the web app, brand dashboard and ops console from outside and pages the founder. All of it runs on cloud hosting; no provider is named in this spec.

Redirect service: a tiny Worker on the platform's own short domain, for example go.distribution.club, that looks up a campaign's tracked short link, records a ClickEvent (link, time, and the post if it can tell which one), and forwards the visitor to the destination link in under a second. It needs a small table for TrackedLink records (short code, destination, promo code) and a table for ClickEvent records; both can live in the relational database above. This is needed at MVP, because the Clicks number on the brand dashboard depends on it (Product spec); verify the redirect domain is registered and pointed at the Worker before the first dispatch.

Conversion tracking, a pixel placed on the brand's site or a postback call from the brand's app, is not part of the two-week MVP; it is a Phase 3 addition (assumption). Once it exists, a brand's dashboard adds sign-ups and purchases to the Clicks number already tracked at MVP, and cost per conversion alongside cost per 1,000 views and cost per click. Until then, MVP and the build-out report only posts, views and clicks from the tracked link and promo code redemptions.

10. Accounting and tax

Invoicing and accounting software, for example QuickBooks or Xero, or a similar Indian equivalent the accountant prefers. Each deposit produces a receipt for the amount paid and any GST. Revenue is the platform's 20% cut of the deposit, recognised at once, the moment the deposit lands, not when creator earnings release; the other 80% is a liability (the creator pool) until it is paid out or spent on a later campaign. The accountant sets this up during the MVP sprint.

GST (Goods and Services Tax) at 18% applies to the platform's own 20% cut on a gig sold to an Indian brand, taken at deposit; the cut on a gig sold to a brand outside India is an export of services and can be zero-rated under a Letter of Undertaking, to be confirmed by the chartered accountant (brief section 30). This replaces the earlier US sales-tax mention in this spec, which is removed: sales tax would only apply if a US entity is created later, which is not part of the two-week plan. GST is added to the platform's 20% cut charged to the brand, as the Business model page describes. There is no subscription, so a merchant-of-record service has no role at all; it never covers GST on the platform's 20% cut, which the platform itself must account for and pay (see Payments).

Running a marketplace that collects payment on behalf of creators also makes Distribution Club an e-commerce operator under GST law, a registration separate from the GST registration for its own fee, to be confirmed by the chartered accountant. That registration is what lets the platform collect TCS (tax collected at source) at 1% on the net value of creators' supplies made through the platform under Section 52, filed monthly, on top of the platform's own GST filing. Most creators sit below the 20 lakh rupee turnover threshold and, under the notification exempting service providers below that threshold, do not need to register for GST themselves even while selling through the platform; the platform asks for a GST number only from a creator who already has one. See Payments for the full picture, including why this depends on the marketplace model rather than the platform being the principal.

TDS (tax deducted at source) on payouts to Indian creators, most likely under Section 194-O, is confirmed by the chartered accountant and applied by RazorpayX or Cashfree Payouts before each payout. Any tax reporting Payoneer or PayPal carries out on their own behalf for creators paid abroad is that partner's own process, not something the platform files directly, and is confirmed with the accountant as international creators sign up (assumption). Year-end company filings go through the accountant and the accounting software.

Monthly reconciliation, after each payout run on the 1st, compares the ledger with the payments partner's statement:

1. Money held at the partner equals the creator pool: Pending and Available creator balances plus unspent fund balance. The platform's 20% cut has already moved to the platform's own account at deposit and is never held by the partner.
2. Payouts sent equal wallet movements to Paid for that run.
3. Fees moved to our account equal 20% of that month's deposits, taken at deposit, not 20% of money released.

Any difference is explained before the next payout run (assumption).

11. Legal documents

Five documents, drafted by the lawyer during the MVP sprint, reviewed by the founder, and in force before the first dispatch on 21 September 2026 (brief section 28). A lawyer can adapt standard templates in about a week (assumption). They are reviewed again before the public launch on 29 March 2027.

Terms of service

One set of terms for the platform, accepted by creators in the web app and brands on the dashboard. Both sides contract with Distribution Club, never with each other.

Privacy policy

What we collect (phone, name, city, handles, videos, views), why, who processes it (payments partner, analytics), retention, and the 30-day deletion rule.

Creator agreement

Independent contractor status; the accepted offer plus brief as the written statement of work; the 90-day live rule; CPM, floor, maximum payout and payout terms; no clawback unless fraud is proven; the duty not to remove the disclosure.

Brand agreement

The fund and the all-in price per gig; that deposits are not refunded and unspent balance carries to future campaigns; the brand-safety check and prohibited categories; that the platform reviews content unless brand approval is on; what the brand may do with a post; no claim on the creator outside the platform.

Disclosure policy

One automatic disclosure standard: "#ad" plus the platform's paid-partnership or branded-content label, added automatically and never removed, with honest opinions required. This satisfies the main disclosure regimes, including India's ASCI guidelines, while the lawyer keeps a per-country wording checklist as the product grows beyond India.

Two more legal items are not ours to draft: each platform's developer terms, accepted once developer apps are created during the build-out, and the payments partner's contract with Razorpay, reviewed with the money-transmission question on the Payments page.

12. Critical path and lead times

The critical path is the chain where any delay pushes back the first gig on 21 September 2026. Every item starts on 7 September 2026 and should be verified against current documentation, since lead times change (brief section 28).

The arithmetic: the sprint is only 10 working days, so the entity and bank account, being the slowest item at 7 to 15 working days, is the one to watch first; everything else that touches money (GST, Razorpay, RazorpayX or Cashfree, the accountant's sign-off) can only complete once the entity exists. If incorporation is not finished before 21 September 2026, the first gigs are dogfood gigs paid from the founder's own account rather than brand-funded ones (assumption). Razorpay Route's 1 to 2 week approval window can also run past the sprint, which is why the RazorpayX fallback exists (see Payments). Everything else on this table, the app stores and the platform APIs, runs in parallel in the background and affects only the build-out timeline, not the first gig.

13. How we choose vendors

Wherever we have a choice, the same criteria apply, and a vendor that misses one is not chosen:

• Coverage for the Indian entity first: full support for Indian bank accounts, UPI, GST and TDS, since that is what the MVP runs on, with worldwide reach as the product grows into the build-out and the beta.
• Documented limits: rate limits, quotas, file sizes and retention written down, so we design to them and re-verify them before each release.
• Sandbox: a test environment where no real money moves, no real post is made and no real SMS is sent, so automated tests run end to end.
• Webhooks: the vendor tells us when something happens instead of us asking. Views are the exception at MVP, since ops reads them by hand, and platform polling is the exception once the build-out adds API reads.
• Exportable data: everything stored with the vendor can be downloaded in a standard format, so switching is possible.
• Price that scales with volume: little or no fixed cost while volume is small, and per-use pricing that still makes sense as gigs scale.
• No lock-in of creator relationships: connections, scores, wallets and history live in our database, and a creator never needs an account with the vendor to be paid.

Each chosen vendor is recorded in an internal register with its contract, the limits we depend on, and the date those limits were last verified against current documentation. The Challenges page covers what happens when a platform or vendor changes the rules after launch.