DEV Community: Mark Barnett

Why I built my own budgeting app (and yes, I know there are hundreds already)

Mark Barnett — Thu, 21 May 2026 07:30:54 +0000

I know what you're thinking. The world doesn't need another budgeting app. You're probably right. But hear me out.

I've used YNAB, Mint (RIP), Copilot, Monarch, and more spreadsheet templates than I want to admit. They all annoyed me in different ways.

YNAB is powerful but it wants you to adopt a whole philosophy. Give every dollar a job, reconcile your accounts regularly, learn what "age of money" means. I spent more time managing YNAB than actually thinking about my finances. I don't want a budgeting practice. I want to know if I can afford the thing I'm looking at.

The simple apps go too far the other direction. Enter income, subtract bills, see what's left. Great for about five minutes until you need to track something that doesn't fit their three categories.

I wanted something in between and couldn't find it. So I built Money Me.

How it started

Weekend project. Classic. I just wanted to answer a few questions without a lot of fuss: what's my actual financial position right now? What does next month look like? Where's money disappearing that I haven't noticed?

The first version was barely an app. Income in, expenses out, a forecast showing when I'd run out of money at my current pace. No bank connections, no AI-powered insights, no gamification badges. Just arithmetic.

The weird thing is, that rough version was more useful than most of what I'd used before. Not because it was smart, but because it got out of the way. Open it, see the number, close it. No guilt about 47 uncategorized transactions. No backlog of receipts.

Manual entry in 2026, seriously?

Yeah. I know it sounds backwards when every other app is racing to add bank sync and automatic categorization.

But I've been on the other side of that. Mint would categorize my mortgage payment as "Shopping" and I'd spend 20 minutes unfiling and re-filing transactions. Plaid connections would break every few weeks and suddenly you're missing two months of data. The automation is convenient when it works and infuriating when it doesn't.

With manual entry, you actually know what the numbers mean because you put them there. It takes maybe 5 minutes a week. The tradeoff is worth it, at least for me.

Where Money Me gets more interesting is the forecasting. It projects forward — what does your cash look like in 30, 60, 90 days? Not just a flat calculation but accounting for irregular bills, the car insurance that hits quarterly, debt payments that change as balances go down. It's the thing I always wanted from a spreadsheet but could never be bothered to maintain the formulas for.

When it stopped being a side project

There was a week where I noticed I was checking Money Me before buying things. Not in a "I should check my budget" guilt way, just... it was the fastest way to know if the purchase made sense. That's when I realised the thing was actually useful and maybe I should take it more seriously.

So I rebuilt it properly as a PWA. Offline support, installable on mobile, actually fast. Added the features I kept wishing existed: debt payoff strategies (avalanche vs snowball, and you can compare them side by side), savings goals with realistic timelines, and something that flags when a spending category spikes compared to your normal.

It's been live at money-me.com for a while now. Works fine as a web app, no app store needed. But I kept getting asked "is it on the Play Store?" so I packaged it as a TWA (Trusted Web Activity — basically a PWA wrapped natively for Android) and that's where things got... bureaucratic.

The Google Play situation

Google requires 12 people opted into a closed beta for 14 consecutive days before you can release to production. Totally reasonable as a policy. Stops junk apps flooding the store. But when you're one person with no existing audience, finding 12 Android users who'll install your thing and keep it for two weeks is harder than it sounds.

I wrote about this already on dev.to. Classic chicken-and-egg: you need users to get on the store, but the store is where users would find you.

Some things I've figured out along the way

Building the product is maybe 40% of the work. Distribution is the rest. SEO, app store requirements, actually telling people the thing exists. Nobody mentions this part when you're excitedly sketching wireframes on a Saturday morning.

The "how often will someone actually use this?" test has saved me from a lot of bad features. Investment tracking sounds great on a feature list. In practice, people check their brokerage directly. Not everything needs to live inside a budgeting app.

And the indie dev community has been surprisingly helpful. People swap beta tests, share what's working, give feedback that's actually useful. Building alone doesn't mean being alone, which is nice.

Where it's at now

Money Me is live on the web. The Android app is in closed beta waiting to clear Google's 14-day window. The core stuff works well — dashboard, forecasting, debt strategies, savings goals, spending tracking. It gets better with each update.

It's not for everyone. If you love YNAB's zero-based approach, stick with YNAB. If you want auto-imported bank transactions, Money Me isn't that (at least not yet). It's for people who want to understand their money without adopting a whole system around it.

You can try the web app free at money-me.com.

If you've got an Android phone and 30 seconds to spare, I'd really appreciate help getting past Google's 12-tester gate. Beta testers get 6 months of Premium free once we're live in production.

👉 Opt in to the beta here

Happy to swap tests if you're building something too — drop your link in the comments.

How I shipped my PWA to Google Play as a TWA (and what actually went wrong)

Mark Barnett — Thu, 21 May 2026 07:29:15 +0000

I built Money Me as a PWA. It works offline, it's installable, it feels like a native app. At some point I decided to put it on Google Play because people kept asking "is it in the store?"

The TWA route seemed obvious. Wrap the existing PWA in an Android shell, ship it. I figured a day of work, maybe two.

It took me a lot longer than that.

So what is a TWA

A Trusted Web Activity is basically an Android app that opens your website in Chrome, but with the browser UI stripped away. No address bar, no back button. Fullscreen. If you didn't know better you'd think it was a regular Android app.

The "trusted" bit: you prove you own the domain by putting a specific JSON file on your server. Android checks it against your app's signing key. If it matches, Chrome hides the browser chrome (pun maybe intended). If it doesn't match, you get an ugly blue bar at the top and your app looks like a glorified bookmark.

