Actual is personal finance system with a simple system for budgeting and tracking finances. See exactly how much you are saving each month and track everything in one place.
Last week I launched Actual, a brand new personal finance system built from the ground up to be as simple as possible without sacrificing utility. While it’s new and missing features, people seem to get the idea. Now that it’s launched, I want to talk about where I want to take Actual from here.
First, a recap of the launch. It went really well. There’s a weird balance you hope to strike at launch: you want as much attention as possible, but hopefully not so much that your servers die. If your servers can handle any amount of traffic, you’ve launched too late. I was a little worried about the simplicity of my server setup, but it was perfect. Lots of attention, and a modest gain of users:
- ~90 retweets and almost 500 likes on announcement tweet
- #4 Product of the Day on Product Hunt (Sat at #3 most of the day, got bumped down right at the end)
- Almost 1500 downloads since launch
- 375 subscribed users signed up for free trial, with 12 already adding credit card information
It’s going to be very interesting what happens 3 weeks from now when the 30-day free trial period ends and I find out the app’s conversation rate.
The most surprising thing was how positive the feedback was. I’m familiar with how brutal the internet can be, but this time there was hardly any mean-spirited comments. There were criticisms for sure, but almost everyone was encouraging and excited about something new. I don’t know if this is the nature of the fintech communities, if I just happened to get my messaging right, or Product Hunt’s focus on positivity, but it was really refreshing.
I would have continued working on Actual even if the launch fell flat, but it’s certainly motivating and paints a bright future that it was so well-received. Especially considering I haven’t even mentioned some of the really killer features, which I intend to do in this post. Here’s the future I envision for Actual.
The first thing I want to talk about is sustainability. People are rightfully nervous about adopting such a new project because it might die before maturing into something stable, especially since I’m the only person behind it right now. Several things could happen: I could lose interest, a life change could force me into a different job, not enough people subscribe to sustain development, or anything.
Let’s address my interest: it’s not going anywhere. Back in 2013 I built my first prototype and have been building different versions since then. That’s six years ago. This is not a quick fad of an interest of mine. It’s not even a side project, I’m currently full-time trying to bootstrap myself.
While there are downsides to being a solo founder, it’s beneficial when bootstrapping because my expenses are so low that it’s much less difficult. Reaching that stage is very feasible — and if I can’t produce the amount of monthly income I need I think there are bigger problems like little interest in the product.
It would be riskier if I had taken VC funding for a wilder idea that needed to prove itself within a couple years. Those startups are seeking hyper growth and if they don’t get it, eventually crash and burn. I believe in slow and steady growth and envision growing a small team to build stable and useful products over a long time.
Until I reach profitability, I’m exploring other ways to unblock myself from Actual’s potential:
- Invest in the community by providing places everyone can interact, and allow them to play a large part in the product by listening to feature suggestions.
- Allow power users to build on top of Actual. This is talked about more below, but the idea is to empower users by letting them build their own features instead of embedding everything into Actual itself.
- Find an investor with the same beliefs. Getting funded is worth exploring. It certainly would help get the product off the ground, but I’m only willing to do it if the investor is interested in long-term growth.
I can’t guarantee anything about the future, but I’m here to work hard on making Actual into a success.
The future of Actual will be driven by the following ideas:
It just works. Focus on the core ideas and make them work as robustly as possible. Make it always work as expected, when possible. Teach the user with consistent and reliable interactions.
The interface should feel natural and relaxing. Don’t show millions of numbers unless absolutely required. Editing data should be quick and painless.
Don’t overwhelm users. Getting started should take minutes. Start simple and allow them to grow into anything complicated. They shouldn’t have to read books or learn accounting to simply track their personal finances.
The app is a tool to serve users. Ideally, users shouldn’t spend much time in the app because they got the answers they needed quickly. Be flexible and don’t force users to rewire their life to match how the app works.
Power users need an escape hatch. There will always be users who want more advanced use cases. Instead of complicating the app by building in big features that still don’t meet power users’ needs, provide a point of extensibility that allows them to build their own features (more below).
Here is an overview of the current plan. This may change over time, and if it does I’ll probably write a new post. For now, this is what I’m planning.
- Move backend syncing data into DynamoDB. This will provide greater reliability as the app scales, but most importantly data will be encrypted at rest.
- Implement end-to-end encryption. This is easier for Actual than most apps because there is already an initial “handshake” between devices when you copy the full budget. A key can be transferred at that time which will fully encrypt all messages sent to my server so that nobody can read them except you.
- Enable automatic transaction downloading. This is already implemented using Plaid but a few details need to be worked out before enabling. You need to commit to a minimum monthly fee so I wanted to wait until I had the paid plan available first.
- Flesh out the apps. Improve stability, fix a lot of little problems, and implement missing critical features (tracked here). Critical features include scheduled transactions, payee management, CSV import, and other smaller things.
- Expose an API. Provide an easy way to read and write your data. This is where having your data locally really starts to pay off — there’s no API keys, usage limits, or anything. All you’re doing is running against your local data. This will also allow people to build custom transaction importers/exporters.
- Linux version. Setup a workflow to test and deploy a linux version of the desktop app
- Prototype Android version. Begin porting the mobile app to Android. The hardest part here will be getting familiar with that world and learning the different design patterns. The code is already cross-platform, but getting the Android version right will probably take some time so this might not be fully complete.
- Forecasting. On the budget page, allow the user to “forecast” how much they will have in each category at a point in time in the future (this will be experimental and not guaranteed on landing).
- Some form of goals. Research the use cases for goals and work with the community to come up with a satisfactory design, and implement it.
- Finish Android app. The Android app will likely not be fully completed yet and need to polished into its final version.
- Better reports. Add more filtering options, add more types of reports like income/expense, and get reports working on mobile.
- Expose a spreadsheet language for custom reports. This language already exists inside Actual and will become an extension point for building your own reports and features. This is the most exciting thing about Actual’s future in my opinion and will unlock a whole new set of use cases. I will talk more about this in the future.
The app will continue to be improved stability and feature-wise in the long-term as well, naturally. The biggest impact is going to be exposing the custom language though, and will likely impact everything in ways I can’t see yet.
The reason I built Actual with a custom language is because when I was looking around at personal finance apps a long time ago, I liked certain things in each one but was frustrated that none of them were flexible enough for me to make up for things I didn’t like. Reporting is typically a rigid set of reports with simple filtering options. Each app also duplicates the entire transaction management functionality, so if I’m looking for different reports I have to adopt whatever that app’s transaction interface is like.
What if we built an app that made transaction management and the budgeting interface rock solid, and allowed users to build everything else on top of it? We’ll handle the few things that are hard to build yourself, and everything else is reports and features created by the community.
We’ll see what happens. For now, join the fun and help build the best personal finance tool there is. I’d love your feedback!
Originally published at https://blog.actualbudget.com on February 4, 2019.