67
42 Comments

How I Built a Google Sheets Extension Making $1.6k+ MRR

I created and run BudgetSheet, a Google Sheets Extension currently making $1.6k MRR and growing. If you have ever wondered if there was money to be made with extensions and addons, there absolutely is! Here's how I built BudgetSheet:

Pick The Right Problem

BudgetSheet was born of frustration. I used many personal finance and budgeting apps, but was frustrated with all of them. Mint is free, but constantly spams you with credit card and loan offers and doesn't have great budgeting tools. YNAB wants you to budget their own specific way. EveryDollar was slow and had a clunky UI that took 5+ clicks and a bunch of time just to re-categorize a single transaction. Multiply that times 200, and it was rage inducing 🤬. All I wanted was my own transactions in my own spreadsheet! In a spreadsheet, I could blaze right down the "Category" column and re-categorize my 200 transactions in a few minutes! Why wasn't it easier to just use a spreadsheet for this? Clearly this was a problem that needed solving!

Explore The Idea

Extensions and addons can be fairly limited by the platform you are building into, so you need to make sure what you want to do is even possible first. I scratched my own itch and built BudgetSheet after about a week of experimenting to see if it was even possible with Google Apps Script. Building something like BudgetSheet was not only possible, but I discovered how awesome and powerful Google Apps Script is (seriously!). It would let me do so much more than I ever thought possible - all with no hosting costs or web service to maintain! Once I realized that it was possible to build what I wanted using 100% Apps Script, I got to work. After about another month or two, I had a good first release on the Google Workspace Marketplace.

Charge Money

Screen shot of Gumroad metrics

Money is the ultimate validation. People will tell you all day long how cool your product is, but things get real pretty quickly when you ask for money. From the start, BudgetSheet has had a paid upgrade plan. The free version allowed users to connect 1 account, and the paid Pro version was required for connecting more than 1 account.

BudgetSheet v1.0 was actually pretty awful. To use BudgetSheet, users had to go sign up for their own Plaid developer account, get their own API keys, plug them into a certain place in a "BSA\_Settings" spreadsheet (the extension created this for you), and then connect all their bank accounts in dev mode to even get started. It was a ton of manual work, and was very error prone! Despite all of these ridiculous hoops to jump through and a lot of early missteps, I not only got my first paying customers, but my free to paid conversion rate was 4%!

If you are looking for specifics, the easiest way to take money within the context of an extension or addon without having to build a payment page or web service is to:

  1. Use a Gumroad link for payments along with their Gumroad License Key service. This will generate a new unique license key per sale that will be emailed to the user.
  2. Add a screen or a form for the user to input their license key. Use the Gumroad License Key API to ensure their key is valid.
  3. Set a flag in the extension that the user has paid and record their license key (I used Document Properties in Google Apps Script)
  4. Add logic gates around paid features that check for that flag being set
  5. ???
  6. Profit!

Focus on Stability and Quality After Validation

Now that I knew the idea was possible AND that people would pay money for it (yes! 🙌), it was time to re-build it with a focus on stability and quality. I could now fully justify investing a lot more time into this little side project of mine to build it into something bigger.

Around the same time I was evaluating all the different approaches I could take on this, Plaid reached out to me. I had gained so many users so quickly that Plaid had taken notice that I was having end users sign up for developer accounts, and reached out to me directly to let me know (very gently and graciously) that was a violation of their terms of service. They were actually pretty impressed with what I had built, and were in the process of building something similar for Microsoft Money.

I spoke back and forth with Plaid a bit about expectations and timelines with me as a solo dev with a family and a full time job, and they gave me nearly 8 months to re-build the whole extension around running all the connections through my own Plaid account and paying for them (the proper way!). The phrase "It is better to ask forgiveness than permission" has never been more true in my entire life. This required a complete re-architecture, running my own web service, database, etc. - the whole deal. No more freeloading on 100% Google Apps Script and no Plaid fees (directing end users to setup their own Plaid accounts had allowed me to bypass them)!