Important thing I didn't understand at first: a TWA is NOT a WebView. It's actual Chrome running your site. Service workers work, push notifications work, everything your PWA already does just... works. This is the main reason to use a TWA over something like Capacitor or a WebView wrapper.

Bubblewrap

Google has a tool called Bubblewrap that generates an Android project from your web manifest. Point it at your manifest URL, it spits out a project, you build an APK.

My advice: don't treat it as a black box. You will need to open the generated project and mess with build.gradle and the Android manifest at some point. If you've never seen an Android project before, spend 20 minutes understanding the structure first. You'll thank yourself later when something breaks and the error message means nothing to you.

The blue bar (aka my nemesis for two days)

This is where I lost the most time. The blue navigation bar shows up when Chrome can't verify you own the domain. Your app still works fine underneath, it just looks terrible.

The fix is a file at /.well-known/assetlinks.json:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourapp.twa",
    "sha256_cert_fingerprints": ["YOUR:SHA256:FINGERPRINT:HERE"]
  }
}]

Simple enough. Except I got the fingerprint wrong three times before figuring out what was happening.

The problem: you have multiple signing keys and they all have different fingerprints. There's your local debug key, your upload key, and then Google Play's own app signing key. Play App Signing is mandatory for new apps now, which means Google re-signs your bundle after you upload it. So the fingerprint that matters for asset links is Google's key, not yours.

Go to Play Console → Setup → App signing → App signing key certificate and grab the SHA-256 from there. I wasted hours using my upload key fingerprint instead. The blue bar kept showing up and I kept double-checking the JSON format, the content type, the file path. The file was fine. The fingerprint was just wrong.

Other things that bit me:

Chrome caches the verification result. You fix the asset links file, reinstall the app, and... blue bar is still there. You need to clear Chrome's data on the test device. Not just the cache. The data. I was clearing the app cache only and wondering why nothing changed.

Content-Type has to be application/json. My CDN was serving it as text/plain. Took me a while to catch that one.

Use Google's verification tool. I should have used this from the start instead of guessing. It tells you exactly what's wrong.

The signing key situation

If you're a web developer, Android signing keys are confusing. There are two keys involved:

Your upload key — you use this to sign the bundle before uploading to Play Console
Google's app signing key — Google uses this to sign the APK that actually gets distributed to users

For your asset links JSON, you need #2. Not #1. I keep repeating this because it took me an embarrassingly long time to figure out, and every tutorial I found either glossed over it or assumed you already knew.

Generate your upload key:

keytool -genkey -v -keystore upload-keystore.jks \
  -keyalg RSA -keysize 2048 -validity 10000 \
  -alias upload

Then do your first upload to Play Console, and THEN go grab the app signing key fingerprint. You can't get it before the first upload because Google generates it at that point.

Closed testing: the 12-tester gate

Once the app was building and the blue bar was gone, I thought I was done. Nope.

Google requires new apps to have 12 testers opted into a closed beta for 14 continuous days before you can go to production. You need real people with real Google accounts who join your testing program, install the app, and stay opted in for the full two weeks.

If you've got an existing user base, this is nothing. If you're a solo dev shipping your first app, it's a real bottleneck. I wrote a whole post about this already.

What I'd do differently next time

Get asset links working BEFORE you build the TWA. Host the JSON file, verify it with Google's tool, confirm it's correct. Then build the app. Debugging both at the same time is miserable.

Start looking for testers before your build is ready. The 14-day clock is the actual bottleneck, not the technical work.

Test on a Samsung phone early. My app looked perfect on a Pixel. Then I tried it on an older Galaxy and some things were off.

Is it worth it though?

Yeah. For a PWA that's already working well, a TWA is the right call. One codebase, Play Store presence, native-feeling experience. The setup takes a weekend if you know the pitfalls. Compared to maintaining a separate React Native or Kotlin app? Not even a question.

The downside is you're dependent on Chrome being installed, but that's basically every Android phone. And you need to keep your asset links in sync when keys change. That's about it.

I'm going through the closed testing process now with Money Me. If you've got an Android phone and don't mind helping an indie dev clear the 12-tester gate, I'd massively appreciate it. Beta testers get 6 months of Premium free.

👉 Join the beta on Google Play

30 seconds to opt in. If you've got TWA questions, drop them in the comments — I've made most of the mistakes already.

Show DEV: I built a personal finance app and now I'm stuck behind Google's 12-tester gate

Mark Barnett — Wed, 20 May 2026 16:15:34 +0000

I've been building Money Me for a while now — a personal finance app that tracks spending, income, budgets, and savings goals. Nothing groundbreaking, just trying to do the basics properly without the bloat.

The web app has been live at money-me.com for a while and it works well. So I figured wrapping it as an Android app would be the easy part. Built it as a TWA (Trusted Web Activity) — basically the PWA packaged natively. Same app, proper home screen icon, runs in Chrome under the hood.

Turns out shipping to Google Play is where it gets interesting.

Google requires 12 people opted into your closed beta for 14 consecutive days before they'll let you publish to production. Makes total sense as a policy — stops junk apps flooding the store. But when you're a solo dev with no audience yet, finding 12 people who'll install your app and keep it installed for two weeks is a genuine challenge.

So here I am, asking the dev community for help.

What Money Me does

Track income and expenses manually (no bank sync — privacy first)
Set monthly budgets and see where you're overspending
Create savings goals and track progress
Monthly overview that actually tells you something useful

The ask

If you've got an Android phone and don't mind keeping the app installed for a couple of weeks, I'd massively appreciate it. The opt-in takes about 30 seconds:

👉 play.google.com/apps/testing/com.moneyme.twa

You can also try the web version first at money-me.com — it's the exact same app.

Every tester gets 6 months of Premium free once we launch to production.

And if you're building something too — drop your link in the comments. Happy to swap tests. We've all been stuck behind this gate at some point.