← Back to list

# I Built an Expense Tracker in Lovable — Here’s What 3 Hours Actually Looked Like

*Using Lovable as an app builder when you’re not a developer: an honest account*

江戸川太郎 · 2026-06-15 09:19 · 0 claps · 4.8 min read
#lovable #no-code #saas
Open on Medium ↗

I Built an Expense Tracker in Lovable — Here’s What 3 Hours Actually Looked Like

Using Lovable as an app builder when you’re not a developer: an honest account

— -

Why Lovable, and Why Now

I’d been putting off building a small internal expense tracker for months. Nothing fancy — just a form, a table to log entries, and a running total. The kind of thing that takes a developer an afternoon and takes me, someone who can read code but can’t really write it, approximately forever.

I’d tried Bolt.new a couple of times before. Bolt is impressive for certain things, but I kept running into a wall where the generated code looked right, the preview looked right, and then I’d try to add one more thing and something upstream would silently break. Debugging AI-generated code when you don’t fully understand the code is its own particular kind of hell.

Lovable had been showing up in the indie hacker communities I follow — not because of hype, but because people were posting actual screenshots of actual things they’d shipped. That’s the signal I pay attention to.

So I blocked off a Saturday morning and gave myself one rule: ship something real, or write honestly about why I couldn’t.

— -

The Build: What I Made and How It Actually Went

My target was simple. An expense tracker with:

  • A form to add expenses (description, amount, category, date)
  • A table showing all entries
  • A total at the bottom
  • Data that persisted — meaning if I closed the tab, it didn’t vanish

I opened Lovable, started a new project, and typed my first prompt:

”Build a simple expense tracker app. It needs a form to add expenses with fields for description, amount, category (dropdown: Food, Travel, Software, Other), and date. Below the form, show a table of all expenses with a running total at the bottom.”

What came back in roughly two minutes: a fully rendered UI, a working form, a table with column headers, and a total line. I stared at it for a moment because the layout was actually clean. Not “for an AI-generated thing” clean — just clean.

I clicked “Add Expense,” filled out the form, hit submit.

The entry appeared in the table.

The total updated.

I felt something I can only describe as suspicious relief — the kind you feel when something works too easily and you’re waiting for the other shoe to drop.

— -

The Trouble: Where I Actually Got Stuck

The other shoe dropped about 40 minutes in.

I wanted the data to persist across sessions, which meant connecting to Supabase. Lovable has a built-in Supabase integration, and the prompting interface for it is clean. I typed something like:

”Connect this to Supabase so that expense entries are saved to a database and load on refresh.”

Lovable scaffolded the connection, created the table schema, and updated the frontend code. In the preview, it looked like it worked — I added an entry, refreshed, it was still there.

Then I tried to add a second project-level user (I wanted my partner to also log expenses). The app stopped saving new entries entirely. No error message in the UI. Just… silence. The form would submit, the spinner would spin, and nothing would appear in the table.

I spent close to an hour on this. I prompted Lovable to debug it. It suggested the issue might be with Row Level Security policies in Supabase — and it was right, but the fix it generated introduced a slightly different problem where all users could see all entries regardless of who created them.

Getting RLS right required me to actually go into the Supabase dashboard, read their documentation on auth policies, and write one policy by hand. Not hard in retrospect, but it broke the “no-code” promise I’d mentally made to myself. This is a real limitation worth knowing about: anything that touches auth, multi-user logic, or permissions will require you to get your hands slightly dirty.

Total time from “this should be easy” to “this actually works correctly”: about 90 minutes, just for the auth piece.

— -

The Surprise: What I Didn’t Expect to Work That Well

The component editing.

When I wanted to change the UI — move the total to the top, add a simple bar chart showing spending by category, change the date format — I just described what I wanted in plain language and Lovable made surgical changes. It didn’t regenerate the whole app. It edited the specific component I was talking about.

That sounds like a small thing, but it’s not. With other tools I’ve used, asking for a UI change sometimes felt like asking someone to repaint one wall and watching them redecorate the whole room. Lovable’s edits felt precise. I asked for a chart, I got a chart in roughly the right place, and nothing else moved.

I also didn’t have to deploy anything manually. The app has a shareable URL by default. I sent it to my partner. She opened it on her phone. It worked. That moment — sending a link to something I’d built — hit differently than I expected.

— -

Honest Comparison to Other Tools

I’ve spent time with Bolt.new, Replit, and v0 (for UI components specifically). Here’s my unvarnished take:

vs. Bolt.new: Lovable felt more stable across iterative edits. Bolt is fast for the first version; Lovable is better when you’re on your 12th prompt and things are getting complicated.

vs. v0: Not really a fair comparison — v0 is a UI component generator, not a full-stack app builder. They solve different problems.

vs. Replit: Replit gives you more raw control and is better if you’re comfortable in code. If you’re not, it’s intimidating in a way Lovable isn’t.

The trade-off with Lovable is that when something breaks in a way the AI can’t diagnose, you’re more stuck than you’d be in an environment where you can poke around the terminal. The abstraction is a gift until it isn’t.

— -

Verdict: Who Should Use This, and Who Shouldn’t

Lovable is genuinely useful if you:

  • Have a specific, bounded thing you want to build (not a vague idea)
  • Are comfortable reading error messages and doing small amounts of research when things break
  • Want to ship a working prototype to show stakeholders, early users, or investors
  • Are a founder who needs an MVP and can’t or won’t hire a developer yet

Lovable is probably not for you if:

  • You need something production-ready with serious security requirements out of the box
  • Your app has complex multi-user auth logic from the start
  • You’re a developer — you’ll be faster in your normal environment
  • You have no tolerance for ambiguity when debugging

My expense tracker is live, my partner uses it, and it took me about three hours total. I’m keeping it. That’s the real verdict.

— -

Try It Yourself

If your current workflow involves a spreadsheet doing a job it wasn’t designed for, or a process you’ve been meaning to automate for six months, I’d suggest this: pick that one thing and try to rebuild it with Lovable’s free tier.

That’s exactly what I did. Not to evaluate Lovable as a product category, but because I had an actual problem and an afternoon. The fact that it mostly worked is what convinced me to write any of this down.

Start building with Lovable

— -

The affiliate program offers recurring commissions — if you sign up through the link above, I may earn a small percentage at no cost to you. I only link to things I’ve actually used.


메타데이터
post_id
394fea68cc7d
slug
i-built-an-expense-tracker-in-lovable-heres-what-3-hours-actually-looked-like-394fea68cc7d
url
https://medium.com/@kentaro.shigoto.edogawa/i-built-an-expense-tracker-in-lovable-heres-what-3-hours-actually-looked-like-394fea68cc7d
canonical_url
https://medium.com/@kentaro.shigoto.edogawa/i-built-an-expense-tracker-in-lovable-heres-what-3-hours-actually-looked-like-394fea68cc7d
author_url
https://medium.com/@kentaro.shigoto.edogawa
status
ok
fetched_at
2026-06-17 08:20:12