📄

Web App

Building Montrack: From Personal Problem to Working Product

The story of turning a personal budgeting problem into Montrack — a digital envelope-budgeting app, rebuilt in 2026 through an AI-assisted (vibe coding) workflow and now being validated with real users.

UI/UX DesignResearchWeb AppFull-Stack DevelopmentAI-Assisted CodingFinTechDashboard

TL;DR

Montrack replaces scattered, inconsistent personal budgeting habits — physical envelopes, half-tracked spreadsheets, an app bought out of desperation — with a digital envelope system built around Indonesia's payday-to-payday budgeting cycle. The first version stalled at a Figma prototype in 2023. In 2026, it was rebuilt and shipped solo through an AI-assisted ("vibe coding") workflow — Figma → Builder.io → GitHub → Zed with the opencode agent → Vercel. There's no completed validation data yet — that's the current phase, running through structured interviews and a short survey before any monetization decision gets made.

Role: Solo — problem discovery, product direction, full-stack build
Tools: Figma, Builder.io, GitHub, Zed (opencode agent), Supabase, Vercel
Duration: 2023 Figma prototype (stalled) → rebuilt and shipped 2026
Live Demo: https://app-montrack.vercel.app/demo/home

Context

Montrack started as a personal problem, not a client brief. As a student living off a fixed allowance, finding a budgeting method that actually stuck became a years-long trial-and-error process — one that eventually turned into a real product.

🔧

Current version: Next.js 16 (App Router), Supabase (Auth, Postgres, Storage), deployed on Vercel. Built and rebuilt entirely solo.

This wasn't built for a client or a market first — it was built to solve my own budgeting problem, tested on myself before anyone else.

Problem

None of the available options actually solved the core problem: something simple enough to stick with, structured enough to actually prevent overspending.

🖼️

[PLACEHOLDER IMAGE] — Diagram: the payday-to-payday budgeting cycle and where it typically breaks down

Insights

💡

Physical envelope systems work conceptually, but don't survive contact with a phone-first life — the friction of carrying cash or a notebook kills consistency, not the underlying method.

💡

Budgeting and tracking need to happen in the same system. Split across two separate habits — plan in one place, log in another — one of the two always breaks first.

💡

An app being "good enough" functionally isn't the same as it being right. Interface dissatisfaction was enough to keep searching even after already paying for a working solution.

Pain Points

🚫

Kakeibo journaling — worked, but required carrying a physical notebook everywhere

🚫

Budgeting without tracking — looked organized at the start of the month, fell apart by the middle

🚫

Tracking without budgeting — accurate records, but no real behavior change

🚫

BukuKas — a bookkeeping app built for small businesses, not personal budgeting

🚫

Kelola Uang Pro — paid IDR 25,000 for the premium version. It worked functionally, but the interface never felt right. Also, the features aren’t strong enough

Constraint

Solo builder — no team, no external funding
Budget limited to essentials — just enough for a domain for early-stage development
No formal usability testing infrastructure — validation has to happen through direct interviews and real usage, not a research team. But for beta version, using personal needs and do a problem-demand validation for market test monetization

🎯

Project classification: Solo, self-initiated build — one validated user (myself) first, before any claim about a broader market. Research and success metrics are scoped accordingly, not benchmarked against a mass-market product.

Attempt #1 — The 2023 Case Study

The first real attempt to solve this happened as a formal design case study: a short user survey, a defined problem statement, a persona, and a proposed direction built around habit-formation — nudges, badges, and goal-setting aimed at fighting forgetfulness and impulsive spending.

🚫

The project stopped at the Figma prototype stage. It was never built.

🖼️

[PLACEHOLDER IMAGE] — Screenshot: 2023 Figma case study mockup

2026 — The Pivot

Coming back to the problem in 2026, the direction changed. Instead of a habit-coaching app with gamification, Montrack became a pure digital envelope system — closer to the original amplop/dompet budgeting method, rebuilt for a phone. No nudges, no badges — just kantong (pockets), a budget, and a clear sense of what's left.

The starting requirement was deliberately narrow: solve it for one user first — myself.

🖼️

[PLACEHOLDER IMAGE] — Screenshot: Figma file after redesign for the envelope-system direction

Approach — A Vibe Coding Workflow

