Building Clear Balance, one version at a time.

What comes next: helping the Assistant grow up

After Version 2.2, I want to keep improving the Assistant's understanding and the quality of its explanations, alongside the everyday planning tools that make Clear Balance useful. I also have longer-term ideas for the app, but I am not putting dates or promises against features before they have been built and properly tested.

I suspect the Assistant would already describe herself as senior management. We will see whether she can manage a few more questions first.

Version 2.2.0: finally building the features I had been saving

10 October 2026

After spending Version 2.1 strengthening the parts of Clear Balance that you do not normally see, I was more than ready to build something people would actually notice. Version 2.2 has been one of the most exciting updates to work on, partly because several of its features have been sitting on my wish list for a long time. They just had to wait until the foundations were ready.

The biggest addition is the Clear Balance Assistant. I wanted someone to be able to look at a figure in their plan and simply ask, "Why has that changed?" or "Which debt should I look at next?" without searching through every screen. The Assistant can explain APRs, budgets, repayment strategies, promotional rates and the information behind your plan. It can remember the context of a conversation while you are using it, and for supported requests it can even prepare debt changes and recorded payments for you to confirm.

Now, a confession: she is not going to win any general-knowledge quizzes just yet. Her IQ is, shall we say, enthusiastically modest. But that is partly the point. Instead of bolting on a cloud AI chatbot, I have built an on-device Assistant that follows rules, uses the information saved in your plan and stays focused on what Clear Balance can actually explain. No financial details need to be sent to an outside AI service. I would much rather she admit what she cannot answer than confidently invent a repayment figure.

The plan is to make her more capable over time, with better language understanding, more useful questions and smarter contextual explanations, while protecting that local-first approach. For now, she is already much more helpful than her imaginary job title suggests.

Away from the Assistant, I rebuilt adding and editing debts into a more guided experience, added achievements and milestone celebrations, and I also introduced Balanced, a brand-new repayment strategy designed to bring together the motivational quick wins of Snowball and the potential interest savings of Avalanche, offering a more rounded approach to paying off debt. There have also been plenty of smaller improvements to Premium screens, subscription handling, accessibility, performance and the general feel of the app.

Then came the less glamorous part: testing it all. I worked through a detailed release audit covering privacy, financial calculations, Assistant behaviour, subscriptions, performance, Android, iOS and accessibility. It revealed problems worth fixing and produced a rather impressive number of automated tests (1018 now in total). As I prepared Version 2.2 for release, I felt proud of how much has changed without losing the original idea: clearer debt planning that respects your privacy and leaves the decisions with you.

Trying to Break Clear Balance: Security Testing

1 October 2026

Clear Balance v2.1 was a security-focused release. It introduced stronger local protection, encrypted password-protected backups, App Lock improvements, safer Android backup behaviour and a number of smaller privacy and resilience changes. Once the release was live, I wanted to do something more useful than simply say, "the app uses encryption".

I wanted to try to break it.

So I ran a structured, owner-led security test against the production Android version of Clear Balance from Google Play. This was not an independent third-party penetration test or a certification, and I do not want to present it as one. It was a practical attempt to test the security claims I had built into v2.1 against the app that users actually receive.

The first step was checking the production package itself. The shipped app was confirmed to be non-debuggable, Android backup was disabled, and cleartext network traffic was disabled. I also reviewed the Android manifest for exported activities, receivers and content providers. The launcher activity was exposed as expected so Android can start the app, while other relevant components were either non-exported or protected by Android permissions.

Next came App Lock. I force-stopped Clear Balance and launched its exported activity directly through ADB, then tried cancelling authentication, pressing Back, switching apps, resuming from the background and repeating the launch after force-stop. The important part was not whether the app could be launched externally - Android has to be able to launch it - but whether any protected content appeared before authentication. In the tests I ran, it did not. There was no dashboard flash, no debt names or balances visible behind the biometric prompt, and no bypass through the lifecycle paths I tested.

I also planted distinctive fake financial data in the app and went looking for it outside the encrypted store. I searched Android logs and readable shared storage for the fake debt name, balance, APR and minimum payment. None of those values appeared in the places tested.

The biggest part of the test was Clear Balance's backup format. I exported a real encrypted backup from the production app, downloaded it from Google Drive and inspected the file. The envelope identified itself as a Clear Balance encrypted backup, used an envelope version, declared AES-256-GCM, and recorded PBKDF2-HMAC-SHA256 with 600,000 iterations. The salt and cryptographic parameters were visible, as they should be, while the actual plan was stored as ciphertext.

I then searched the raw backup for the fake debt data and the disposable test password. Neither appeared in plaintext.

After that I started damaging copies of the backup. A valid backup with the correct password restored successfully. The same backup with the wrong password was rejected. A copy with its ciphertext deliberately changed was rejected even when the correct password was supplied. A truncated copy was rejected. Backups declaring an unsupported envelope version, unsupported cipher or unsupported key-derivation function were also rejected. In each failed case I checked that the existing plan remained intact rather than being partially overwritten.

