I think there's something wrong with whatever bot/abuse detection you're using.
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.
My personal bias is that anytime I see on a software company's website footer that they're a GmbH, I know it will be selling high quality, durable, reliable software ;)
Thanks! That’s funny, because while it’s technically a GmbH, it’s really just me — a one-person company.
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.
"Whether I’d do it again today, I’m honestly not sure."
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.
I love this. I also built a business like that[0]. It's super niche. I have maintained this small business for soon to be 13 years now. Most of what has worked has been maintaining great relationships with the few customers I have.
I think the most important thing for me have been offering amazing support. I always reply to all e-mails right away and make it my top priority giving them my best help.
Congratulations on your success, and best of luck going forward!
Thank you — and congrats to you as well, that’s an impressive run.
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.
Nice project! I built a CLI budgeting project a long time ago, and what made me stop using my own project was the lack of automated integration with my bank accounts. At that point I had many credit cards, multiple bank accounts, in different currencies, and integrating all expenses was just too much manual work.
I wish financial institutions were better at automated exports of your financial data, given the right permissions of course.
That’s a fair point. Automated bank imports sound essential at first, especially with many accounts and cards.
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.
This is something I kept bumping into when building my own tracker (Simple Wallet - https://simplewallet.app).
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.
That’s fair — and I agree if enough context exists.
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.
Is there any chance it could become richer? What governs the content of credit card and bank statements? Is there anyone pushing for them to be more useful?
I think (granted, this is from a quick bit of research so I could be wildly wrong) - the message you see in your credit card app with a transaction is usually mainly the merchant name and location which is part of ISO 8583, so it may be a bit hard to extend it to include an arbitrary message in a way that works without merchants having to replace card reader/POS systems en-masse.
one way to go around this is to use apps like Toshl which connect to banks (it is far from perfect but usable) and then if you are unhappy with the app you can use their API to sync with your own system
That was also my first impression when I saw the site. The color scheme in general looked more like "boring b2b SaaS" and not a personal budgeting app and not really something where I'd look forward to spending a lot of time in (Which ideally you should in a budgeting app).
I think it could benefit from a personal, playful kind of touch to appeal to more mainstream users.
Indeed. The capitalization and punctuation inconsistencies are a huge turn off. My instinct was that people behind the software don’t have attention to detail.
I have been paying my bills by computer since the early 80s. The key feature I wanted was check printing. These days I only write about 3 or 4 checks a month. For the past few years I have been using Banktivity but they have gone to a subscription model so I expect soon my copy will no longer run. I use it mostly for cash flow planning. Mac based so I would have to gin up something in Numbers to track expenses. Not looking forward to getting Numbers to print checks. Are you aware of any open source budget app that might give me a head start? If Apple ever gets around to running iOS apps on my MBP I would certainly consider your utility.
Nice work. I started around same time as you 1996. I was selling professional dj software as shareware called ClubDJ Pro from 1999-2012 before coding for the app store as well.
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.
Good questions.
- The Android version came about two years after the iOS app. iOS was always my primary focus and the main success driver.
- Both apps are 100% native. No cross-platform framework and no web views. It may sound more complex, but for me it was actually simpler and more controllable that way.
- There is very little shared code between platforms. Concepts and ideas are shared, but the implementations are platform-specific.
- The core app functionality is almost entirely on-device. MoneyControl works locally by design. There is an optional WebApp that adds device sync and a browser-based interface, but the server side is essentially limited to synchronization.
In short: native apps, local-first architecture, with sync as an optional layer rather than a requirement.
> Unfortunately, our security system has detected malicious access from your computer to our website. For the protection of our system the access was temporarily blocked.
This really resonates. Long-term maintenance, reliability, and staying useful over years is the hardest part of building software — and often the most overlooked. Respect for prioritizing sustainability over hype. That mindset is what actually creates real products.
Interesting! I know next to nothing about iOS development, but surely there have been major changes in frameworks and expected look (often connected)? Which changes were there over the years and how and when did you follow them? Did it turn out good or bad to follow early / late?
Good question — yes, there were many major changes, both technically and visually.
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.
How do you market your software?
Did you learn how to become a marketer and took it as a persona? What have you learned how to market your software in the past 20 years as a developer?
>The mobile apps (iOS, Android, etc.) can be downloaded from the app stores and tested free of charge. Simple in-app purchases or the conenction to a paid WebApp unlock the Premium Features.
That’s a fair point. Automated bank imports sound essential at first, especially with many accounts and cards.
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
Looks great, and I was also happy to see that it has offline capabilities and will sync once you have a signal. There needs to be more apps built using this model.
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.
And people think you need to go to the jungle of Honduras to lose connectivity. It can happen literally anywhere, in a parking garage, next to trees in a park, in the desert. Intermittent in a shopping mall, the list goes on. Also, I like apps being resilient.
I've done a similar app and this was basically the reason why I'm discontinuing the app. You didn't have a polished offline-first sync solution back in the days and my homemade sync code is a spaghetti soup.
I think there's something wrong with whatever bot/abuse detection you're using.
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.
My personal bias is that anytime I see on a software company's website footer that they're a GmbH, I know it will be selling high quality, durable, reliable software ;)
Congrats on your continued success!
Thanks! That’s funny, because while it’s technically a GmbH, it’s really just me — a one-person company.
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.
"Whether I’d do it again today, I’m honestly not sure."
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.
which Rechtsform would you expect instead then for "high quality, durable, reliable software"? :-D
I love this. I also built a business like that[0]. It's super niche. I have maintained this small business for soon to be 13 years now. Most of what has worked has been maintaining great relationships with the few customers I have. I think the most important thing for me have been offering amazing support. I always reply to all e-mails right away and make it my top priority giving them my best help.
Congratulations on your success, and best of luck going forward!
[0] https://www.mino.no.
Thank you — and congrats to you as well, that’s an impressive run.
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.
Thank you! I agree, it's so motivating to read stories like this. Thank you for sharing :)
That looks really cool. Seems like it could work for hotels or holiday apartments too, especially if they have smart home appliances?
Thank you! Yes, it definitely could. I haven't thought about holiday apartments.. Thank you for the good idea!
I thought holiday apartments like Airbnb would be the biggest use case when I first saw your site.
Nice project! I built a CLI budgeting project a long time ago, and what made me stop using my own project was the lack of automated integration with my bank accounts. At that point I had many credit cards, multiple bank accounts, in different currencies, and integrating all expenses was just too much manual work.
I wish financial institutions were better at automated exports of your financial data, given the right permissions of course.
That’s a fair point. Automated bank imports sound essential at first, especially with many accounts and cards.
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.
This is something I kept bumping into when building my own tracker (Simple Wallet - https://simplewallet.app).
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.
This was true, but today I would much rather have an llm categorize my expenses. Me doing it manually will never happen.
That’s fair — and I agree if enough context exists.
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.
Is there any chance it could become richer? What governs the content of credit card and bank statements? Is there anyone pushing for them to be more useful?
I think (granted, this is from a quick bit of research so I could be wildly wrong) - the message you see in your credit card app with a transaction is usually mainly the merchant name and location which is part of ISO 8583, so it may be a bit hard to extend it to include an arbitrary message in a way that works without merchants having to replace card reader/POS systems en-masse.
it's very sad that in Europe we have laws to guarantee "open banking" but in practice it's only B2B
one way to go around this is to use apps like Toshl which connect to banks (it is far from perfect but usable) and then if you are unhappy with the app you can use their API to sync with your own system
Just some constructive feedback. Your site needs a little bit of work on design and copy.
"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"?
That was also my first impression when I saw the site. The color scheme in general looked more like "boring b2b SaaS" and not a personal budgeting app and not really something where I'd look forward to spending a lot of time in (Which ideally you should in a budgeting app).
I think it could benefit from a personal, playful kind of touch to appeal to more mainstream users.
Indeed. The capitalization and punctuation inconsistencies are a huge turn off. My instinct was that people behind the software don’t have attention to detail.
I have been paying my bills by computer since the early 80s. The key feature I wanted was check printing. These days I only write about 3 or 4 checks a month. For the past few years I have been using Banktivity but they have gone to a subscription model so I expect soon my copy will no longer run. I use it mostly for cash flow planning. Mac based so I would have to gin up something in Numbers to track expenses. Not looking forward to getting Numbers to print checks. Are you aware of any open source budget app that might give me a head start? If Apple ever gets around to running iOS apps on my MBP I would certainly consider your utility.
Nice work. I started around same time as you 1996. I was selling professional dj software as shareware called ClubDJ Pro from 1999-2012 before coding for the app store as well.
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
Your is overly zealous about blocking people.
I've also been blocked on my home network (CO, USA). Any insight into how your block system is working?
The questions that come to mind for me:
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”?
Good questions. - The Android version came about two years after the iOS app. iOS was always my primary focus and the main success driver. - Both apps are 100% native. No cross-platform framework and no web views. It may sound more complex, but for me it was actually simpler and more controllable that way. - There is very little shared code between platforms. Concepts and ideas are shared, but the implementations are platform-specific. - The core app functionality is almost entirely on-device. MoneyControl works locally by design. There is an optional WebApp that adds device sync and a browser-based interface, but the server side is essentially limited to synchronization.
In short: native apps, local-first architecture, with sync as an optional layer rather than a requirement.
Wow, that is so rare these days (and not the answers I expected)! A tip of the proverbial hat to you for doing things "the right way".
(And thanks for the reply!)
> Unfortunately, our security system has detected malicious access from your computer to our website. For the protection of our system the access was temporarily blocked.
???
Small typo on https://primoco.me/en/price: "conenction to a paid WebApp"
Congrats! It's not easy to build something people want and will pay for. It's even less easy to do it for 10+ years.
That's all I wanted to say - as much of a milestone as version 10 is - the past 9 were amazing as well.
Some basic questions from a cybersecurity vulnerability researcher:
- 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!!
this is cool, but you have a typo under "Manage your finances with MoneyControl"
>Primoco ist not free and with good reason. Learn more about our offers and create your personal budget book with a free test.
`ist`
This really resonates. Long-term maintenance, reliability, and staying useful over years is the hardest part of building software — and often the most overlooked. Respect for prioritizing sustainability over hype. That mindset is what actually creates real products.
Interesting! I know next to nothing about iOS development, but surely there have been major changes in frameworks and expected look (often connected)? Which changes were there over the years and how and when did you follow them? Did it turn out good or bad to follow early / late?
Good question — yes, there were many major changes, both technically and visually.
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.
How do you market your software? Did you learn how to become a marketer and took it as a persona? What have you learned how to market your software in the past 20 years as a developer?
>The mobile apps (iOS, Android, etc.) can be downloaded from the app stores and tested free of charge. Simple in-app purchases or the conenction to a paid WebApp unlock the Premium Features.
Typo in 'conenction'
As a German - I'm sure you've looked into integrating FinTS and therelike? What made you decide not to integrate any of that?
That’s a fair point. Automated bank imports sound essential at first, especially with many accounts and cards.
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
Thank you!
Amazing to see such a long tenure in that competitive market. Thanks for sharing!
I wonder, apart from the normal exposure/distribution on App Store, what are the main strategies you've used for marketing?
Looks great, and I was also happy to see that it has offline capabilities and will sync once you have a signal. There needs to be more apps built using this model.
Thanks! I strongly agree.
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.
And people think you need to go to the jungle of Honduras to lose connectivity. It can happen literally anywhere, in a parking garage, next to trees in a park, in the desert. Intermittent in a shopping mall, the list goes on. Also, I like apps being resilient.
I've done a similar app and this was basically the reason why I'm discontinuing the app. You didn't have a polished offline-first sync solution back in the days and my homemade sync code is a spaghetti soup.
14+ years?
Congrats, really a long-run marathon!
your link to get the on ios app store isnt working.
Thank you very much for pointing this out? The correct link is https://apps.apple.com/app/id465909912
How many users?
Na, how many subscriptions/ARPU/churnrate and all this stuff are the relevant KPI here :-)
Maintaining it for 14+ years is a huge effort, so I expect somehow a stable business model behind it?