Yes, I’m planning for the app itself to be subscription and/or one-time payment, but of course the database is all yours if you stop paying.
I haven’t used double-entry because I wanted to focus on spending analysis rather than account balances, and often bank statements are partial data. Would this be a deal-breaker for you?
I think this article misses the fact that the native date and time pickers look ugly in Chrome, and that a lot of websites are ultimately an extension of a brand, not just a tool where function > form. The Airbnb date range picker looking on-brand makes the experience seem a lot more slick. There are more things to optimise for than just accessibility.
I'm working on yet another spending analysis app. How will this one be different?
- Stores transactions locally in a SQLite database, so in theory you could build your own Front End if mine didn't do everything you wanted. Think someone who wants to do a fancy "year end summary" visualisation. And if you want to do a complex filter, can just write an SQL query to the database itself.
- Has a great UI.
- Allows you to write your own import connector and mix 'n' mash between locally-saved CSV/OFX files and APIs, rather than going down the standard route of only supporting Plaid. Current solutions leave users high and dry if the Plaid connector doesn't work well / they want to import old data (Plaid only gives the last 2 years I think).
Haha love it. Would love to see the IT guy's face handing that back in.
reply