Introducing Jumpy

Jumpy is my latest side project! It’s an intelligent router where folks can map keywords to links to find and navigate the web by meaningful words and phrases instead of by arbitrary URLs groked only by computers.

Origins

Back in July my friend Roopak invited me to a fintech event jointly hosted by Brex and Bolt, where we had the opportunity to hear from the founders of both companies. Having heard their founding stories, we were both re-inspired to do a startup at some point. I had just joined Stripe after having been at Skip Scooters for the better part of a year, and there was naturally some post-startup fatigue.

Roopak had brought up previous small-team startups that could lower the bar from massive venture-backed future behemoth to just anything that could be fun or generate some small amount of income on the side. From there, the idea naturally went to something like Go links, an internal tool used by Twitter, Google, and many tech companies. An intra-net where “go/” followed by a keyword would route users to links, so that people could avoid having to remember or bookmark long and convoluted paths.

While GoLinks was made for the corporate use case, I found that there wasn’t anything similar for the consumer use case. With that in mind, I set out to making Jumpy.

Stack

The tech stack I chose was something I was most familiar with: the GCP serverless ecosystem that I fell in love with during my time at Skip. Typescript helps to minimize the most common Javascript errors, and VS Code is an IDE built to perfectly handle this sort of codebase.

For the frontend, I’m most familiar with React, so I stuck to what I’m good at.

Lessons Learned

Time Is Precious

A side gig - even one as tightly scoped and feature contained as Jumpy - takes longer than I initially expected. First and foremost was just the friction of getting started. Finding a consistent time to work and preventing context loss is easier said than done, especially when one already has a full time job.

Initially, I’d dedicate one evening per weekend.

I had just joined Stripe, and like any new job, I wanted to prove myself during the first few months as I onboarded and ingested the firehose of new data. Additionally, we had just gotten MoMo, so there was a huge adjustment period in caring for our first dog, wrangling having a dog with two cats who didn’t particularly care for said dog, and just new pet ownership in general.

One of the weekend days we’d typically do some sort of activity in addition to obedience training, and with the chores and other typical errands I’d have to do, that usually left one evening per weekend.

This meant that anything that couldn’t get shipped in that tightly scoped context basically didn’t get done. I didn’t want to leave anything hanging for the next time becuase it would often take me a half hour just to remember where I had left off. It also meant that bugs were particularly grueling, as it would take me far longer than usual to fix. Or I’d just sleep less on Sunday nights.

Burnout Is Real

Eventually, life stabilized. MoMo got used to our routines, and I got used to Stripe. This allowed me to dedicate slightly more time to Jumpy, so for a couple weeks my schedule became as follows: 6AM wake up and walk MoMo, and then go to work. 7:30AM-9AM work on Jumpy, 9AM-5PM work on work, and then go home. 6PM-8PM is dinner and walk MoMo again, and then 8PM-midnight work on Jumpy some more.

Needless to say, there wasn’t very much time for decompressing. I got quite a bit done, but because I was doing everything, it still felt like an insurmountable task. I didn’t have any technical partners, and in the early phase everything you have to do is technical.

Coding for long stretches so you can have this ‘grand reveal’ at some point when everything is done is super demoralizing. This strategy may work for Apple, but typically engineers are happiest when the time between code pushed to master and launch is minimized as much as possible.

Beta Early and Often

Following my previous statement, one of the best ways to get the excitement back is to have mini launches where you beta with friends and family. At various milestones, reach out to close friends who are willing to try stuff. Not only does this give the periodic boost of shipping something, it also forces you to get in touch with your customers more often, which is tough to do when you’re a single-dev shop.

Code Is One Way to Solve Problems

Coding is ultimately just a way to solve problems. But it’s not the only way. And as engineers, that’s pretty hard to remember. Since I was the only dev on this project, I wanted to do everything from scratch in just the right way. This was pretty easy with most things, but frontend work and designs are something I’m not good at.

And whenever this part of the project started, I’d hit a huge wall. Weeks or even months would go by, and I’d make make little to no progress. Ultimately, this just wasn’t something I was excited to do, and giving up my weekends or evenings to do this was a huge blocker.

In retrospect, this was a sign that I shouldn’t have been trying to solve this.

I asked a friend what he used for this sort of stuff, and he recommended contractors on Fiverr. Boom. Three weeks later, we had a great introductory video out and the website was coming together. Another friend recommended Divjoy’s templates, and while not perfect, they met the bar of “I don’t have to do this anymore”.

Just a couple weeks after switching to Divjoy, Jumpy was ready to go!

Conclusion

Overall, I’m really glad I worked on Jumpy. It’s not going to be a huge VC thing - I’m not even sure it’s going to be a thing at all. But I learned a ton along the way. I told myself I’d easily be able to launch this small project by August… It’s now February, and I’m only now readying to go live. :) Estimation is hard, true, but side gigs are hard as well. I think I’ve underestimated just how hard such a small thing can be!