In the previous post I described how we think the perfect app to write expenses should look like. Recently two months have passed since we started development of our own application, which is supposed to meet all these requirements. The time has come when we started our internal testing of our application.
We are still running the budget and writing down all our expenses in the Google Docs spreadsheet, but at the same time we started to record expenses in the Family Finance Tracker. In my opinion that this is a very big milestone for us, because we think, the application has already become usable. Of course, it still suffers from “childhood illnesses”, it has many areas to improve, which I still work on, but it already meets our basic requirements. It is time, therefore, to share with you the information what we have been able to achieve over these two months.
During first logging into the application, the so-called “File” in which we will record all expenses is created. The default name of this file is our email address, which we use to login. An additional, very important parameter of the file is the currency. The application automatically tries to detect the language used by the user and assign the appropriate currency. If automatic allocation fails, application will set the US dollar as default. You should pay attention to this setting, because it is the main currency that we will use when writing expenses. All amounts will be converted into it. If the app detects the currency incorrectly, you can change it in the settings, but only until the first operations are entered. You will no longer be able to change the currency later. The application allows you to define any number of such “files” and switch between them in the “Settings” tab. We can therefore keep a separate record of our family’s expenses, a separate register for our activities, and a separate one for our child, for example. You can share each of these files with any number of users. All you have to do is send an invitation to share the file to the selected email address. The person who logs into the application with the email address provided, will automatically be able to switch to the shared file in the “Settings” tab.
Categories are probably the most important element of the entire application. Adequate categorization not only allows you to conveniently writing down the expenses, but also helps with a comfortable analysis and drawing the right conclusions. You can take several approaches to the topic. If You do not have experience with writing down expenses and are afraid that it is too complicated, You just can define only a few main categories. When we want to more accurately analyze our finances, a more extensive division is necessary. We prefer the second approach and that is the method we will promote, but the application also provides the opportunity to simplify the list of categories. At the first launch, a default file will be created to which a predefined category set is stored. The categories are stored in the automatically recognized language. As I wrote, at the beginning we only support Polish and English, but we plan to add add new languages in the future as needed. We have prepared the default set of categories based on the sheet of Michał Szafrański, which we use every day. It worked very well for us, so we decided it would be a great starting point for our application.
The default set of categories:
- Partner salary
- Bank interest
- At home
- At work
- In the city
- Sweet drinks
- Flat / house
- Water and sewage
- Garbage collection
- Maintenance and repair
- Car equipment
- Car insurance
- Regular clothes
- Sport clothes
- Cleaning products
- School tools
- Additional classes
- School payments
- Toys / games
- Gym / swimming pool
- Cinema / Theater
- Hotel / Tourism
- Other expenses
- RTV equipment
- Education / Training
- Other services
- Repayments of debts
- Mortgage loan
- Consumer loan
- Personal loan
- Emergency fund
- Irregular Expenses fund
- Financial cusion
- Retirement account
- Overpayment of debts
As you can see, the default categories set is quite extensive and I encourage everyone to adapt it to their needs after the first login. Below is a video that presents part of the category management options:
The film was recorded from the browser version of the application. The main categories are marked with colors. The green color means the revenue category, the red color is the expense category. The assumption is that we will enter all amounts without any sign. It depends of the category type if the position will be treated as income or expense.
Categories can be freely moved, added, renamed. However, there are some limitations. The category type can not be changed. If you incorrectly specify the type, delete the category and enter it again. In addition, you can not delete a category if you have already added any operations to it. In order to delete such a category, we must transfer all operations to other categories. Only then the deletion of the category will be possible.
Our assumption from the beginning was that we do not want to create applications in only one language. We would like to reach the widest possible audience. We create the website and blog in both Polish and English. It was natural, therefore, that the application must also support multilingualism. At the moment, We support both of the above-mentioned languages. Therefore the application is fully adapted to support any number of them. At the first login, the browser / phone language is recognized and the application verifies whether the language supports it. If so, it is set as default. If not – English is set. After starting the application in the “Settings” tab, you can change the language of the application without the need to restart. The change applies only to the application interface – categories do not change. This is not possible because the descriptions of the category can be freely edited – therefore it is not possible to easily translate them automatically. The functionality from the testing version can be seen in the following video, which was recorded on a mobile device (Android).
For each operation that we will write down in the application, it will be necessary to allocate the payer who performed the operation. In the application, you can define any number of payers. For example, all family members, even those who do not write out their own expenses in the application themselves. You can freely modifiy, add or delete payers. However, You cannot delete the payer to whom any operations have already been assigned. In this case, it is necessary to rewrite operations on other payers. Only then will the removal of the payer be possible.
I think that at this point I will finish the first part of the functionality description. In the next post I will try to show you how we define accounts, how we have implemented support for any currencies. I will show how you can do transfers between accounts, and how to list and view operations. As you can see the application is already at a quite advanced stage. As I wrote at the beginning, we have already started our internal tests. We have a plan to release the first public beta very soon, We will send invitations to the subscribers of our newsletter. If you want to test our application by yourself, sign up for our newsletter at: https://join.familyfinancetracker.com/
Przemek · November 8, 2018 at 10:40 am
Cool! I wanted to ask you a few design and technical questions if you don’t mind (I was also thinking of writing an app like that, Google Sheets are not enough after some time):
1. Where do you store the user data (expenses, income records)? Is there a DB on the server or is it a local file?
2. If it is local, how do you manage the synchronization between web and mobile app?
3. What technology do you use for both apps?
Anatol Ogórek · November 8, 2018 at 11:15 am
There will be dedicated post about technology very soon, but in few words: I store data in postgresql server. In production it will be in a cloud, currently in tests it’s on my serwer. I write backend in Java and springboot. Frontend is written in Ionic, so there is one code base for web and mobile
Przemek · November 8, 2018 at 12:07 pm
Thanks, I am waiting for the technology post then 🙂
One thing I was wondering about with this approach (DB in the cloud / global server) is that the data that the user stores there are kind of sensitive (income, expenses for different things). Did you consider encrypting this data so that noone but the owner can access it in plaintext form?
My two approaches were:
– have the user store his data DB locally (google drive, dropbox, whatever), but that raises problems in terms of accessibility via mobile and web app.
– have the data stored in an encrypted way (db just stores a binary blob that cannot be decrypted even by the admin), the data is sent to user and decryption happens on client side. The problem with this approach is how to store the encryption key and what if user fogets / loses the key 😉
Anatol Ogórek · November 8, 2018 at 1:26 pm
Yes, I was thinking about it, and I’m aware that it might be an issue for some people.
First of all, I’m going to gather as little private data as possible. The only required data to start using an application will be email address – required to log into an application, nothing more. So it will be possible to create an account with some new email used only for this app – and then it will be very hard to connect a person with application data. I hope it will be enough for most people.
Ofcourse it is possible to generate some key on client’s device and encrypt/decrypt data with it, but it raises a problem not only with loosing/forgetting but also with exchanging it between devices, because in my opinion access to data for it’s owner should be as simple as possible – from any device.
And about gdrive, dropbox – I plan to use it for storing photos of receipts and invoices – but it will be a little later. Now I’m working on basic functionalities 🙂
Roger · November 9, 2018 at 8:50 pm
“So it will be possible to create an account with some new email used only for this app – and then it will be very hard to connect a person with application data.”
Well, theoretically yes but there’s also an IP address and that combined with the application data is already a lot.
Anatol Ogórek · November 9, 2018 at 8:58 pm
Of course you are right.
Currently I do not have better solution, but it is the same with most of online application where we leave our (very often sensitive) data.
If you have any reasonable solution to this situation which will not have large influence to usability I will be very glad to hear about it and implement it in application. I’m open to any propositions
Roger · November 10, 2018 at 12:07 pm
I’d personally prefer an offline application that stores encrypted data on my device only (be it a desktop app or a mobile app), even at a cost of no synchronization. But I understand that for some users synchronization is important. Eventually a solution that stores the data in my icloud (from Apple), as to my understanding Apple can’t decrypt it (but I might be wrong here).
Anatol Ogórek · November 10, 2018 at 1:30 pm
I understand that approach.
I like comfort of synchronization and sharing access between family members, and in that case – when data is in the cloud, encryption and decryption might be an issue, because for example in some functionalities I might need access to data for some grouping, sorting, summing or charting…
We already give a lot of our data and privacy for example to banks using online access. I know that banks have huge budgets for security, but there is always a risk.
The only thing I can say, is that I’m fully aware of possible users’ concerns and security is my priority while developing this application.
Roger · November 10, 2018 at 2:15 pm
“The only thing I can say, is that I’m fully aware of possible users’ concerns and security is my priority while developing this application.”
Roger · November 23, 2018 at 7:57 pm
And maybe the sync (and thus off-device storage of data) will be optional? That way both users willing to have synchronization possibilities and users who don’t want to upload their data anywhere will be satisfied? Just an idea.
Anatol Ogórek · November 26, 2018 at 1:52 pm
I base on assumption that application works using SQL database, so unfortunately that might not be possible 🙁