That was probably the most valuable part of the whole exercise. It showed more than "the file looks encrypted". It tested both sides of the restore boundary: valid data was accepted, while wrong, damaged or altered data failed closed.

I then tested what happens when the Android app is removed. After uninstalling and reinstalling Clear Balance from Google Play, the local plan and App Lock state did not silently return through Android backup. An encrypted backup that I had explicitly exported remained restorable, which is the intended distinction: uninstalling removes the local app data, while a backup the user deliberately created remains under their control.

For network privacy, I routed the phone through an interception tool and exercised representative parts of the app including debts, budget, settings, the Premium screen and Restore Purchases. I again used distinctive fake financial values and searched the observed traffic for them. I did not find the seeded plan values in the traffic captured during those workflows.

I also checked the production APK for unexpected analytics and crash-reporting SDKs. Adapty was present, as expected for subscription entitlements. Initial broad searches appeared to show AppsFlyer and Adjust, but a more precise namespace check showed that these were optional integration references inside Adapty rather than the AppsFlyer or Adjust SDKs themselves. The targeted checks also did not detect Firebase Analytics, Crashlytics, Sentry, Amplitude, Mixpanel or the Facebook SDK.

Finally, I tested a few of the less obvious privacy surfaces. Sensitive Clear Balance content was not visible in the Android recent-apps preview. ADB screen capture worked normally on the Android home screen, but Clear Balance itself rendered black in captured screenshots. The budget-review notification also exposed only generic reminder text; I did not find debt names, balances, APRs, minimum payments or other seeded plan values in the notification surfaces tested.

Across the completed Android test scope, I did not identify a security vulnerability that required a fix.

That sentence needs an important qualifier: this does not mean Clear Balance is "unhackable". No software is. I deliberately deferred rooted-device/runtime instrumentation testing, which would assume the Android sandbox itself has already been compromised. I also have not repeated this test suite on iOS yet, and this was an owner-led assessment rather than an independent review.

For me, the useful outcome was not a perfect scorecard. It was turning the privacy claims in Clear Balance into things I could actually test: Can another normal app browse the data? Can a backup be read without the password? What happens if the encrypted file is changed? Does App Lock fail safely? Do balances end up in logs, screenshots, notifications or network traffic?

For the Android scenarios I tested, v2.1 behaved the way I intended.

I will keep repeating these checks when the security-sensitive parts of Clear Balance change, and I would like to extend the test further in future with hostile-device testing and an independent external review. Security is not a one-off feature to tick off; it is something I want to keep testing as the app evolves.

This was a developer-led security assessment, not an independent certification. Results describe the specific production Android build and workflows tested on 1 October 2026. The absence of a finding in these tests is not a guarantee that no vulnerability exists.

Read the Android security testing summary (PDF)

Version 2.1.0: the less flashy work that matters

Version 2.1.0 has been mostly about security, privacy, resilience and user protection. It is probably the least glamorous update to explain, but one of the most important I have worked on.

Sensitive plan data now lives in an encrypted local vault, with migration from older installs designed to preserve existing plans. I also replaced the old export approach with password-protected encrypted Clear Balance backup files that can be moved between Android and iPhone.

App Lock was strengthened, Android backup behaviour was tightened, the subscription paywall was brought into the app instead of being remotely hosted, and several failure and recovery paths were hardened after a full release audit.

There are some more visible additions too: budget-gap safeguards, optional budget review reminders and a new Savings Impact tool in Focus for Premium users. A lot of Version 2.1.0 has been about making sure the app behaves sensibly when things go wrong, not just when everything goes perfectly.

Version 2.0.0: turning a tracker into a planning tool

By Version 2.0.0, Clear Balance had grown beyond simply keeping a list of debts. I spent a lot of time refining the Dashboard, Debts, Budget, Focus and Progress areas so the app felt more joined-up and useful day to day.

The planning side became much more important too. Focus, projected debt-free dates, strategy comparisons and one-off payment scenarios made it possible to explore what different choices might change without pretending there is one perfect repayment method for everyone.

This was also the point where the whole product started to feel more mature. The design became more consistent, the website grew around the app, and I got much more comfortable maintaining the same product across both Android and iPhone.

Version 1.0.0: getting the idea into people's hands

Version 1.0.0 was about proving that the idea worked at all. It was my first Flutter app, so I was learning Dart, Flutter, mobile layouts, state, debugging, subscriptions and the app-store process while building the product at the same time.

The first release gave Clear Balance its foundations: a place to record debts, keep an eye on a monthly budget, compare Snowball and Avalanche repayment approaches, and turn a pile of separate figures into something much easier to understand.

Looking back, there were plenty of things I would build differently now. That is part of the fun of it though. Version 1.0.0 got the app out of my head and onto real phones, which meant I could finally start learning from the app itself rather than just from the idea.