Why We Rebuilt a 13-Year-Old Budgeting App from Scratch

In 2013, I was a student who couldn’t answer a simple question: can I afford lunch today without going broke before rent is due?

I looked for budgeting apps. They wanted me to connect bank accounts, set up complex category systems, or learn an entirely new financial philosophy. I just wanted one number — what I could safely spend today.

So I built BUDGT.

Thirteen years later, that same app has been rebuilt from the ground up. Every line of code rewritten. Every screen redesigned. Every user’s data carefully migrated.

This is the story of why.

The Original App: A Student Project That Stuck

BUDGT started as a learning project. I was teaching myself iOS development, and I needed a real problem to solve. My budget problem was very real.

The first version was simple:

• Enter your monthly budget
• Log expenses throughout the month
• See one number: what you can spend today

That’s it. No categories at first. No analytics. Just the daily budget, updated in real-time.

I launched it on the App Store in 2013, expecting nothing. Maybe a few downloads. Maybe some feedback to improve my coding skills.

What happened instead: people actually used it. Not millions — BUDGT has never been a viral hit — but thousands. Enough to realize I’d built something that solved a real problem.

Over the following years, I added features: categories with colors, savings mode, travel mode for currency conversion, day weights for uneven weekly budgets, geotagging, export, Face ID, and more. Each feature was carefully considered against BUDGT’s core philosophy: simplicity above all.

The app grew. The codebase aged.

When Technical Debt Becomes a Wall

Here’s something they don’t tell you about maintaining software for over a decade: the decisions that made sense in year one become constraints in year ten.

The original BUDGT was written in Objective-C — the standard iOS language in 2013. The architecture made sense for what the app was: a simple daily budget tracker with a few extras.

But users kept asking for things the architecture couldn’t support:

“I track everything, but I can’t see patterns.” Adding analytics required restructuring how data was stored and queried. The original database schema wasn’t designed for time-series analysis.

“I want to set limits on specific categories.” Category targets meant adding a parallel budgeting system alongside the daily budget. The existing code was too tightly coupled.

“Can you show me spending pace?” Calculations that would be trivial in a modern architecture required complex workarounds in the legacy code.

I tried. For years, I tried to add these features incrementally. Every attempt hit walls. I spent more time fighting the architecture than building the features users wanted.

The codebase wasn’t broken. The app worked fine. But it couldn’t grow.

The Rebuild Decision

Rebuilding from scratch is the nuclear option in software development. It’s almost always the wrong choice — you lose momentum, introduce new bugs, and often underestimate the complexity of what you’re replacing.

But sometimes it’s the right choice. Here’s what convinced me:

The gap between “what users want” and “what the code can support” was widening. Analytics wasn’t a nice-to-have anymore; it was the #1 request for years.

Modern tools would make future development faster. Flutter and Dart offer development speed and maintainability that Objective-C can’t match.

The migration could be done safely. Same bundle ID means same app container, which means access to the existing database. A careful migration was technically possible.

BUDGT deserved a future. After 13 years and thousands of users, the app had earned the investment needed to continue.

I made the call: start fresh.

The Migration Challenge

If you’re building a new app, you start clean. No legacy data. No existing users with years of history.

BUDGT 13 wasn’t a new app. It was an update to an existing product with thousands of users and years of their financial data.

Every expense they’d ever logged. Every category they’d created. Every setting they’d configured. Every geotagged location.

All of it had to move to the new version without losing a single record.

This was the hardest part of the rebuild.

The technical challenge: The old app used Core Data (Apple’s database framework) with a schema designed in 2013. The new app uses Drift (a modern SQLite wrapper). They don’t speak the same language.

The edge cases: What about archived categories? Recurring expenses with gaps? Geotags stored in Apple’s proprietary format? Settings in UserDefaults? Every edge case needed handling.

The stakes: A failed migration means users lose their financial history. That’s not acceptable — ever.

I built seven test scenarios covering different data patterns:

