Breaking Through to Refinement
Launching the first version of anything is a big deal and there’s plenty of popular advice on how to do it, most of which encourages creators to build as little as possible as quickly as possible. But there’s another approach, one where at the center is passion, craftsmanship, and faith in vision. This is how we’re building Spend.
Most product-related idologies encourage creators to build as close to nothing as possible to prove out an idea. The Lean Startup, in many ways the bible of Silicon Valley, encourages founders to build a Minimum Viable Product (MVP) to quickly test a hypothesis, prioritizing speed and validated learning over perfection or craft. Agile encourages us to “delivery early and often,” breaking work down into incremental pieces, often forgoing long-term vision. Google X famously provides bonuses to employees that can find the fatal flaw of an idea. I’m sure there are many abandoned startup offices, where words like “move fast and break things” and “fail fast, fail often” are still emblazoned on the walls.
The theory behind these ideologies is that most ideas won’t work. Rather than sinking a bunch of resources into developing something that’s destined to fail, pivot instead to one that will work.
But this is not the only way to build successful products. Sometimes we just know that a product has to exist. We face a problem on a day-to-day basis, have tried the available solutions, and know that something better needs to exist. This is why we’re working on Spend.
Morgan and I fundamentally believe that budgeting is the most critical tool to building and maintaining wealth. Yet, building a budget is hard and maintaining it over time is even harder. We think it should be easy and that has become our north star as we build and evolve this product. He and I trust that if we get what we see in our minds-eye into software, the rest will follow. This is not the Silicon Valley way. We’re zigging in a world of zags.
When we started Spend, we both had prototypes. Morgan had a spreadsheet-based budget that he used multiple times each week. His friends had even copied the template, which we saw as a positive sign that people needed help budgeting. I had also built a local web app that informed a series of direct-deposit rules so that money would end up in different accounts (essentially modern-day envelope budgeting) and by sticking to my budget I was ultimately able to buy a home.
Morgan’s spreadsheet-based budget
Avand’s budget app prototype, MyFi
When we came together, Morgan and I saw the vision but we weren’t even sure if we could build it. In our first phase of working together, we vetted our working styles and the technology stack. Did we like working together? Could we talk through difficult problems peacefully? Could we develop designs and technical solutions productively together? How well did Plaid, React, TypeScript, Firebase, and Google Cloud Platform play together? We decided to build a prototype to vet these questions and, about 3 months in, everything was looking good.
Our next phase was dominated by creating the cornerstones of our budgeting vision in code: boiling down a weekly budget to a single number, allowing over- or under-spending from previous periods to carryover, being able to recover the cost of emergency expenses, and to be able to set aside money for future goals. Based on our vision, these were the features we had to get right and, while we tried to build each of these features as quickly as possible, we also knew that building them such that they felt like integrated components of the whole product required a certain degree of craftsmanship too. I’d say we’ve struck a nice balance because we can still make big improvements in short-order without breaking everything.
It’s worth noting that this phase was hard. With 20/20 hindsight, it’s easy now to see the faster path but I think we did about as well as we could given that we were groping in the dark and there’s nothing like Spend out there to copy or use as a reference point. The only real lesson is to avoid “re-arranging deck chairs on the Titanic.” Practice zooming in and way out repeatedly to avoid polishing surfaces that will need to be re-cut.
Getting to a solid offering took about two years of nights and weekends. It’s taken a combination of gut instinct, user research, and iterative testing to get here. Neither of us had any idea that Spend would look exactly like it does now, and yet it has held its shape remarkably well due to our vision of what a budget app should be, how deeply a customer should be connected to it, how often they use it, and how integral it becomes in their life.
It’s not like we threw caution to the wind. From day one, we’ve focused on tracking user retention and sign up conversion. We’ve also made user research a regular part of our workflow. We’re not only trying to build the perfect budget tool for ourselves, we’re also on a mission to build the most popular budgeting tool in the country. So user feedback is vital as are the data that support our hypothesis.
With our Android and iOS apps about to ship, every fundamental aspect of the vision we had for Spend will exist. We’re nowhere close to done, but we now feel that we’ve truly started. Today, for reference, we’re on version 4.3.15. For those unfamiliar with semver, that means 4 major versions with significant changes to how the product works. Externally, we’d call this “version 1,” which is easy to do having also just rebranded to Spend.
To the extent that we’re still building product (we’ve switched most of our resources to growth), we’re focused on refinement: removing features that feel clunky, moving information around to make things simpler and easier to use, and adding little moments of surprise and delight throughout the experience.
Working on refinement is joyful for me. We get to go deeper into the details, find out which parts of our idea works and which don’t, what people love about it, and, maybe even more important, discover what we can take away. How can we make Spend even lighter and more delightful?
We like to think of ourselves as our first customers—we build the product to solve a need we had, and we use it every day, but the true test is whether you like it, too.
If you have ideas for what we should build next, feel free to email us with ideas.
Written by Avand, co-founder