Behind the Build: Making LimitKeep With AI

I talk a lot on this site about building apps with AI. This post is the receipts: the story of how LimitKeep went from an idea to a real app, built by someone who isn't a traditional developer.

It's not a polished success story. It's the actual process, including the parts that took way longer than they should have.

The problem LimitKeep solves

Your credit utilization is how much of your available credit you're using, shown as a percentage. If you have a $1,000 limit and a $300 balance, that's 30%. It's one of the things credit scores look at.

Here's the catch most people don't know: card issuers usually report your balance to the credit bureaus around your statement closing date, not your payment due date. So you can pay your card in full every month and still have a high balance reported, simply because the balance was high on the day the statement closed. And every card has its own closing date.

LimitKeep tracks each card against its own statement closing date and tells you what to pay, and when, so the balance that gets reported is the one you actually want. It also tracks each card's balance, limit and utilization, and sends reminders before cards report and before payments are due.

Why I built it

I built LimitKeep because I was spending hours every payday trying to figure out which credit card I should pay down to have the biggest impact on my credit profile.

I had multiple cards, different balances, different credit limits, and different billing-cycle dates. I knew that utilization mattered, but figuring out exactly where my money would make the biggest difference meant doing a bunch of math and comparing everything over and over again.

Eventually, I thought, there has to be an easier way to do this.

That was the idea behind LimitKeep. I wanted to be able to enter my cards, see where I stood, and have the app help me figure out what to pay and where. What started as a problem I was personally tired of dealing with turned into an experiment to see if I could actually build a solution myself using AI.

And that became the real motivation behind the project: I wasn't building some random app just to say I built an app. I was trying to solve a problem that I was personally having.

The stack

LimitKeep runs on the same setup as this site:

• Next.js for the app itself, the pages and the logic
• Supabase for the database and user logins
• Vercel to host it and deploy every change automatically

I didn't pick these after weeks of research. I picked them because they're popular and well documented, which matters a lot when an AI is writing most of the code. The more examples an assistant has seen, the fewer strange problems you hit. (If you're curious about those pieces, I've written about why your app needs a database and the security basics every AI-built app should cover.)

How the work actually split up

I use two AI assistants for different jobs. Claude handled the planning and the coding: mapping out features, writing the code and fixing what broke. ChatGPT was my second opinion for brainstorming and pressure-testing ideas before I built them.

My job was everything the AI couldn't do: deciding what LimitKeep should and shouldn't do, testing every change like a real user, and noticing when something was technically working but not actually right.

From start to finish, the first version of LimitKeep took me about six weeks.

That might not sound like a huge amount of time, but I wasn't building it full-time. I have a full-time job, so most of the development happened on weekends. I also spent a lot of my free time during the week working on it whenever I wasn't at work.

There were plenty of nights and weekends where I probably should have been doing something else, but I was too caught up in getting the next feature working. I'd tell myself, "I'll just work on this for an hour," and suddenly it was several hours later. 😂

Those six weeks were a pretty intense learning experience. I wasn't just writing code — I was learning how the pieces of an application fit together, figuring out how to communicate what I wanted to the AI, fixing things when they broke, and constantly learning something new along the way.

Looking back, I'm actually pretty amazed at how much I was able to accomplish in six weeks, especially while working a full-time job. It made me realize just how much more accessible building software has become with AI.

The hard parts

The charts were the most visible headache. They looked simple, but dates didn't always line up, some updates appeared at the wrong point on the chart and different transactions weren't displayed consistently. I told the full story in I'm not a developer — here's how I build apps with AI anyway, but the short version is that I had to stop asking the AI to "fix it" and start breaking the problem down: how the data was stored, how the dates were calculated and how it all reached the chart.

The charts definitely weren't the only difficult part. One of the biggest challenges was getting all of the underlying logic to work correctly.

LimitKeep isn't just displaying information. It has to calculate utilization, understand billing-cycle dates, track balances and payments, determine which cards need attention, and turn all of that into recommendations that actually make sense. A small mistake in the underlying data or calculation can make something else in the app look completely wrong.

The user interface was another surprisingly difficult part. It's easy to keep adding features, but it's much harder to make all of those features understandable without overwhelming the person using the app. I had to repeatedly step back and ask, "Does this actually make sense to someone who didn't build it?"

And then there was the AI itself. AI can write a huge amount of code very quickly, but it doesn't automatically understand the entire product the way a human developer who has lived with the codebase for months does. Sometimes fixing one thing would break something somewhere else, and I had to learn how to give the AI better context, break problems into smaller pieces, and actually understand enough of the code to tell when its solution wasn't the right one.

That's the pattern I'd warn anyone about. AI is great at the parts of an app that look like a thousand other apps. It needs much more guidance on the parts that are specific to your idea, which, for LimitKeep, meant every card having its own cycle.

What worked well

The biggest thing that worked was simply having an AI coding partner available whenever I got stuck. Instead of spending hours searching through documentation trying to figure out why something wasn't working, I could explain the problem, get an explanation, try a solution, and keep iterating.

It also let me build things that I probably wouldn't have attempted otherwise. I didn't need to know every programming language, framework, or technical concept before getting started. I could learn as I went.

What I'd do differently

If I were starting LimitKeep over, I would do a few things differently.

First, I would spend more time planning the architecture before writing a bunch of code. AI makes it incredibly easy to say, "Hey, add this feature," and suddenly you have a feature. Do that enough times and you can end up with a codebase that's harder to maintain than it needs to be.

I'd also break larger features into smaller pieces instead of asking AI to build too much at once. The more complex the request, the easier it is for something important to get overlooked.

Most importantly, I'd make sure I understood what the AI was building instead of treating it like a magic box. You don't have to be an expert programmer to use AI effectively, but you do need to understand your own project well enough to recognize when something isn't right.

That's probably the biggest lesson LimitKeep has taught me: AI can dramatically lower the barrier to building software, but it doesn't remove the need to think.

What you can take from this

You don't need to be building a credit tool for any of this to apply. A few lessons carry over to almost any app built with AI:

• Solve a problem you actually have. You'll know exactly what "working" means, and you'll keep going when it gets hard.
• Use boring, popular tools. Let the AI work on familiar ground so you can focus on what's unique about your idea.
• Expect your hardest problems to be the ones only your app has. Budget extra time for them, and break them into small pieces.
• Stay the person who decides. The AI writes code. You decide what the app is for and whether it's right.

If you want to see what I ended up with, LimitKeep is on the apps page. And if you're starting your own project, the first AI-assisted web app guide is the best place to begin.

— Spencer