Before You Build
Web AppArchived

SocialKiwi

SocialKiwi was a social media management SaaS that drew build-in-public attention and free users, but the founder reported only one paying customer before selling it for $2,200.

View original story

Product snapshot

What it was

SocialKiwi was a web SaaS for managing social media channels from one product.

Who it was for

social media managerscreators active on X, TikTok, Meta, or similar channelssmall businesses trying to manage social posting

Problem / value

It aimed to give creators, marketers, and small businesses a cleaner social media management workflow than existing tools.

Core workflow

Manage social accounts, connect platform APIs, and replace scattered social media workflows with one cleaner interface.

Product form

web SaaSsocial media management toolAPI-backed scheduling and management product

Pricing model

The post does not disclose subscription pricing. It reports one paying customer, a $100/month X API cost, and a later $2,200 product sale.

Competitors or alternatives

BufferHootsuiteLaterother social media management tools

What happened

Summary

SocialKiwi got public attention and free users, but the founder reported only one paying customer before selling it for $2,200.

Outcome

This is a weak paid-conversion and platform-cost case during the founder-operated phase. Public sources do not disclose the buyer, post-sale outcome, retention, pricing, or MRR.

Core risk

Attention and free users before paid segment proof

Demand signal

SocialKiwi had visible attention and roughly 200 free users, but the founder reported only one paying customer. The disclosed evidence points to weak paid conversion, not a total absence of interest.

Distribution issue

The founder tried Product Hunt, build-in-public posting, Google and Meta ads, cold DMs, and an affiliate program, but did not find a repeatable paid channel. The needed X integration also introduced a $100/month API cost before revenue justified it.

Timeline

  • Around late December 2023, the founder began building SocialKiwi in public after a previous SaaS attempt failed.
  • After about one month of building and API-access work, SocialKiwi launched and reached Product Hunt day rank #15 with 114 upvotes.
  • The founder reported about 40 launch signups, mostly from people who wanted to test the product.
  • After adding X focus, the founder reported roughly 200 free users and 1 paying customer.
  • The founder later sold SocialKiwi for $2,200 instead of shutting it down.

Before you build

Why it matters

SocialKiwi had public attention and free users, but the founder still reported only one paying customer while an important integration carried a $100/month API cost. Builders of social tools need to validate the paid workflow before expanding across platforms.

Primary check

Validate the paying social-media operator and platform costs before treating build-in-public engagement or free users as demand.

Checklist

  • Who pays for this workflow, and how often do they need it?
  • How many paid users are needed to cover API costs and support time?
  • Which launch signals are only attention, not revenue?
  • What feature can be sold before expanding to every social platform?
  • Name the exact buyer segment and the repeated social workflow they will pay for.
  • Ask that segment for paid commitments before building broad platform coverage.
  • Calculate API costs before promising integrations.
  • Separate testers, free users, and paying customers in your launch metrics.

Relevant if

  • You are building a social media tool, creator tool, or API-backed workflow product.
  • Your launch has attention, free users, or build-in-public engagement but little paid conversion.
  • Your roadmap depends on paid platform APIs or expensive third-party integrations.

Less relevant if

  • You already have a narrow paid buyer segment and enough MRR to cover platform costs.
  • Your product can deliver its core value without third-party platform APIs.

Pre-build tests

  • Pre-sell a single social workflow to one buyer segment before building full multi-platform support.
  • Run a manual or lightweight workflow for paying users before buying expensive API access.
  • Test whether free users will convert before adding the next integration.

Transferable lessons

  • Treat build-in-public engagement as discovery, not proof of willingness to pay.
  • Define one paying segment before broadening across multiple social platforms.
  • Price API costs against expected revenue before committing to integrations.
  • Pre-sell one workflow to one buyer type before adding more channels.

If you build this today

Start with one narrow buyer segment and one paid workflow, pre-sell it, and price API costs before expanding across X, Meta, TikTok, or broader social scheduling features.