The new setup was a lot more work, maintenance, and cost compared to the 100% profit margins I was enjoying doing things the freeloader way, but it was the right thing to do. It was time for me to put some real skin in the game on this and build out a proper web service. The end result was much higher stability for bank connections and transactions, and a much nicer onboarding flow for my users with fewer manual steps. Since I could control the runtime, I could also run things faster (Apps Script is great, but it runs slow!), longer (Apps Script has low script timeouts!), and do more than I could previously - like support oAuth bank connections that required a stable URL endpoint.

Use Leverage Where Possible

As a lifetime developer of 20+ years (I started very young!), my strength is on the code and tech side of things and almost non-existent on the sales and marketing side of things. Creating an addon was a perfect solution to this, because Google has over 3 billion users and provides a built-in marketplace and distribution channel to funnel users straight to me without me having to lift a finger.

Naming is important for discovery both in the marketplace and SEO. So I chose the name "BudgetSheet" to leverage those looking for tools that helped them budget in spreadsheets. Strong brand names are ultimately better in the long run so I may re-brand at some point, but I think this name that is more specific to what I am targeting has really helped me get a great start.

Time is the most precious resource, and I knew that my time was going to be seriously constrained between my family, my full time job, and growing BudgetSheet on the side. When building out the web service, I made very specific technology choices like Serverless tech with Next.js and Vercel that would completely eliminate me worrying about servers, software upgrades, uptime, SSL certs, scaling, capacity, etc. I also use Amazon AWS RDS for PostgreSQL. Now I can focus nearly 100% on the product, the code and data without any concern for servers or deployments. Vercel and RDS have been well worth the cost for the piece of mind they offer and the time the save me.

Have Fun

BudgetSheet is a joy to run. As a spreadsheet lover myself, I often think to myself "these are my people" when a user sends me a cool formula or shares charts and graphs of things they have done with their finances using BudgetSheet. I love when users share these things or just pass along some nice comments. It's an amazing feeling, and it is consistent validation that BudgetSheet is solving a real problem for many people.

Seeing real traction and getting such positive customer feedback is such a game changer. I have launched many things over the years, but BudgetSheet is by far the most fun startup to run out of all of them. It is also the only one to grow so much organically.

Make a good product that you are proud of in a space that you love, and you will have fun running it along the way. It's the best way to stay sane and do what you love.

If you made it this far and you like spreadsheets, check out BudgetSheet! It's free to try for 45 days, so there is nothing to lose. Who, knows? You might like it!


