Outsourcing your startup’s MVP

Compromising is part of product design, and often the compromise is cutting scope. Cutting scope is better than compromising on quality. (Quality being defined as design, usability, stability, and performance.) Customers get excited about a product that does a few things well, whereas they’re turned off by poor execution, because poor execution erodes their trust in your brand and their confidence for the future. A Minimum Viable Product (MVP) is about cutting scope from your grand plan while maintaining quality. It’s the smallest thing you could build to test the viability of your idea in a real-life scenario.

When you’re a solo founder, you’re very interested in cutting scope because not only do you have to design the product, you also have to build it. I realized my long term vision for Dovetail as a ‘qualitative research platform’ would need to hit the back-burner as I decided to focus on diary studies first.

Picking this niche for our MVP was a good decision, although only just. There isn’t much competition for a diary study product, automating a manual process has clear value, and because it’s a niche, marketing and SEO are straightforward. Yet one thing I overlooked is how infrequently researchers run diary studies and how important recurring revenue is for a business. More on that in a later post.

I’d written some JavaScript in the past, so I thought Node.js, Firebase, and Twilio SMS (for the contextual diary entries) would be a decent stack. A few days of spiking made me realize this was harder than I thought, so my girlfriend suggested Ruby on Rails since she’s familiar with it. The thought of learning another language when I hardly knew JavaScript frightened me. But one of the nice things about Ruby on Rails is that — unlike Node — it’s very opinionated. Ruby on Rails makes it clear when you’re going down the wrong path because the light starts to fade away, the trees contort into creepy shapes, and howling noises emerge from the dense forest that appears to have engulfed you. You quickly find another path (usually on StackOverflow).

The outsourcing option

Around this time somebody suggested outsourcing via Upwork. I had never considered outsourcing, and I investigated Upwork and decided to give it a shot. After all, what else could I do? I believed in the idea.

I am a designer, so I sketched, wireframed, and designed until I had a clickable InVision prototype. If you’re not a designer, try to sketch your idea anyway, and look for a freelancer to help you with the high fidelity designs and prototype.

Dozens of quotes appeared within minutes of posting the job on Upwork. Mostly automated, mostly rubbish. I reduced the offers down to two: a solo developer in the US and a web development agency in Poland. The solo developer had startup experience, although he wanted to use Node and his timezone overlap with Sydney wasn’t great. (I was still working at Atlassian, so could only start work on Dovetail at 6 pm.) The agency had a comprehensive quote and understood the idea. They were an established business specializing in Ruby on Rails development. Most importantly, their timezone meant I could work with them in the evenings.

We went over the details of the project and I walked them through the design prototype. I told them my budget, they came back with a quote of around $5,000 USD and a four-week estimate. We broke the project down into milestones and had partial payments released at each.

Pro tips for outsourcing

I learned a great deal working with the development agency throughout those four weeks. If you’re thinking about outsourcing, here are some tips.

Be prepared. This is not the time to be Agile. Plan everything in advance. Have designs, requirement documents, tasks, and a clickable prototype if possible.

Be present. Ask for regular check-ins, screenshots, and demos. Upwork has a built-in chat tool, so use that to talk with the team. If you can code a little, get the code and review it. At the least, you’ll start to familiarise yourself with the technology.

Be prescriptive. When working at Atlassian, I could ask developers to use their common sense with small design decisions. Contracted developers are eager to avoid mistakes and loathe ambiguity. They make no guesses about the behavior of functionality. You will need to tell them exactly how you want everything to work and provide all assets.

Set expectations. Triple check the developers know what the final deliverable should be and what your expectations are for quality. Again, a clickable prototype is a great way to show what you want instead of telling, and it helps bust through language barriers.

Consider a team over a single developer. Agencies give you more security than a solo developer. They often have a project manager who can speak fluent English, and the developers have others around them to ask for advice.

Consider the time difference. Ensure their working hours line up with yours, otherwise you might find yourself on a Skype call in the middle of the night. If you’re working a day job like I was, then shoot for overlap in the morning or evening.

Use a site like Upwork. They hold the money in escrow until both parties agree the work is completed satisfactorily. They also have a review system that is useful for vetting, and can help mediate disagreements.

At the end of the four weeks, I reviewed what I got. The Ruby backend and configuration on Heroku looked reasonable, but the frontend was a mess. I spent long nights rewriting JavaScript, the view templates, and CSS. The developers opted to use Bootstrap, which would normally be fine, but as a designer, I am quite picky with details. If you’ve ever worked with Bootstrap, I’m sure you understand how difficult it can be to customize. The CSS codebase was 50% overrides. Yuck.

I learned a great deal about working with tests, continuous integration, deploying to Heroku, and Ruby on Rails’ Model View Controller framework. I was already on the path to ‘becoming a developer’ although I hardly noticed because I was focused on the output. There were frustrating moments where I wanted to give up, and at least once or twice I felt utterly useless and out of my depth. My morale was a rollercoaster during this time. Huge shoutout to my girlfriend Lucy who helped me through these programming hurdles.

Apart from Bootstrap, I was happy with the result I got from the development agency. The project had gone smoothly, within budget, and within time. But most importantly, I now had a working thing! The next step was the daunting task of getting some people to use it.