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 storyProduct 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
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
Pricing model
Client-funded and bootstrapped; no public standardized pricing was found in the sources used.
Competitors or alternatives
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
Hakeema shows that nonprofit and social-sector buyers may pay, renew, and stay satisfied while each implementation remains shaped by grants, programs, stakeholders, and custom platform needs. Builders need to separate repeatable software from service delivery before treating revenue as SaaS validation.
Primary check
Separate repeatable software from custom client work before treating nonprofit service demand as scalable SaaS demand.
Checklist
- Can the second customer use the same workflow as the first without a custom build?
- How much staff time is required before a nonprofit sees value?
- Is the buyer paying for software access, funded program delivery, or bespoke stakeholder engagement?
- Would the business still work if all custom platform work were priced separately?
- Separate product revenue from custom implementation revenue.
- Track how much each new nonprofit customer changes the product or delivery process.
- Define which parts of the workflow must be self-serve before calling it SaaS.
- Price custom work explicitly instead of hiding it inside product plans.
Relevant if
- You are building software for nonprofits, public-sector teams, education, healthcare, or other implementation-heavy verticals.
- Early customers pay for custom platforms, grant-funded programs, or stakeholder-specific workflows.
- Your retention looks strong, but every deal still requires bespoke setup, content, data, or delivery work.
- You are calling the business SaaS while most value is created through services.
Less relevant if
- Customers can self-serve the same workflow with little configuration.
- Most revenue comes from repeatable product usage rather than custom client delivery.
Pre-build tests
- Deliver the first workflow manually and document which parts repeat across clients.
- Sell the same package to three similar organizations without changing scope.
- Measure onboarding and custom work hours per customer before expanding features.
- Create a fixed implementation menu and reject one custom request to test product boundaries.
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.