Why Working on It On the Side Wasn’t Working
5 short months ago I did the unthinkable. I quit my job to start a business. I’d be lying if I said that was the original plan. The original plan was to work my day job as a Frontend Developer while working on a business idea on the side. That’s what all the good advice was telling me. Work on it on the side. Keep your day job. That’s what Basecamp, Mailchimp, and countless other bootstrapped success stories did.
Unfortunately, this approach hadn’t worked for me so far. That’s not to say it’s bad advice. It had as much to do with the way I was trying to follow it. I’m sure for a lot of developers this advice will continue to work great. In the past, I’d managed to find 90 minutes before work early in the morning to work on personal projects. Projects I’d tell people were just side hobbies. But I’d harbored hope they’d turn into something more. Something people would pay real money for. But this wasn’t how I was treating them.
I’d start with an idea for something I wanted myself. As an example, I wanted a way to track my net worth over time. I began working on a way to track all my assets and liabilities using a compilation of APIs. I displayed the result in a neat, simple user interface.
But the idea wasn’t the problem. The real problem was the developer in me. Whenever I had an idea for a new project, I’d take the opportunity to build it using a new technology I wanted to learn.
At the time I was working with JavaScript. Think frontend frameworks like React.js, Vue.js, and even some legacy Knockout.js. On the backend, I was most comfortable with Node.js. But for this project, I was going to forego all that and build it in Ruby on Rails. That was the backend framework my company used at the time.
Instead of diving straight into building the idea, I went to some tutorials for Ruby on Rails. As you can imagine this was a VERY slow process. After a few months, I was only a third of the way through building the idea. I needed to learn an entirely new programming language and framework. Combined that with the tiny pocket of time I could dedicate to working on it meant it progressed at snail’s pace. I became burned out as the months went by.
Fast forward a few months and I picked up a more senior role at a different company. The hours at this company were far worse. Before, I was working roughly 8 hours a day and working an hour and a half per day on my side project. At this one, I was working 10-11 hours and on a good day, could squeeze just 40 minutes in for my own projects. Often I’d end up using the 40 minutes to brush up on a new technology I was using at this job. Think Docker, PHP, and some older tech.
To make matters worse the culture didn’t fit me. At my previous job people dressed casually. It was a startup with a young demographic. This job required me to wear a suit. There was far more office politics. The spec of the product I was building was changing by the day. There were many times I had to stay back to work late. My product manager regularly changed his mind about features and it was ‘urgent’.
The last straw was when they fired a contractor I was working with. He’d been subject to the same constant spec changes I was. When the project fell behind he became the scapegoat.
It was at that point I decided I’d had enough. I’d made no progress on my own projects due to the demanding hours and was beginning to hate going to work each day. I understood most workplaces were not like this.
I could’ve just gone out and picked up a better job. But I was feeling the weight of having made no progress towards my own goal. Having my own business. So I did it. I quit. But my goal wasn’t to launch a successful business. I set the bar far lower.
My goal was to take what I called a ‘hackathon sabbatical‘. The only goal was to actually launch something which I charged money for. I figured if I was ever going to reach my goal of having a successful software business I had to launch something. If the idea wasn’t a success, at least It would be a step in the right direction.
It would also give me confidence. That if I ever wanted to take a few months off to work on a promising idea, I could be confident I’d actually launch it. I told friends and family I was working on my own project. That’d I’d likely go back and pick up a job in a few months if it didn’t work out.
This took away lots of pressure. Keeping everyone’s expectations low made the whole process feel mentally easier. My first step after quitting was to begin my search for an idea to work on.
The Screening Criteria I Used To Choose An Idea
The second I quit I began searching for an idea. But not just any idea. I had a checklist of criteria the idea had to meet before I’d even consider working on it.
1) It had to solve a problem I had or had experienced at some point
Scratching my own itch made sense to me. It was also one of the few ideas people I respected agreed on. From Jason Fried of Basecamp to Paul Graham of Y Combinator. Plenty of great software businesses I admired started this way. Dropbox started when Drew Houston wanted an easy way to store and retrieve his files. Basecamp began when Jason Fried needed a way to keep track of all his projects and tasks.
There was also a more pragmatic reason for choosing this path. As a single developer living on savings, I needed every advantage I could get. I wouldn’t have the time or money to research and understand the problems of people in a market I wasn’t apart of.
At least if I built something to solve a problem I had myself, I could be sure the problem existed. I’d also circumvent one of the biggest risks facing new startups. Not solving a problem that actually exists.
2) It had to involve recurring revenue
There’s something about the predictability of recurring revenue which appealed to me. On a philosophical level, I liked the incentives created by a SaaS business model.
Most of the value is around creating a great product and retaining customers. Businesses built around one-off purchases are generally more focused on acquisition. It’s more about getting leads to buy in the here and now. I also didn’t like the idea of creating something, not charging for it and trying to get people to click on ads. I liked how the SaaS model created a greater incentive to get people to stay. Most of my efforts would be around making the product better and more valuable in the long term.
A SaaS model also meant I’d likely be selling to businesses. Most of the bootstrapped businesses I read about were in the B2B space. They created a product and companies paid for it. I also didn’t use many SaaS products outside of my work. Selling to businesses was not so much a strict rule as a likely conclusion.
3) It had to have a sustainable marketing channel
I wanted a channel to market to customers cheaply and sustainable. I hadn’t built up an audience I could market to and wouldn’t have the funds to hire a salesperson. I was always going to have to recruit users manually. But I wanted a channel that would act as a tailwind for customer acquisition.
I’d heard about startups that built products that integrated with popular software. As a result, they had their software listed in the app stores of the host software. Think an app that integrates with gmail and gets listed in the Google web store. Or an app that integrates with Slack and gets listed in the Slack app store. These companies generated many sales directly from the app store at no cost. This seemed like a smart approach.
There was another benefit. Integrating with other software reduced the scope of my minimum viable product. The host software already serves a lot of the customers’ needs. This freed me to focus in on a specific pain point.
4) It had to have people ready to pay for it now or at least look forward to using it
My last criteria was that other people also experienced the problem. And ideally, would be willing to pay for a solution. Even if I was scratching my own itch, I wanted to be sure I was not totally crazy.
I figured If I put up a signup page and no one signed up to use the beta version of my product, the idea wasn’t great. I found this rule the hardest to stick to. More on that later.
The Ideas I Considered
I began the process of coming up with ideas and putting them to the test. I started by looking at the Shopify app store. Revenue from the store was growing every year. There appeared to be tons of e-commerce related problems to solve.
But I didn’t have any personal experience as an e-commerce vendor. This didn’t meet my first criteria of being able to scratch my own itch. I considered building a Stock Screener. I wanted to be able to screen stock based on the criteria I used when investing in the market. But I couldn’t find a sustainable marketing channel I could use to help me sell the product.
Finally, I considered a Jira extension to help get features into Jira faster. At my previous job, my product managers refused to put his ideas and feature requests into Jira. I figured this was so he could retain the freedom to change his mind at the last minute. As a result, I had to put all the Epics, User Stories, and Tasks into Jira myself. And boy did it suck. Creating Epics, Stories, and Tasks and linking them up was a slow, tedious process. No wonder my product manager didn’t do it. It was a longer, more annoying process than it should’ve been.
I had an idea for a way to make it simpler. An interactive tree view of all the issue hierarchies in Jira. There were already products in the app store which did this. But mine would be different. You’d have the ability to create your entire project from scratch in a tree view. And it would feel as easy as working with dot points in a google doc.
I drew inspiration from WorkFlowy. A note-taking app that allowed you to create nested todos. I used it myself.
It felt like a more natural way to work with Projects, Epics, Stories and Tasks in Jira.
In my app, you’d be able to create a new Story by creating a new dot point. Or turn that Story into a Task by tabbing it across and creating a relationship with the Story above. All the links between your Epics, Stories, and Tasks would be created automatically.
It would solve a pain I’d felt at my previous job. On to the next criteria. After some research, I determined my marketing channel would be the Atlassian Marketplace. I could list my product, which integrated with Jira there. Revenue from the marketplace had been increasing every year. It reached 200 million dollars in sales in 2018.
Better still, most of the apps were SaaS apps. They charged a monthly fee. Usually with a free trial for the first month. This satisfied another two criteria.
There was a sustainable marketing channel and recurring revenue. There was only one criterion left to meet. Ensure people would be willing to pay for or at least use the app.
How I Validated the Idea
I put together a google form that asked people about the pains they felt using Jira. It asked whether they:
- Wanted a hierarchy view of their issues
- Wanted to create Projects and Tasks from that view
I also asked which issue hierarchy they currently used at their workplace.
I posted it in some slack groups I was apart of and sent it to some friends. The responses seemed to confirm people experienced these pain points. That they’d love to create Projects and Tasks directly from this view. But I only had 11 responses. Not the biggest sample size.
Next, I browsed Jira’s support forums for people complaining about these pain points. I found a few threads where people mentioned these problems.
By now you probably think I went ahead and built the app. But I didn’t. I needed more validation. I had a deep fear of building something no one wanted. So I coded only what was necessary to put together a demo video.
Inspired by the video Drew Houston put together to demo Dropbox before it was ready to launch.
This took about 3 weeks all up. This time included creating a landing page to display the video. Writing some sales copy to describe the benefits of the app. And adding an email opt-in form to collect email addresses.
I called the app Agile Docs. There was no special reason for the name. It sounded cool. It was an app for Agile Development teams. And the app made interacting with Jira feel like editing a google doc. It made sense to me. The demo showed how the app would work when complete. This meant I only had to build the frontend of the app.
I’d send an email to early signups from my personal Gmail account using Zapier. This gave it a personal touch. The email asked the person what pain point they were trying to solve with Agile Docs. The feature they liked best, and what features they wish it had.
I contacted all the Product Managers, Engineering Managers and Developers I knew. I wanted their feedback on the demo. I also posted on the Jira support forums where people had the problem my app solved. I told them to check out the Agile Docs demo.
Responses didn’t come in right away. Every week I’d get a few people signing up for Agile Docs and maybe 1 email response. I had to follow up people in my network a few times to get them to take a look at it.
The response was mostly positive. Many said they’d use it, some said it was cool. Many of the email responses I was getting were very comprehensive and made me rethink a few parts of the app.
I made the mistake here of not putting a price tag on it or asking about price. If I had my time over I’d be more upfront asking if people would pay. But at the very least many people claimed they’d find the app useful.
I was still on the fence about proceeding with building the app. It’s difficult to know when an idea’s been ‘validated‘. There’s no official standard. I battled with this mentally during this phase. Is there enough interest in this? Should I build it?
In the end, I decided to go ahead and build it. If no one used it, at least I could say I’d shipped something. If the app made no money and I needed to go back and pick up some dev work I could at least point to an app in the app store.
How I Overcame My Developer Demons And Actually Shipped The App
Developing the app had its own challenges. There were times I doubted I could execute on the promises I made in the demo video. I originally created the Frontend for the app using Next.js. A framework using React.js which came with built-in routing and server-side rendering. The plan was to send API calls from the frontend of my app to create, edit and delete tasks. Create links between tasks. And do everything I wanted the app to do.
But there was a problem. I was unable to access all of Jira’s APIs directly from my frontend app. Jira’s authentication mechanisms didn’t allow it. This was especially true if I wanted to use the APIs to create tasks on behalf of a user.
After some research, I came across Atlassian’s framework atlassian-connect-express. A toolkit for creating Atlassian Connect based apps with Node.js. It had built-in authentication.
This meant once the app was installed, It could make API calls to all Jira’s APIs. This also meant I wouldn’t be making API calls directly from the frontend of my app. Instead, my frontend made calls to my own atlassian-connect-express app. And that app made calls to Jira’s API.
I expected to encounter unforeseen technical challenges. This didn’t surprise me. My biggest challenge during this phase was my own developer demons. More than once I considered rewriting the atlassian-connect-express app to use graphQL. But I consciously resisted the urge. At one stage I folded and ported my Next.js app into the shiny new Gatsby, a similar frontend framework. This added little value. But also didn’t take much time.
A few weeks in I had the tree view part of the app done. I decided to release it for free in the app store. I called the app Project Tree.
At least this way I’d know what to expect when I released the full version. It also felt good mentally to release something after a few weeks of work. Psychologically, it can be tough to keep working on something without feedback.
It was a nice checkpoint. At least if I didn’t or couldn’t finish Agile Docs, I’d have something in the app store. Even if it was a little free app. Over the next 2 months, I made my app work exactly as it did in the demo. I added a couple of extra features at the request of early sign-ups. These were usually the ones which only required an extra 5 minutes dev time. I removed other features some people found confusing.
After 2 months I had a working version of the app I could launch. It wasn’t perfect. There were tons more features I wanted to add but tried to keep it as lean as possible.
For instance, It only worked on Jira Cloud. Jira Server used a different API so I elected to only make it compatible with Jira Cloud. At least for version 1. From the research I’d done, it looked like Jira Cloud was growing as more Server customers moved to the cloud.
The issue hierarchy was not yet customizable. It used the hierarchy of Epic => Story => Task. These were the default issue types for next-gen projects in Jira. It was also the issue hierarchy used by most of the people I interviewed before building the app.
But still. I could now create my entire project super quickly. All my Epics, Stories and Tasks were linked perfectly. It was pretty nice. It made interacting with Jira feel as easy as messing around in a google doc. For the first time, I was using Jira as a personal todo app with my own Epics, Stories, and Tasks. I never had the patience to do this in the past. But Agile Docs made it easy. Even enjoyable.
I put together a little sales page and submitted Agile Docs to the app store for approval. I had a look at some other apps to gauge a reasonable price. I settled on $10 per month for up to 10 users and $1 per user after that. It was a nice simple pricing model and sounded about right.
How I Launched The App And Acquired My First Users
As soon as my app was approved it became available on the Atlassian Marketplace. I reached out personally to everyone in my network who said they were interested. I also sent an email broadcast to everyone on my email list of roughly 50 people.
Many people who showed interest initially didn’t respond. Some said they’d give it a try, but never started a trial. In the first couple of weeks, only a handful started a trial. I posted my app on Product Hunt. This attracted a number sign ups but no trials I could directly link to Product Hunt.
The majority of trials came directly from the app store. After 3 weeks I had 10 companies on active trials. 12 total, with 2 cancellations.
The Challenges I’m Facing Today
That leaves me to where I am today. Roughly 4 months since I started. A paid app in the app store, 10 active trials, and scratching my head over marketing. There’s a lot I could’ve done better knowing what I know now. But that’s the case with any new endeavor.
At the moment I’m exploring different marketing channels. I’m finding more Jira support threads to post on. Working out how to use Google Adwords. And considering dipping my toes into cold emailing (shudder).