PS - This is also posted to my blog if you want to check it out there!

  1. 6

    Love the story, thanks for sharing, sounds like your running your infra on AWS, keep in mind that as a Google workspace creator you can fill out some paperwork that is hidden deep inside GCP documentation and they will provide you with 6k of GCP credits a year to run your addon.

    The program is called -> Google Cloud Partner Advantage it does take some time to navigate the process but well worth it in my mind.

    1. 1

      Thanks for sharing! Interested in getting a link if you have it somewhere. I couldn't find that on the documentation :/

    2. 1

      I didn't even know about this! Now I will have to look into it 👀

      The reason I chose AWS is because I use Next.js deployed to Vercel, which also uses AWS. I wanted the PostgreSQL database to be as close as possible to the code (serverless AWS Lambda) so that it would be very fast. Right now I am only paying $20/mth for Vercel Pro and around $28/mth for AWS stuff (resources beyond the free tier), so it's not bad. I may look at those GCP credits though as I scale out more. Thanks for the tip!

  2. 5

    Hey Vance - great work. I've also built a few Google sheet add-ons (PrestoText.com, MyCalTracker.com). I'll have to investigate the Gumroad option next time around.

    I've used Stripe and to validate the subscription, I just call their API to check if their subscription is valid. I use Session.getActiveUser().getEmail(); to get the users email and then check the endpoint 'https://api.stripe.com/v1/customers?email=' which returns data in jsonObj["data"][0]["status"] (with a step in between). As you said, just throw in some gates and voila you make sure only paying users are getting access.

    Thanks for sharing your story - I'm excited to follow along (there's no subscription/sign up on your blog page... you should add one!)

    1. 1

      Curious in what's your expectations with your add-ons in term of revenue. There are already some add-ons that let you sent sms for example.

      1. 1

        There were a few things different about my solution, that in my opinion, made it a better solution.
        The main perk is BYON - bring your own number. My solution was built on Twilio API. So users would just go and buy their own number. This had 2 benefits and 1 drawback. By having your own number, you could control what happened when someone responded to an SMS. Many other SMS add-on solutions use a shared number, so your customers can't respond. This also has the drawback that if someone else using the add-on gets the number blacklisted, you also get blacklisted. The other, major perk is that you then pay for your own SMS costs. In the US/Canada Twilio is like $0.0075/message, whereas many of the other add-on's were $0.05 or more. Adds up if you are sending hundreds/thousands of messages. The drawback is that the user then has to sign up for Twilio, buy a number, get their secret keys and insert them into the sheet (which might not be easy for everyone even though I provided a walk through video).
        So my idea was to simply just charge $5/month for access to the add-on whether the user sent 15 message or 1500.

        1. 1

          Interesting! Thanks for sharing your thoughts

    2. 1

      Hey (shameless plug), but I've actually built a product that besides handling churn and upsells also does this!
      It checks wether the user is active, canceled or delinquent and takes appropriate action. You can check LlamaFi on my profile.

  3. 3

    I like this. Found a problem, released early (without tinkering and polishing it for 20 centuries!), got feedback and then built and polished on the knowledge that people need this and would pay for it.
    This is how it should be done! Good luck in future projects!

    1. 1

      Thanks for the kind words and encouragement! I have definitely made the mistake before of waiting too long to release something. Not this time! :)

  4. 2

    Super long time Google Apps Script engineer and it is so slept on! Glad you've had success in the space.

    1. 1

      Yes! There is so much opportunity in this space for other things too!

  5. 2

    It is so nice to see I am not alone in the Google Apps Script journey!

    I am in a really similar position, I built Notion2Sheets which allows you to sync your Notion databases with Google Sheets among other things, I have ran into so many issues with Apps Script but it was worth it, happy to have a chat :)

    1. 2

      We scaled Chromebook Getter to over 2 million installs but found we had to rewrite the application due to issues with app script. We now use app script as a placeholder to make API calls to cloud functions that then use the google sheets API under the hood. Doing things that way has allowed us to remove all the weirdness of google app script from our project. Just something to note.

      1. 2

        100%, I use Apps Script for the UI only and all the processing is done from Cloud Functions. The only thing is that I have to ask users to authorize spreadsheet access again for offline access.

        Took a while to be where the app is at now 😅

      2. 1

        I am also actively going down this route. I went from 100% Google Apps Script starting out down to around 20% now and looking to lower that number a bit more in the near future to where GAS is only the binding glue for data between the sheet and my web service.

        Moving most of the work to the Sheets API that my web service talks to is my next large task for BudgetSheet that I think will really help with those last bits of occasional instability and slowness.

  6. 2

    Cool, thank you for your story! Loved quote "Money is the ultimate validation"

  7. 2

    Love the way you shared your story and congrats on the success!
    I love hearing "joy" attributed to a money-making side project - that's the whole point!

    What are your plans next? Are you going to try building something else or just grow BudgetSheet?

    1. 1

      For now the plan for me is to continue to grow BudgetSheet with a better UX, better onboarding flow, and expand it to support UK and EU banks and integrate other banking vendors as well.

      I did also have to build a serverless database proxy service with managed connection pooling to keep things fast for end users and lower the number of simultaneous connections to my database (Serverless tends to use too many connections as you scale - min. 1 per lambda instance running). I might eventually open that up for others to use as well, but that is for another time since that is a mission critical service that I am not ready to support for other users right now :)

      1. 2

        That's great! Oooh, haha one side project begets another so quickly.
        Excited to see the new updates!

  8. 2

    Haha I actually NEED this!~ thank you

  9. 2

    Really cool to hear your journey. Thanks for sharing.

    I'm in the process of building a niche product and am planning to use Gumroad license keys for members. It's great to hear it worked well in your (epic) stack!

    Also as an engineer first developer (marketing is always a work in progress!), if you have time, I'd love your input on ways I can market this.

  10. 2

    You expose a pretty cool stack here. Had no idea gumroad had this license thing, for starters! Solid article :)

  11. 2

    Great read about a neglected developer revenue path. Building a startup mouse on the shoulder of a tech giant does mean you can be squished, but there's just not enough money in your app to warrent it.

    Again, great read! So how do you handle support?

    1. 1

      Bob Walsh? Like, the Micro ISV Bob Walsh who was doing this "Indie Hacker" thing long before that was even a phrase? You are a pioneer, man! I started when I was 12-13 years old and followed your blog back in the day. Small world!

      Thanks for the praise! I handle support via email right now, and the load is pretty light for how many users I have. The nice thing about an addon is the much smaller surface area of the app, so I don't have to deal with things like users, passwords, accounts, etc. which really helps my support load.

      1. 2

        That's me! Thanks for the praise! I'm looking at indiehackers and like what I see: expect to see more of me.

        I think that going from developer to founder is a monster hard career path: doing what you've done with BudgetSheet is an example of adding a great waypoint along that path.

  12. 2

    Naming is important for discovery both in the marketplace and SEO. So I chose the name "BudgetSheet" to leverage those looking for tools that helped them budget in spreadsheets. Strong brand names are ultimately better in the long run so I may re-brand at some point, but I think this name that is more specific to what I am targeting has really helped me get a great start.

    This is really interesting. But what do you mean by a "strong" brand name? Surely, being discoverable is already a great strength to have - in what way are you thinking of changing it to make it stronger?

    Awesome story, Vance, thanks for sharing.

    1. 1

      Strong brand names almost always win in the long run. Think about the companies around today:

      • Google, not SearchEngine
      • RobinHood, not StockTrader
      • Starbucks, not GoodCoffee
      • Shopify, not OnlineStore

      If I ever want to expand a bit beyond the personal finance and budgeting space, then I will have to rebrand at some point. I am thinking about this now, but not ready to take action on it yet. I thought it was worth mentioning regardless.

  13. 2

    Very interesting.

    1. Would love to know, how you have marketed your product to get early paying subscribers.
    2. How long does it took to reach $1.6k+ MRR?
    1. 2
      1. I have not actively worked on marketing that much! I have done a few ads here and there, but I have mostly focused on leverage and the addons/extensions marketplace. Read the "Use Leverage Where Possible" section :)
      2. It took me about 2 years to reach this point. I suspect I could have been here a lot faster with more active marketing efforts, but I have a family and a full time job that I love as well as this, so slow and steady growth is best for me right now.
  14. 1

    This is legit. I totally feel the frustration using Mint. We run all our family finance through google sheets and still manually export/import transactions. Might give this a try myself.

  15. 1

    Amazing concept. Thanks for sharing and congrats for your work.

  16. 1

    Hey Vance, congrats on your success! Thank you for sharing. I also build tools in Excel, mainly financial models for startups. You find them on finmods.com. Have a great day!

  17. 1

    We have a feature in fabform.io that allows you to submit form to Google Sheets

    I never though of putting in the Google Workspace Market place

    Is that a long process?

    1. 1

      Not that long. You can start from here: https://developers.google.com/workspace/guides/get-started?hl=en - The documentation is really well made.

  18. 1

    Very informative.

  19. 1

    You might be onto something big here as well. In the project management space, for example, things started with fixed/unflexible tools and now some of the most popular PM software are basically Google Sheets on steroid (Airtable/Smartsheet). Wondering if the same will happen in the personal finance space.

    1. 1

      I have definitely seen more spreadheet-like apps out there - that's for sure. As far as things directly integrated into an actual spreadsheet like BudgetSheet, I don't know.

  20. 1

    What stops people from re-sharing once they get the code?

    1. 2

      They don't get the code. It is distributed as a Google Add-on for Sheets and installed directly into a user's Google Sheet. The end users never see or get the addon/extension code.

Trending on Indie Hackers
How I Launched My AI Startup with a Warm Email List and Zero Marketing Budget? 27 comments What you can learn from Marc Lou 19 comments Here's how we got our first 200 users 17 comments Software Developers Can Build Beautiful Software 10 comments Worst Hire - my lessons 8 comments Transforming Habits: What I Learned from 90+ Days of Regular Workouts 7 comments