Inwall
Two-sided ad marketplace: advertisers fund a budget and set a price per share, per social network; Inwallers browse a vertical feed and get paid the moment they share. MVP specs — a living document, updated as we work through the Figma design.
Overview
Inwall connects advertisers who want reach on social networks with everyday people who already share things on those networks. Instead of buying impressions from a platform, an advertiser pays per confirmed share, directly to the person who shared.
| Platforms | iOS + Android |
|---|---|
| Mobile stack | Flutter (single codebase) |
| Two sides | Advertiser (campaign console) / Inwaller (vertical feed) |
| Design source | Figma, file "Inwallsept2025", canvas "MVP Flows TO BE USED FOR MVP ONLY" |
Core loop
The whole product is this cycle running on repeat, one ad view at a time.
Fund & split
Advertiser sets a global budget, splits it per social network, sets targeting zones.
Price the share
Fixed payout set per network — e.g. €3 on Facebook, €5 on Instagram.
Scroll & share
Inwaller browses the vertical feed and shares an ad to one of the priced networks.
Get paid
Payout lands, deducted from that network's sub-budget, then the global one.
Campaign setup Advertiser
"Create an ad" is a 3-step flow (Figma frames Budget add budget, ad settings, Your social accounts popularity), tracked by a segmented progress bar at the top of each screen.
Console states to cover: draft campaign, live campaign, paused (a network's sub-budget exhausted), ended.
Budget mechanics
A share deducts from its network's sub-budget first, then from the global budget. When a network's sub-budget hits zero, sharing to that network stops paying out — the ad can still appear, but shares to that network earn nothing until the advertiser tops it up.
| Network | Sub-budget | Price per share |
|---|---|---|
| €450 | €5.00 | |
| €350 | €3.00 | |
| Snapchat | €200 | €2.00 |
Matches the fields on the ad's "Details" tab in Figma: Status (Live, green check), Date, Ad name, Remaining budget ("$300 / $1,000"), Target (gender, location, age, interests), and the price-per-share per network.
Feed & sharing Inwaller
Vertical, full-screen, TikTok-style (Figma frame explore / infinite scroll). Creative fills the screen edge to edge; chrome floats on top of it, same dark tab bar as the rest of the app.
| Element | Behavior |
|---|---|
| Bottom-left pill | Advertiser identity (logo mark + name) over the creative |
| Bottom-right circular button | Share action — reuses the Inwall logomark itself as the share icon |
| Eye icon | View counter for the ad |
| Swipe up/down | Next / previous ad in the feed |
| Tap share | Choose a network, confirm the share, see the payout amount before confirming |
| Network exhausted | That network's payout option is disabled on this ad, others stay active |
Feed states to cover: loading (skeleton), empty feed (no funded ads left for this user's targeting), network error.
Payouts
Earnings and payout history are visible in-app at all times.
Data model (first pass)
To refine with the developer, this is a starting point based on the flows above.
| Entity | Key fields |
|---|---|
Advertiser | id, name, email, kyc_status, created_at |
Inwaller | id, handle, email, wallet_balance, trust_score, created_at |
Campaign | id, advertiser_id, creative_url, global_budget, global_spent, status, zone, created_at |
NetworkAllocation | id, campaign_id, network (facebook/instagram/snapchat/tiktok), sub_budget, sub_spent, price_per_share |
Share | id, inwaller_id, network_allocation_id, network, status (pending/confirmed/rejected), payout_amount, shared_at, verified_at |
WalletTransaction | id, inwaller_id, share_id, amount, type (payout/cashout), created_at |
Screen inventory (Figma)
11 top-level frames on the "MVP Flows TO BE USED FOR MVP ONLY" canvas (node 2413:46122):
logo inwall— app icon / splash markexplore / infinite scroll×3 — the vertical feed (splash/onboarding variant + two feed states)Budget add budget— campaign step 1, budget + price per sharead settings— campaign step 2, creative + targeting + paymentYour social accounts popularity— campaign step 3, advertiser's own follower countssuccess— "Your ad is now live" confirmationFull ad— advertiser dashboard, all campaigns, budget used, impressions, reach, shares by networkAd performance— single-campaign detail, "Ad performance" / "Details" tabsStartup profile / Documents— leftover frame from another project's template, not part of Inwall's flow, hidden in Figma
Design system
Extracted from the real Figma variables on 2026-08-19 (session with the file shared to laura@inwall.app). See the full design system page for colors, type, and components pulled directly from the file, not a provisional palette.
Risks & open questions unresolved
Share verification
No reliable way yet to confirm a share happened and stayed visible. Biggest single point of failure in the model — needs prototyping before the rest of the app.
Third-party API dependency
Facebook, Instagram, Snapchat, and TikTok can restrict or ban this usage pattern at any time. No fallback currently defined if one network cuts access.
Fraud / farming
A flat payout per share is a direct incentive to fake accounts and disposable posts. Needs a trust score gating payout eligibility (see roadmap).
Payout compliance
Paying individuals for posting ad content sits in a legal grey zone (disclosure rules, KYC/AML, tax withholding), and varies by country.
Out of scope for MVP
- Automated real-time reach/engagement measurement beyond confirming the share exists
- Multi-currency payouts (single currency, EUR, at launch)
- Advertiser self-service billing beyond a prepaid budget top-up
- Any network outside Facebook, Instagram, Snapchat, TikTok
V1 roadmap future
- Delayed verification + quality score: confirm a share survives 24–48h before paying the full amount
- Trust score per Inwaller (account age, share survival rate) gating payout rate
- Wallet, KYC, and payout compliance built on Stripe Connect or equivalent from day one
- Native in-feed value (views, interactions, ranking) so Inwall isn't 100% dependent on external share APIs
Decisions made & open questions
Decisions
- Mobile stack: Flutter
- Repo holds specs first, app scaffold to follow once the Flutter SDK is installed locally
- Payout is per confirmed share, priced per network, set by the advertiser
- A network's sub-budget hitting zero disables payouts on that network only, not the whole campaign
- Share verification and third-party API dependency are treated as the top two risks, prototyped first
Open
- Share verification method: which signal counts as "confirmed"?
- Sub-budget race condition at zero: first-confirmed-wins or reserved buffer?
- KYC/payout compliance approach per launch country