The build ran through a chain of AI-assisted tools rather than a single framework:

🖼️

[PLACEHOLDER IMAGE] — Graphic: 6-step tool chain (Figma → Builder.io → Plugin → GitHub → Zed/opencode → Vercel)

Figma, refined — the old case study file was reworked to match the new envelope-system direction
Builder.io — used to translate the design into a working front end
Figma-to-Builder.io plugin — bridged the design file directly into Builder.io's visual editor
Exported to GitHub — the generated code was pushed to a repository as the real codebase

🖼️

[PLACEHOLDER IMAGE] — Screenshot: GitHub repository structure right after export

Zed + the opencode agent — the heaviest lifting happened here: wiring up Supabase, writing Server Actions, fixing what the export didn't get right, and extending features the visual export couldn't handle
Deployed to Vercel — connected for continuous deployment straight from the repository

🖼️

[PLACEHOLDER IMAGE] — Screenshot: Vercel deployment success / live demo URL

⚠️

This wasn't a "type a prompt, get a finished app" process. Several parts needed manual debugging, rewriting, and back-and-forth between the agent and the codebase — that friction is part of the story, not a footnote to it.

Solution

The result is a working envelope-budgeting app, built around a payday-to-payday cycle:

Kantong (Pockets)

Budget categorized into pockets with 3 types — flow (routine), event (one-off), reserve (buffer) — mirroring how envelope budgeting actually gets used, not a generic category list.

🖼️

[PLACEHOLDER IMAGE] — Screenshot: Kantong list & detail view

Transaction Logging

Expense-only by design — no income tracking, because the budget is already fixed at the start of the cycle.

🖼️

[PLACEHOLDER IMAGE] — Screenshot: Add transaction flow

Ringkasan (Summary)

Weekly summary, budget progress, and recommendations — a running answer to "how am I doing this cycle," not just a transaction history.

🖼️

[PLACEHOLDER IMAGE] — Screenshot: Ringkasan / weekly summary view

Market Signal

Beyond the direct problem-demand validation happening with real users — interviews and a survey — there's a second, independent data point worth stating plainly: personal finance and budgeting is a proven-to-sell category for Notion templates, not a hunch.

🌍

International: Personal finance is one of only four Notion template categories that together account for roughly two-thirds of paid sales volume across Gumroad, Etsy, and the official Notion Marketplace. Leading personal-finance template creators report $10,000–$25,000 in monthly revenue; one widely-sold finance tracker template lists over 10,000 customers.

🇮🇩

Indonesia: Notion's own Indonesia Ambassador has confirmed a growing number of Indonesian creators already earn real income selling templates on the official Notion Marketplace — some as a primary income source. Locally, Notion-based finance templates typically sell for Rp50,000–150,000, with better customer loyalty than comparable Canva templates. IDR-localized and Indonesian-language finance templates already exist on the official Marketplace and on local platforms like Tokopedia and Lynk — including listings with problem framing nearly identical to Montrack's own ("a template for people who feel like they don't know where their money went").

⚠️

What this does and doesn't prove: this confirms the category sells — it says nothing about whether Montrack's specific product, pricing, or positioning will. That's exactly what the ongoing problem-demand validation is for. Category evidence lowers the risk of the bet; it doesn't replace product-specific validation.

Result

📌

Montrack is at MVP stage — a working product, built and used daily by its creator for months. The approach here was deliberately product-first: solve the problem for one real user before researching whether it holds for a market. That validation is running now — structured interviews and a short survey — ahead of any decision on monetization.

This case study will be updated as that validation plays out.

Learning

This project pushed the work past pure UI/UX design into owning a full build end-to-end — problem framing, product direction, and shipping something used daily, not just prototyped. The Figma → Builder.io → GitHub → Zed workflow showed where AI-assisted tools genuinely compress time (scaffolding, boilerplate, wiring) and where they don't (judgment calls about what the product should actually do) — that gap is exactly where the manual work in Zed happened.

Live demo: https://app-montrack.vercel.app/demo/home

Next Portfolio

Web Design for Ngetikapasaja

A freelance project for Ngetikapasaja, where I translated the client's content brief into a structured visual design — building the design system, page layouts, and a more professional, trustworthy website experience.

See Full Story →