WalletIQ

The problem

Financial tools can record transactions accurately and still leave the user unsure what to do next. A balance shows what is available and a transaction history shows where money went, but neither necessarily explains whether spending is on track, which obligations are approaching, or how recent activity changes the decisions someone can make today.

I built WalletIQ around a different idea: financial data becomes more useful when it is organized around decisions. The goal was not to create another ledger or pack more information into a dashboard. It was to surface the financial signals that matter most and make them easier to understand and act on.

My role

I founded and built WalletIQ from concept through deployment. I defined the product vision, requirements, and MVP roadmap, then made decisions across information architecture, user flows, visual hierarchy, financial logic, data structure, feature scope, testing, and iteration. I managed the database schema, authentication, production issues, deployments, and releases using PostgreSQL, Supabase, React, GitHub, and Vercel.

I used AI assisted development to accelerate implementation while maintaining ownership of architecture decisions, feature acceptance, testing, and product quality.

Key product decisions

• Financial intelligence over raw tracking. The product is designed to explain financial activity, not simply record it. Every major screen should help answer a question or support a decision.
• Spending clarity over abstract budgeting. I prioritized making available spending easy to understand instead of building a complicated system of budgets and configuration options.
• Calendar context. Transactions and fixed costs are connected to dates so users can understand when financial activity occurs, not just how much occurred.
• Manual category control. Users can change and create categories instead of trusting opaque automatic labeling.
• A real interactive demo. Visitors can use WalletIQ rather than relying on screenshots alone. The demo uses fictional data and does not require an account or private financial information.
• Deliberate scope reduction. Plaid integration, CSV upload, and other proposed features were removed from the MVP so I could concentrate on making the core experience coherent and reliable.

What changed during iteration

The earliest version looked more like a traditional budget tracker. As I continued using and testing it, I found that technically correct features could still create a poor experience. A calculation could be accurate but displayed with the wrong precision. A calendar could work but emphasize the wrong date. A guided walkthrough could progress correctly while making the interface difficult to use on a smaller screen.

That changed how I approached iteration. I simplified the navigation, gave the calendar a more important role, refined the walkthrough, revised financial language that could create the wrong interpretation, and repeatedly adjusted the hierarchy of the overview screen. The product improved most when I stopped asking, “What else can WalletIQ do?” and started asking, “What does the user need to understand here?”

What I learned

Building WalletIQ reinforced that product quality comes from a chain of small decisions. The code can run and the interface can still be wrong. A feature can work and still be unnecessary. A calculation can be accurate and still communicate the wrong idea. A technically successful implementation can still fail if the user cannot understand what matters.

It also taught me that product ownership requires moving between different kinds of problems. A financial concept becomes a requirement. A requirement becomes an interface. An interface exposes a data problem. A production issue requires root cause analysis. The biggest lesson was that building a better product does not always mean building more product.

WalletIQ became stronger as its purpose became clearer: turn financial activity into financial intelligence that helps people understand what matters next.