Before You Build
Web AppShut Down

Ledger Cloud Reminders

Ledger was a cloud-cost reminder utility for AWS and GCP users. Public cloud-provider documentation shows native budget and alarm mechanisms already cover part of the workflow, raising questions around distribution, habit formation, and differentiation.

View original story

Product snapshot

What it was

Ledger was a Slack reminder tool for terminating EC2 instances, with stated support for GCP as well.

Who it was for

developers using AWS EC2developers using GCPsmall teams managing cloud instances

Problem / value

It aimed to reduce avoidable cloud spend by reminding users to terminate cloud compute instances they no longer needed.

Core workflow

Users received Slack reminders about temporary cloud instances and used them to reduce avoidable infrastructure costs.

Core dependency

Google Cloud documentation describes budget alerts and customized email recipients through Cloud Monitoring notification channels.

Product form

Slack appweb app

Pricing model

The reviewed public source does not disclose pricing data.

Competitors or alternatives

AWS CloudWatch alarm actions that can stop or terminate EC2 instancesAWS Budgets alerts and budget actionsGoogle Cloud budget alertsSlack-based DevOps remindersmanual cloud cleanup processes

What happened

Summary

Ledger reminded users via Slack to terminate EC2 instances and also worked with GCP according to the founder post.

Outcome

The founder wrote that he had decided to shut down the side project.

Core risk

Utility Saas Distribution And Adoption Gap

Timeline

  • Founder publicly said he had decided to shut down the side project on December 2, 2021.
  • Founder said the project had zero users in the Indie Hackers post.
  • Founder considered making the code public rather than deleting it.

Before you build

Why it matters

Many solo builders choose narrow developer utilities because the problem is concrete, but Ledger shows that a clear pain point still needs a channel, installation motivation, and recurring usage.

Primary check

Find teams with recurring cloud-cost pain and a Slack adoption path before investing in a narrow cleanup reminder.

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 utility saas distribution and adoption gap risk?
  • Validate a distribution channel before building small developer utilities.
  • Test whether users will install and keep a reminder workflow in their existing tools.
  • Separate personal pain-point clarity from broader adoption evidence.

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 a distribution channel before building small developer utilities.
  • Test whether users will install and keep a reminder workflow in their existing tools.
  • Separate personal pain-point clarity from broader adoption evidence.