Echo Ledger

Echo Ledger helps people avoid overcommitment by projecting the true historical cost of new commitments using their own past behavior. It replaces optimism with evidence, not advice.

Comment 2

Inspiration

I kept overcommitting - saying yes to things that felt doable in the moment, then burning out or dropping off weeks later. I wanted something that didn’t give advice or motivational tips, but showed what actually happened when I’d tried similar things before. Echo Ledger came from that: turn personal history into a simple projection so the next commitment decision is based on evidence, not optimism.

What it does

Echo Ledger gives you a Historical Friction Projection before you start a new commitment. You pick a category (e.g. Learning), enter how much effort you think it’ll take, and it uses your past commitments and reflections to show:

  • Effort reality check — e.g. “You think 5 hrs/week; you usually spent ~7 (+40% overrun).”
  • Consistency risk — e.g. “Typical drop-off: Week 3” so you can plan check-ins.
  • Regret likelihood — how often, in your own data, you reflected that you regretted starting.

No AI, no black box: everything is computed from your logged data with clear, inspectable formulas. The live app has Seed demo data and Clear demo data so judges can run and reset the demo easily.

How I built it

As a solo developer I used Flutter for the web UI and Serverpod 3 for the backend. The client and server share a Dart protocol (commitments, reflections, effort logs, projections), so types and endpoints stay in sync. The backend exposes:

  • A friction projection endpoint that aggregates past commitments by category and user, computes overrun %, drop-off week, and regret likelihood, and returns a structured projection.
  • Seed and Clear demo data endpoints so the hackathon demo has realistic data for User ID 1 / Learning without real auth.

I added a short onboarding flow and a deploy script that runs serverpod generate, flutter build web, and scloud deploy so the app and API stay up to date. The app is hosted on Serverpod’s infrastructure; docs live in DEPLOYMENT.md.

Challenges I ran into

  • Protocol serialization: The projection response referenced RateLimitData, but the client didn’t have a matching class — the web build failed with “No deserialization found for type RateLimitData.” I fixed it by defining RateLimitData in the client and ensuring the protocol/generator knew about it.
  • Auth vs demo: For judging, the app needs to work without sign-in while still being ready for real auth later. I kept auth checks out of the projection path for the hackathon and left a clear “HACKATHON NOTE” in the code describing how to add serverpod_auth and user-scoping for production.
  • Discoverability of Clear demo: The “Clear demo data” control lived only in the app bar and disappeared into the overflow menu on smaller screens. I moved both Clear and Seed into a labeled “Demo:” section in the main body so they’re always visible and obvious.
  • Deploy pipeline: Making sure the Flutter web build and Serverpod generate both ran before scloud deploy, and that the built assets were not ignored, took a few iterations; the script and .scloudignore are documented so redeploys are repeatable.

Accomplishments that I'm proud of

  • End-to-end working product: Live app and API, deterministic projections, demo seed/clear, and a single-command deploy.
  • Transparent logic: Formulas (overrun %, regret likelihood, drop-off week) are spelled out in the README and validated by integration tests; there’s no “the model said so” — you can trace every number to your own data.
  • Serverpod as the backbone: Persistent state and longitudinal analysis aren’t optional — they’re the core of the product. The value of Echo Ledger grows with time and data, and Serverpod is what makes that possible.
  • Hackathon-ready docs: DEPLOYMENT.md, and in-code notes so another developer (or future me) can run, deploy, and judge the project without guessing.

What I learned

  • Deterministic > black box for trust: For “should I take this on?” decisions, users care about why a number looks high or low. Deterministic, documented math beat a generic AI summary for transparency and debuggability.
  • Serverpod’s generated client pays off: Shared Dart types and a single serverpod generate step kept the Flutter app and backend in sync and caught protocol mismatches (like the RateLimitData issue) at build time instead of in production.
  • Demo ergonomics matter: One extra step (“where’s Clear?”) is enough to break a judging run. Putting Clear and Seed side-by-side in the main UI with clear labels made the demo flow smooth.

What's next for Echo Ledger

  • Auth and multi-user: Add serverpod_auth, scope all queries to the signed-in user, and retire the “User ID 1 for demo” escape hatch.
  • Longitudinal features: Recurring re-evaluation (“your friction for Learning is trending up”), category-level summaries, and gentle nudges (e.g. “Week 3 is usually when you drop — add a check-in?”).
  • Optional AI for explanation: Keep projections deterministic, but add an optional layer (e.g. Gemini) to explain patterns in natural language (“You often overestimate by ~40% in Learning; consider adding buffer”).
  • Mobile: Ship a Flutter mobile client reusing the same Serverpod API and protocol so users can log commitments and check projections on the go.

Built With

Share this project:

Updates