Taking the plunge on your startup

It had been two months since our October launch and Dovetail had 200 users, of which 20% were active each week running real studies. This felt like good traction at the time but I still had 99 problems. I needed to restart the app every 6 hours due to a memory leak and the scheduling system was unreliable during restarts since it wasn’t idempotent.

The MVP was built by an external agency, so I hired them once again before a holiday to the US. I couldn’t get the original developers and ended up with another developer who quit the agency one week into my project (unrelated to me!). The whole project dragged on as the client manager tried to find someone else to complete the work. Meanwhile, I was debugging a memory leak in code I could hardly read without the people who wrote it around to help. I spent parts of my holiday debugging and I eventually figured it out. The leak had a simple fix after a lot of investigation: the library that inlined CSS for emails was caching the entire application’s CSS. The fix was splitting the email CSS into a separate stylesheet.

I got back to Sydney and decided this would be the last time I outsourced development. Outsourcing might work to build a simple MVP to validate your idea and the market demand, but to move forward I needed someone who could architect the code, do the bulk of the development, and stick around to help when things got hairy. I needed a technical co-founder, and I made that my main goal heading into the new year.

By this point, I had been pestering Brad for several months. Thankfully my refined pitch, the traction Dovetail had from launch, and the positive customer reception was enough to convince him to join as a co-founder. We had a lot of discussions about how we would work together. If I were to summarise the ‘ideal co-founder relationship’ in bullet points, I’d say:

• Complimentary skills. Development is just one aspect of a startup. Someone has to design the product, run marketing, customer support, keep track of expenses, apply for grants, talk with investors, do customer research, etc. Complimentary skills enable Brad and I to run fast.

• High trust and respect. One of us will be the ‘expert’ and the other person just has to trust the expert. I need to trust Brad with technical decisions, likewise, he has to trust me with design decisions. Of course, we have sparring and discuss things in detail, but because we move quickly we don’t spend too long on trivial decisions. The relevant person makes the call and we move on.

• Similar experience levels. One person feeling like they are the ‘noob’ all the time isn’t healthy. Brad and I are the same age and we’ve been in the workforce for a similar amount of time. We’ve both got 8 years of Atlassian experience between us on a variety of teams.

• Compatible personalities. You will be spending an insane amount of time with each other, so you must get along. At the moment I spend more time with Brad than I do with Lucy.

Going full time

Brad and I were still working full time and coding Dovetail in the evenings and on weekends. As I talked with more customers, I became more confident and excited about the opportunity for better software in the research space, but it was clear we needed to give Dovetail our fullest attention to have a chance at success.

After four years of putting in 110%, I was burned out from Atlassian. At the end of (Australian) summer, I took two months off work. I needed a break, but I also wanted to see whether I would go crazy working at home. I didn’t. In fact, it was pretty awesome. At the end of this mini-sabbatical it was clear my passion had shifted to Dovetail and the decision to leave Atlassian was tough. I was certain I wanted to try and ‘bootstrap’ instead of taking investment, so obviously a lot of considerations were financial.

We did a lot of due diligence before making the final decision to leave our paying jobs. We see Dovetail as a financial investment but also an investment in ourselves. We’re both ready for different challenges and we’re in a stage of our lives where we can take risks. Brad and I looked at our expenses, talked about ‘salary’ expectations, and ran some exercises to check we were on the same page. In one exercise we each described Dovetail in three years and compared. For me, it was critical we both had the same expectations — the last thing you want is one founder imagining a ‘lifestyle business’ and the other dreaming of a billion-dollar IPO.

A successful startup is the result of making informed decisions, not counting on luck. We had just launched pricing, so I forecasted how many customers we would need to break even. This information plus our growth rate gave me the numbers I needed to model our runway based on an initial investment Brad and I put in. I had worked on Dovetail myself for a few months before Brad joined, so I looked at how much time I had invested and multiplied that by the market rate for a senior designer in Sydney. Brad would invest the same ‘seed’ as me plus extra to make up for that time spent. We each own 50% of Dovetail.

One thing we’ve learned is that researchers do not run diary studies very frequently. Customers sign up for a paid plan for the duration of their study, then cancel once it finishes. Brad and I decided to go back to the drawing board and start working on features that encouraged repeat use. We needed to expand beyond the diary studies MVP I created with the outsourcing agency, and into a product that solves more common researcher problems.

Reality check

I dislike the word pivot. It often has negative connotations (“oh, you didn’t get it right the first time around?”), and the reality is that startups are always pivoting anyway. You never get it right the first time. One huge benefit of a startup is that you are extremely agile and can pivot all the time if you haven’t found product-market fit. Also, its definition is unclear—you can ‘pivot’ the core feature set or marketing message dozens of times while continuing to target the same problem space. Is that a pivot?

In saying all of this, I had gone down the diary studies rabbit hole and lost sight of our mission. Brad, with somewhat of a fresh perspective, convinced me we needed to evolve into something that researchers could use more than a few times a year. Ideally every day. We scheduled a bunch of customer interviews to help us figure out what that looks like, and for the past few weeks, I’ve been sharing sketches and designs with our customers to see what they think.

It’s possible we could double down on diary studies and eventually become profitable. I don’t think we would be very profitable, and that journey would be tough. So we’re pivoting the feature set while still going after the same general problem space of qualitative research.

Moving to a new stack

As part of this new work, we’re taking the opportunity to incrementally rewrite the original outsourced code. Ruby on Rails was great at getting us where we are, but the new features we’re building demand a more modern stack, particularly on the frontend. Real-time collaboration and a single page app with no page refreshes are two features people take for granted.

The temptation to rewrite everything is strong but stupid. We’d spend our whole runway rewriting code and not moving forward. We won’t move off Rails completely any time soon. Instead, we’re slowly replacing components and services with React, Node, and GraphQL. It’s exciting, I’m personally learning a lot, and our frontend is much happier with the modularity and reusability that React brings to the table.

We’re working to get a usable alpha of our new stuff out the door as quickly as possible, while making technical decisions that help us speed up development and build experiences people will love. We hope to launch our new version of Dovetail over the next couple of months. Stay tuned because I think you’re going to love it.