When you are first starting out with a new idea, often the advice is given to “build the MVP (Minimum Viable Product) of your idea”. But sometimes the MVP (Minimum Viable Product) of your idea can be a little ambiguous. Do you need user management? Integrations with other apps or APIs? A mobile app? Which core app features do you build and which ones do you put aside?

What does “minimum viable” mean in the context of your idea? The lines are often fuzzy, and the phrase “MVP” does not always help you draw the lines clearly around which features are important to ship and which ones are not.

A personal philosophy that I use when building my ideas instead of “build the MVP” is build the simplest thing that could possibly work for one use case. I find that this distinction, while small, is a bit more concrete in my mind while thinking of new ideas to build.

Find the Core Value Proposition

For example, when building BudgetSheet, the single most important use case to solve was linking bank accounts and getting bank data into a spreadsheet in a useful way. That is the sole feature that I started with and launched the first version with.

Over the years since launch I have since added a lot more features to BudgetSheet like monthly budgeting sheets, account balance tracking, custom transaction categorization, etc. but the core of BudgetSheet remains the reason that the vast majority of people use it and buy it today. Automating the import and formatting of bank transactions. It will always be the #1 job people look for the app to do, because it is the core value proposition.

Make sure the core value proposition you pick is a painkiller, not a vitamin. People will more quickly and easily pay for something that solves a real pain than something that is a “nice to have”.

Pick a Distribution Channel

I launched BudgetSheet on the Google Workspace Marketplace as a Google Sheets Add-on because I know that I am a much better developer than a marketer. The existing marketplace is a built-in distribution channel that makes user acquisition much easier for me, and allows me to focus more on building a better product.

Launching my idea as a Google Sheets Add-on enabled me to laser-focus on my core value proposition and even allowed me to launch without building user accounts into BudgetSheet. This cut out a significant amount of things that I had to build, account for, and support. When the extension is installed, BudgetSheet just uses the current logged in Google account and gets an email and spreadsheetId that is used to track linked banks and upgrades per spreadsheet. Since the app exists entirely within Google Sheets as a persistent sidebar, this works out very well and is a super low barrier to entry for new users – they don’t have to setup another user account and remember another password to use BudgetSheet! Users just install the extension, run a quick automated setup, and start using it immediately.

If I had tried to launch my idea as an entire standalone app, the path would have been much more difficult and would have taken much longer both to build and get real traction. The competition in the personal finance space is also a lot more fierce as a standalone app vs. an Add-on that is tightly integrated into Google Sheets. The distribution channel that you pick can be key to early success. Choose wisely, and think long and hard before building a standalone app.

Get Validation (Money)

Money is really the only validation that matters, because it is the only thing that will get your idea to a default alive status. If you nail the core value proposition and solve it well with your launched idea, then you should have no problem getting people to see the value and pay for it. You can charge a smaller amount for your product at first just to test the waters or get traction, but you should absolutely charge money from day one.

BudgetSheet started with only manual bank imports at $5 per month. It was pretty difficult to use. Users had to signup with their own Plaid accounts and plugin their own API keys in a specific place in a specific spreadsheet. It involved many manual and error-prone steps. But there was so much value there that people signed up and paid anyways.

Grow & Build After Traction

After if it clear that your idea has traction and users (i.e. is solving a real problem that people will pay for), then you can start building more and branching out from there.

Don’t waste months or years of effort building huge, elaborate apps with tons of features or integrations before you have validated the idea itself. Start with the simplest thing that could possibly work for one use case, and then grow and build from there. 🚀

Credits: Cover photo by Kelly Sikkema.