Before You Build
English
English中文日本語
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

Ledger was a cloud-cost reminder utility for AWS and GCP users. The pre-build question is whether developers using AWS EC2, developers using GCP, and small teams managing cloud instances have enough urgency, budget, and repeat behavior to support this workflow through a channel you can keep reaching.

Primary check

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

Checklist

  • Who owns the budget for this problem?
  • What repeated event triggers the buyer to use this every week or month?
  • Which channel reliably reaches developers using AWS EC2, developers using GCP, and small teams managing cloud instances without a one-off launch spike?
  • What evidence would show Utility Saas Distribution and Adoption Gap before you build more?
  • Define which segment among developers using AWS EC2, developers using GCP, and small teams managing cloud instances pays first and why the problem is urgent now.
  • Prove the workflow happens often enough to justify buying.
  • Test one acquisition channel for developers using AWS EC2, developers using GCP, and small teams managing cloud instances before relying on launch traffic.
  • Write down why a buyer would switch from AWS CloudWatch alarm actions that can stop or terminate EC2 instances, AWS Budgets alerts and budget actions, and Google Cloud budget alerts.

Relevant if

  • You are building a Slack app for developers using AWS EC2, developers using GCP, and small teams managing cloud instances.
  • The product promise is specific: It aimed to reduce avoidable cloud spend by reminding users to terminate cloud compute instances they no longer needed.
  • You have interest, signups, usage, or founder confidence but have not proven paid repeat use.
  • Your acquisition or product value depends on a platform, search channel, API, or third-party system you do not fully control.

Less relevant if

  • You already have paying developers using AWS EC2, developers using GCP, and small teams managing cloud instances who repeatedly use the workflow and renew or expand usage.
  • The product is an internal tool with a mandated user base and no external go-to-market risk.

Pre-build tests

  • Run the workflow manually for a small group of developers using AWS EC2, developers using GCP, and small teams managing cloud instances.
  • Ask one buyer to pay, renew, or sign a dated pilot before building the next version.
  • Test one non-launch acquisition channel and count qualified conversations, not page views.
  • Put the offer next to AWS CloudWatch alarm actions that can stop or terminate EC2 instances, AWS Budgets alerts and budget actions, and Google Cloud budget alerts and ask what would make the buyer switch now.

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.