← Back to all projects

Case Study — Stamp Mind

Stamp Mind

A cross-platform productivity app spanning Flutter mobile, a native desktop activity tracker (C++/Swift) that reads window metadata, and a Next.js web app — backed by a PostgreSQL schema migrated cleanly from AWS to Supabase.

At a glance

Role
Full-Stack Engineer · 2024 — 2025
What
Cross-Platform Productivity & Goal Tracking App
Did
Shipped across Flutter mobile, native C++/Swift desktop, and Next.js web on one PostgreSQL schema
Stack
FlutterDartTypeScriptNext.jsAWSSupabase

Problem

Existing productivity apps treat task management and self-awareness as separate problems. Users need a single tool that tracks what they're working on and helps them reflect on how they spend their time.


My Role

Built across three platforms end-to-end — Flutter mobile, a native C++/Swift desktop tracker, and a Next.js web app on a shared PostgreSQL backend.


Process

  1. 1

    Conducted user interviews and surveys to validate the problem space and understand how people currently track their time and goals.

  2. 2

    Built a landing page and collected ~100 waitlist signups before writing a single line of product code — validating demand first.

  3. 3

    Recruited 5 pilot users from the waitlist and ran hands-on testing sessions, iterating on the core experience based on real usage patterns.

  4. 4

    Built the mobile app with Flutter/Dart for cross-platform task and goal management with a clean, friction-free daily interface.

  5. 5

    Developed a native desktop activity tracker (C++/Swift) that reads window metadata to automatically log what users work on.

  6. 6

    Initially built the backend on AWS — Amplify for auth, Lambda for serverless functions, RDS PostgreSQL for the database. Noticed costs climbing: the always-on RDS instance was charging even with near-zero traffic. Investigated options — Aurora Serverless for scale-to-zero, smaller instance types, reserved pricing — but concluded that for 5 pilot users, optimizing AWS was itself over-engineering.

  7. 7

    Migrated to Supabase instead. Same PostgreSQL, so the schema carried over cleanly. Auth moved from Amplify to Supabase Auth. The decision wasn't about AWS being bad — it was about matching infrastructure to the current stage. AWS makes sense at scale; Supabase made sense at 5 users.


Outcome

Validated product-market fit through user research before building. Shipped a working cross-platform tool spanning mobile (Flutter), desktop (native C++/Swift), and web (Next.js). Migrated from AWS to Supabase, cutting infrastructure costs to near-zero while keeping the same PostgreSQL schema. Pilot users reported the daily tracking flow took under 30 seconds.


Stack

FlutterDartTypeScriptNext.jsAWSSupabasePostgreSQL

What I Learned

Two lessons. First — I kept adding features to stand out, but pilot users just wanted the core flow to be fast and simple. I removed most of what I'd built. Shipping less was harder and better. Second — infrastructure decisions are product decisions. AWS wasn't wrong, it was wrong for the stage. Knowing when to optimize vs. when to switch is a skill I use in every project now.