Before You Build
Web AppShut Down

Adproval

Adproval combined manual consulting revenue with a funded self-service software path. The founder reported more than $200k from consulting while the software product reached only about $200 per month.

View original story

Product snapshot

What it was

Adproval was a marketplace connecting bloggers and social media influencers with brands for sponsorships and direct ad placements.

Who it was for

bloggerssocial media influencersbrandsadvertisers

Problem / value

It aimed to let creators control brand collaborations while giving advertisers a way to buy sponsorship opportunities.

Core workflow

Creators listed sponsorship inventory, brands bought direct ads or social promotions, and both sides managed collaboration opportunities.

Core dependency

The founder said he first used landing pages, Google Forms, and Google Sheets to fake a two-sided marketplace for market research.

Product form

web marketplacecreator monetization platform

Pricing model

The original platform took commissions on direct ad purchases; later consulting services generated revenue, while self-service software reportedly made about $200 per month.

Competitors or alternatives

influencer marketing agenciesPR agenciescreator marketplacesdirect brand sponsorship outreach

What happened

Summary

The founder said Adproval was a marketplace connecting bloggers and social media influencers with brands.

Outcome

A creator-brand marketplace raised funds and built software, but the founder later said the business moved away from simple revenue-generating services before regular revenue was proven.

Core risk

Marketplace Software Before Revenue

Timeline

  • Founder began with static pages, Google Forms, and spreadsheets for validation.
  • Founder later raised about $300k.
  • Founder reported more than $200k consulting revenue but only about $200/month from self-service software.

Before you build

Why it matters

Indie builders often automate marketplaces too early. Adproval shows why spreadsheet/manual service workflows can be the right path until regular revenue and liquidity are proven.

Primary check

Keep manual sponsorship revenue working and prove repeatable marketplace liquidity before shifting into self-serve software.

Checklist

  • Can you name the first buyer segment and the repeated job they need solved?
  • Can you reach that segment without relying on one fragile channel?
  • What happens if the platform, API, or data source changes terms or blocks access?
  • What evidence would disprove the marketplace software before revenue risk?
  • Keep manual marketplace operations until recurring revenue exists.
  • Do not let self-service purity block a managed service that customers will pay for.
  • Validate the paying side of a marketplace before scaling software complexity.

Relevant if

  • You are building a similar web app with public-source distribution risk.
  • Your product depends on another platform, search channel, API, or third-party data source.
  • You need to validate who will repeatedly pay before investing in product polish.

Less relevant if

  • You already control a reliable acquisition channel for the exact buyer segment.
  • The product is an internal tool with no need for public distribution.

Pre-build tests

  • Run a landing-page or concierge test with the narrowest buyer segment before building the full workflow.
  • Ask users to commit to a paid pilot, not only to join a free waitlist.
  • Prototype the highest-risk platform or data dependency first and document backup options.

Transferable lessons

  • Keep manual marketplace operations until recurring revenue exists.
  • Do not let self-service purity block a managed service that customers will pay for.
  • Validate the paying side of a marketplace before scaling software complexity.