• Fresh installs (no data to migrate)
• Long-time users with thousands of expenses
• Users with archived categories
• Users with recurring entries that had gaps
• Users with geotagged expenses (requiring native Swift code to decode Apple’s location format)
• Users with customized settings
• Users who’d upgraded through multiple previous versions

Each scenario had to pass completely before shipping.

The migration took more development time than any new feature. But every user who updates sees their complete history, exactly as it was.

What Didn’t Change (And Never Will)

The rebuild changed a lot. But some things are core to BUDGT’s identity:

100% Offline, Always

BUDGT doesn’t connect to the internet. There’s no cloud sync. There’s no server. Your financial data exists on your device and nowhere else.

This isn’t a technical limitation — it’s a philosophy. Your spending data is sensitive. It reveals your habits, your location, your lifestyle. We believe that data should stay with you.

In an era of data breaches, companies selling user information, and apps that require internet for basic functionality, BUDGT’s offline-first approach is increasingly unusual. And that’s intentional.

No Bank Connection

BUDGT doesn’t connect to your bank. You manually log expenses.

Some people see this as a limitation. We see it as a feature.

Research consistently shows that manual expense tracking makes you more aware of your spending. The act of logging creates a moment of reflection. That friction is the feature.

Auto-import makes expense tracking effortless — but effortless tracking often becomes mindless tracking. You see the transactions after the fact, with no opportunity to reconsider.

BUDGT’s manual approach means every expense gets your attention.

The Daily Budget Philosophy

The core concept hasn’t changed since 2013:

1. Take your monthly income
2. Subtract your fixed expenses
3. Subtract your savings goal
4. Divide by the days in the month

You get one number: your daily budget. Stay under it, and you’ll have money left at month’s end.

Everything else in BUDGT — categories, analytics, targets, travel mode — exists to support this simple premise. The rebuild added features, but the foundation is unchanged.

What This Foundation Enables

The rebuild wasn’t just about adding analytics and category targets. It was about building a foundation for the next decade.

Flutter enables cross-platform development. The same codebase can run on Android. While I’m not announcing a timeline, the technical door is now open.

Modern architecture supports future features. New capabilities can be added without fighting legacy constraints.

Cleaner code means faster iteration. Bug fixes and improvements ship faster on a maintainable codebase.

The app is positioned to grow. Whether that’s new platforms, new languages, or new features — BUDGT 13 can accommodate what users ask for next.

Try the daily budget method Calculate your daily spending limit in seconds

Lessons from 13 Years

Maintaining a product for over a decade teaches you things:

Users want consistency more than novelty. The features people rely on should keep working exactly as expected. Stability is a feature.

Simple ideas are hard to execute. “Show me what I can spend today” sounds simple. Making it accurate, reliable, and instantly understandable took years of refinement.

Privacy is increasingly valuable. When I built BUDGT in 2013, “no cloud sync” was a technical simplification. In 2026, it’s a selling point.

Technical debt compounds. Small shortcuts in year one become major constraints in year ten. Every workaround you leave in place makes the next change harder.

Rebuilding is expensive but sometimes necessary. I delayed the rebuild for years, trying to extend the existing code. Eventually, the gap between what users needed and what the architecture could support forced the decision.

Users trust you with their history. Thousands of people have years of financial data in BUDGT. That’s a responsibility. The migration had to be perfect because anything less betrays that trust.

A Thank You

BUDGT exists because people use it. Not millions — BUDGT has never been the most popular budgeting app — but enough. Enough people found it useful enough to keep it alive for 13 years.

Every feature request that pushed me toward this rebuild. Every review that pointed out problems. Every user who stuck with the app through updates good and bad.

BUDGT 13 is built on that foundation. The code is new; the community isn’t.

If you’ve been using BUDGT for months or years, thank you. Your data is safe, your history is preserved, and the features you’ve been asking for are finally here.

If you’re new to BUDGT, welcome. The app has 13 years of refinement behind it — and now, a foundation that can support the next 13.

Download BUDGT on the App Store