Before You Build
Web AppShut Down

Hakeema

Hakeema found demand and retention in the social-sector market, but implementation-specific nonprofit requirements pushed delivery toward custom platforms and service work instead of scalable SaaS.

View original story

Product snapshot

What it was

Hakeema was a small-team platform for nonprofit marketing, stakeholder engagement, and knowledge-asset communities in the social sector.

Who it was for

nonprofitssocial-sector organizationspublic-sector and expert organizations

Problem / value

Turn cloud docs, knowledge bases, and content marketing into partner and prospect communities.

Core workflow

Teams built partner or prospect communities around knowledge assets, supported stakeholder engagement, and delivered social-sector program platforms.

Core dependency

The founder said nonprofit customers often needed custom platforms tied to grant proposals or funded programs.

Product form

web appcustom client platforms

Pricing model

Client-funded and bootstrapped; no public standardized pricing was found in the sources used.

Competitors or alternatives

custom nonprofit software agenciesnonprofit CRM and stakeholder engagement platformsknowledge-management and content-marketing platforms

What happened

Summary

Hakeema's founder announced that the team decided to shut down after three years building software for the social sector.

Core risk

Service Gravity In Vertical Saas

Timeline

  • LinkedIn lists Hakeema as founded in 2017 with 2-10 employees.
  • The founder reported almost $600k in revenue in 2.5 years.
  • The founder announced Hakeema's shutdown after three years.

Before you build

Why it matters

Bootstrapped founders often treat early revenue as validation, but Hakeema shows the need to test whether paid work repeats as a product or pulls the team into bespoke delivery.

Primary check

Separate repeatable software from custom client work before treating nonprofit service demand as scalable SaaS demand.

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 service gravity in vertical saas risk?
  • Validate repeatability, not only willingness to pay.
  • Vertical markets with grant or program-specific requirements can create custom-service gravity.
  • Strong retention may still be compatible with a business model the team does not want to operate.

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

  • Validate repeatability, not only willingness to pay.
  • Vertical markets with grant or program-specific requirements can create custom-service gravity.
  • Strong retention may still be compatible with a business model the team does not want to operate.