DEV Community: Vance Lucas

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

Vance Lucas — Mon, 23 May 2022 01:55:34 +0000

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

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:

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.
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.
Set a flag in the extension that the user has paid and record their license key (I used Document Properties in Google Apps Script)
Add logic gates around paid features that check for that flag being set
???
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!

Work Hard and Don’t Burn Bridges

Vance Lucas — Wed, 09 Jun 2021 14:43:33 +0000

On a cold December day in 2014 I got a random call from a contact that had lay dormant in my phone for 12 years. It was Ryan, the owner of Element Fusion – a company that I had worked for in the summers of 2004 and 2005 while I was in college. NetSuite had recently acquired Element Fusion (EF) and they were looking to hire JavaScript developers to help build a custom Content Management System into NetSuite’s E-commerce platform. It was good timing for me. It was big and ambitious – full of challenges and unknowns. We talked for a bit on the phone about the opportunity and what was needed. I went in for an interview, and took the job. Things went well – really well. After about a year of hard work leading and implementing the new CMS architecture, I was promoted to Principal Software Engineer and JavaScript Team Lead. I stayed there almost 4 more years before moving on – completing all the code changes I wanted to make, coordinating with the Uruguay office (and their half of our product), building the product and leading the team.

The somewhat insignificant 6 months of work over 2 summers during an internship lead to an opportunity that transformed my career. I had always written a lot of JavaScript, but never full-time before NetSuite, and never exclusively on the front-end – I had always been a full-stack developer in every previous job, and even in the freelance consulting I did as well. My time at NetSuite enabled me to re-shape my career into an expert front-end/React developer and a effective team leader that was able to get some pretty hard things done and change the trajectory of the product we were building to a much better one than the course it was on before I got there.

Thinking back to my internship at EF, I did some good work while I was there. learned a lot, and made a good impression. At the end of my internship in 2004, I was invited to return as an intern again the next summer (2005). At the end of my internship in 2005, EF wanted to hire me full-time, even while I was still in college. They were confident they could make everything work around my schedule. I thought about it for a while, but ultimately turned it down. I didn’t want to have a full-time work commitment while trying to focus on my studies in college and getting my degree. EF was also deep into the Microsoft development stack with ASP and .NET, which was interesting to learn, but I did not want to work in the Microsoft tech stack full time back then. I preferred open source tech stacks like JavaScript, PHP, and MySQL and wanted to advance further with those. I was direct and upfront with Ryan about all of this, and left on amicable terms. Though our parting in 2005 was friendly, I never expected to work there ever again.

Fast-forward 11 years later, and I was working for Ryan again after a single phone call. I got a handsome salary and RSU package – just because (1) he remembered my strong skill set and good work ethic, and (2) now that NetSuite had acquired them, they had to develop a new product and integration with an open source tech stack and needed deep JavaScript expertise, which I now had by focusing on it for over a decade. But (3) most importantly, I didn’t burn a bridge when I left, and I left a good impression when I was there. This was even though I didn’t like Element Fusion’s tech stack and was pretty sure in 2005 that I would never work there again because of that.

Never burn bridges. You never know where they might lead in the future, or if you will ever need to cross them again. Always do your best work , even if it seems futile. Even if the work itself doesn’t ultimately matter, people around you will notice and remember. People move jobs, companies get bought, and things change. It could lead to an amazing opportunity in your future, even when you least expect it.

The post Work Hard and Don’t Burn Bridges appeared first on Vance Lucas.

How to sleep() With Promises and async/await

Vance Lucas — Thu, 10 Sep 2020 15:25:42 +0000

Occasionally you may find the need to sleep for a bit or use setTimeout in your code or your test suite if some async work is going on that you know will finish during that time (like a quick deferred function or something like that). Here’s an easy way to do it:

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

And now you can use it wherever you need to like so:

await sleep(1000);

Caveat : Keep in mind that generally random setTimeout calls are a code smell – ideally you would know what you are waiting on and chain things up to happen after that work is done, or orgainze your code so that you know what you are waiting on specifically. This sleep method is for those times where that is not possible.

How to Fix Git fatal: The current branch has no upstream branch

Vance Lucas — Thu, 20 Aug 2020 15:44:38 +0000

If you constantly get the following git error message after attempting a git push with a new local branch:

fatal: The current branch <branchname> has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin <branchname>

Then the issue is that you have not configured git to always create new branches on the remote from local ones.

The permanent fix if you always want to just create that new branch on the remote to mirror and track your local branch is:

 git config --global push.default current

Now you can git push without anymore errors!

Scorched Earth: Quitting Twitter and Deleting Everything

Vance Lucas — Wed, 05 Aug 2020 16:48:22 +0000

After getting into yet another stupid and pointless opinion scuffle on Twitter where no one wins, I decided to pull the plug and just quit Twitter completely for a while.

