At the time, my plan was to replace a few larger shareware projects with several smaller apps to spread the risk. That didn’t quite work out — one app, MoneyControl, quickly grew so much that it became my main focus.
Fifteen years later, the app is still on the App Store, still actively developed, and still used by people who started with version 1.0. Many apps from that era are long gone.
Looking back, these are some of the things that mattered most:
Starting early helped, but wasn’t enough on its own. Early visibility made a difference, but long-term maintenance and reliability are what kept users.
Focus beat diversification. I wanted many small apps. I ended up with one large, long-lived product. Deep focus turned out to be more sustainable.
Long-term maintenance is most of the work. Adapting to new iOS versions, migrating data safely, handling edge cases, and keeping old data usable mattered more than flashy features.
Discoverability keeps getting harder. Reaching users on the App Store today is much more difficult than it was years ago. Prices are higher than in the old 99-cent days, but visibility hasn’t improved.
I’m a developer first, not a marketer. I work alone, with occasional help from freelancers. No employees, no growth team. The app could probably have grown more with better marketing, but that was never my strength.
You don’t need to get rich to build something sustainable. I didn’t build this for an exit. I’ve been able to make a living from my work for over 20 years, which feels like success to me.
Building things you actually use keeps you honest. Every product I built was something I personally needed. That authenticity mattered more than any roadmap.
This week I released version 10 with a new design and a major technical overhaul. It feels less like a milestone and more like preparing the app for the next phase.
Happy to answer questions about long-term app maintenance, indie development, or keeping a product alive across many iOS generations.
After much effort, I was earning enough from the FTP client to make a living, so I wanted to develop another app to diversify my risk. That one was a failure. I persisted and developed a third app around 2012: an email automation tool for Windows, something I actually needed myself. This one was also a success.
Finally, around 2020, I decided to focus exclusively on the email automation tool and develop a browser-based version of it. I've found that if you want to build something worthwhile, it's better to focus—even at the cost of more risk. That decision turned out to be the right one.
Congrats on your continued success!
I originally set it up mainly for risk separation. Before the apps, I was developing backup software, and having a legal structure felt like the responsible thing to do. It also looked more professional at the time. Whether I’d do it again today, I’m honestly not sure.
That said, keeping personal and business finances clearly separated has definitely been a good decision in the long run.
What are the main downsides you encountered? Apart from the initial investment I can imagine the administrative overhead, but I'd love to hear your insights.
Congratulations on your success, and best of luck going forward!
[0] https://www.mino.no.
I completely agree: in a small, niche business, relationships and support matter far more than scale. Replying quickly, taking users seriously, and actually helping them goes a long way over many years. It’s probably one of the few real advantages solo developers have over larger teams.
13 years in a niche is no small achievement. Best of luck to you too, and thanks for sharing your experience — it’s always encouraging to hear similar stories.
I wish financial institutions were better at automated exports of your financial data, given the right permissions of course.
In practice, though, I found them less useful for budgeting than expected. A bank statement tells you how much was spent and where, but not what the expense actually was. “$100 at a supermarket” could be groceries, pet food, a lawn mower, or business expenses — that context is what makes budgeting meaningful, and it usually has to be added manually anyway.
At that point, entering the expense directly with the right category often turned out to be simpler and more accurate for me. Automated access would still be nice for reconciliation, but it’s not the silver bullet it’s often perceived to be.
You're right that "$100 at a supermarket" is useless but I found even knowing "I spent $400 on groceries" wasn't that useful either. I kept asking myself "okay, but on what?"
So I leaned hard into making categories the starting point instead of the endpoint. Groceries breaks down into what I'm actually buying. Turns out I was spending way more on coffee than I realized.
Did you ever consider going deeper into categories, or do you find users just want the high level view? I've been torn on how much detail is actually helpful vs. overwhelming.
The key limitation is that a raw bank transaction usually contains very little semantic information: amount, merchant name, date. From that alone, an LLM can only guess based on patterns or prior behavior, not actually know what the expense was for.
“$100 at a supermarket” could be groceries, pet food, a household item, or something work-related. An LLM can infer probabilities once it has enough historical data and feedback, but that still means the user has to correct or confirm things at some point.
So I see LLMs as very helpful for assisting categorization (suggestions, defaults, learning over time), but they can’t fully replace intent unless the underlying data becomes richer than what bank statements provide today.
"test your personal user account one month free for." and other (translation?) mistakes.
Your use of capitalisation and spelling is not consistent throughout each page.
FAQ page is empty?
Quick Manual page is empty?
iOS download link doesn't work.
Your security posture boils down to "we're German, trust us"?
I think it could benefit from a personal, playful kind of touch to appeal to more mainstream users.
I got an error about "preventing attacks" the first time I tried to load your site.. and then again (I assume) in German when I clicked somewhere else. One time out of 10 I got a real page (I think) but it was also in German.
Impressive that you have created one app and stayed focused this whole time. I ended up creating multiple apps and having a couple acquired and moved on to other projects, but maybe I have ADHD lol.
I like your website, but I did find two dead links to the appstore here https://primoco.me/en/apps
These links do not work. I believe you want /us/ not /en/ for the links http://itunes.apple.com/en/app/moneycontrol/id465909912?mt=8 https://itunes.apple.com/en/app/haushaltsbuch-moneycontrol/i...
Anyway, keep up the good work and nice app. Cheers, Greg
1. How long after releasing the iOS app did you start on an Android version?
2. Are you using some kind of cross-platform framework, or are the apps mostly “mobile-friendly web views”?
3. How much code is shared between the three architectures?
4. How much of the app functionality is “server based” instead of “on device”?
In short: native apps, local-first architecture, with sync as an optional layer rather than a requirement.
(And thanks for the reply!)
???
That's all I wanted to say - as much of a milestone as version 10 is - the past 9 were amazing as well.
- what kind of authentication protocol stack is used
- what algorithm is used for network protocol encryption (hash, block, encryption)
- is data centrally stored, if so, is it encrypted at rest? Key stays in phones?
- any accounting audit done? (Moot but just a check mark in a small-family-business-oriented checkbox)
Great pricing!!
>Primoco ist not free and with good reason. Learn more about our offers and create your personal budget book with a free test.
`ist`
On the technical side, the biggest shifts were things like Objective-C → Swift, ARC, Auto Layout, size classes, Dark Mode, and more recently SwiftUI. I generally didn’t jump on everything immediately. My rule of thumb was: adopt new frameworks once they’re clearly stable and proven in real apps. Being too early often meant rewrites; being too late meant technical debt. A slightly conservative approach worked best for me.
Visually, Apple’s HIG evolved a lot: skeuomorphism → flat design → more layered, content-first UIs. I followed those changes gradually. Smaller visual updates happened continuously, but larger redesigns only when there was a real user benefit or a technical reason. Version 10 is one of those bigger moments where design and architecture changes aligned.
In hindsight, following a bit late rather than very early turned out to be the better tradeoff. Users value stability and consistency more than being on the absolute cutting edge, especially for a long-term app they rely on daily.
Typo in 'conenction'
In practice, though, I found them less useful for budgeting than expected. A bank statement tells you how much was spent and where, but not what the expense actually was. “$100 at a supermarket” could be groceries, pet food, a lawn mower, or business expenses — that context is what makes budgeting meaningful, and it usually has to be added manually anyway.
At that point, entering the expense directly with the right category often turned out to be simpler and more accurate for me. Automated access would still be nice for reconciliation, but it’s not the silver bullet it’s often perceived to be
I wonder, apart from the normal exposure/distribution on App Store, what are the main strategies you've used for marketing?
A local-first, offline-capable model turned out to be one of the best long-term decisions. It makes the app faster, more reliable, and usable in situations where connectivity is poor or nonexistent. Sync then becomes an enhancement, not a dependency.
It also changes how you design software: you optimize for resilience and data ownership instead of assuming a server is always there. I’m convinced more apps would benefit from this approach, especially for tools people rely on daily.
Congrats, really a long-run marathon!
Maintaining it for 14+ years is a huge effort, so I expect somehow a stable business model behind it?