It’s not really the specific exchange of tweets that was the issue this time because it was honestly pretty mild and not super antagonistic. It’s just that I finally fully realized just how completely pointless it all is, and what a massive waste of time it is. No one wins or proves anything, and no one changes their mind. The only thing achieved is that everyone gets upset and mad at each other, misunderstands each other, takes the other person’s text to mean the worst possible thing, and talks past each other. So in the end it’s actually worse than pointless. Twitter is great for some things, but most serious discourse on Twitter is actively harmful.

With social media, we spend more time reading other people’s random opinions and knee-jerk reactions to current events, and less time reading carefully considered thoughts and factually informed opinions from experts and experienced professionals. It’s exactly the opposite of what we as a society should be doing.

I finally got to a point mentally where I could not in good conscience continue participating in this madness. Time is precious. Don’t waste yours anymore.

Delete all your tweets and likes

Quitting Twitter wasn’t enough for me. The whole ecosystem is so bad that people are actually incentivized to trudge through all your old tweets and textual vomits, and then weaponize them against you. I’ve seen it happen over and over and over. I have always been relatively careful of what I publicly share and most of my strong opinions aren’t too far away from mainstream anyways so I am not too concerned about this. Nevertheless, the risk is still there no matter what because popular opinions change over time.

The only real solution to significantly reduce or eliminate this risk is to delete everything. So I did this, and then wrote a separate post on how to delete all your tweets and likes from Twitter if you are interested in doing the same.

Is This The End?

Not quite. I am not going to interact on Twitter at all (no tweets or likes, etc.) for a while – I am not sure how long. At least a few months most likely. However, I am still keeping my Twitter account itself, and may check my feed once a week or so to keep a pulse on current events (something Twitter does well). I may also hook up this blog to it to auto-post any new blog posts that I write for a little extra exposure for those that still follow me on Twitter.

As much as I have just riffed on Twitter in this post, it still does have its uses. I have made connections and had some real interactions with more of my industry peers on Twitter than I ever did with LinkedIn – a social network with the explicit purpose of professional/work connections (what does that say about the state of LinkedIn?).

If/when I do come back to Twitter, I will take an entirely different approach to it. I can’t allow myself to get sucked into it again the same way I did before. I am still thinking through what that might be or what that would look like. I don’t want to get sucked into Twitter again, where I am just mindlessly scrolling through my feed and posting whatever thoughts come into my mind at the moment.

Moving Forward

My ideal future would be more blogging and long-form thoughtful communication; less off the cuff remarks and knee-jerk reactions. The things you and I post online are forever. They should be our best thoughts, tempered with wisdom, viewed through the lens of reality and facts. Social media as it exists today isn’t built for that. It doesn’t seem like it ever will be.

How to Delete Tweets and Likes from Twitter

Vance Lucas — Wed, 05 Aug 2020 16:21:13 +0000

I recently quit Twitter and deleted all my tweets and likes. This post shows how you can do the same.

Delete All Your Tweets

Start out by deleting all your tweets. You can use a 3rd party tweet delete tool to do this for you for free for up to 3200 tweets, and it’s quick and easy.

I think I had right around 3,100 or so tweets, so I was just under the free limit.

Delete All Your Likes

Deleting all your likes seems to be a lot more difficult than deleting all your tweets. I am not sure why, but a lot of tools don’t offer it as an option. It also appears to be rate-limited, so you may have to make multiple attempts at this over several days before you are able to unlike everything if you have lots of likes.

Go to your likes page: https://twitter.com/<username>/likes

Open up the Developer Tools console, and paste in the following script:

function _unlikeAll() {
  const randomNumber = (x, y) => ~~(Math.random() * y) + x;
  let unlikes = Array.from(document.querySelectorAll('[data-testid="unlike"]'));

  unlikes.forEach((unlikeEl) => {
    setTimeout(() => {
      unlikeEl.click();
    }, randomNumber(100, 8500));
  });

  window.scrollTo(0, document.body.scrollHeight);
}
var interval = setInterval(_unlikeAll, 12000);

Let this run for a while. Use a tool like Caffieine to keep your computer awake while this is running if needed.

This script stopped a few times for me, so I had to re-run it over the course of a few days to get everything. Twitter seems to have some kind of rate-limiting built into their web API, so you may run into it also.

Cleanup

After authorizing apps to delete tweets for you (which requires full read and write access), make sure to head over to the authorized applications settings page on your Twitter account and revoke access to all the various apps you have used over the years.

Other Options

Here are a few more scripts and things I found when researching how to do this. Some of them worked, and some of them did not. If the above script is not working well for you, feel free to try a few others:

GitHub Gist: delete-likes-from-twitter.js: https://gist.github.com/aymericbeaumet/d1d6799a1b765c3c8bc0b675b1a1547d

GitHub Gist: delete-rt-and-tweets.js: https://gist.github.com/FocusWho/5a8e74895293eae0071cec612477c72f