Speramus

Sorry to go incommunicado this last month; we’ve been real busy trying to push into a full featured beta. I have to admit, we were surprised as the amount of ‘stuff’ we needed to do before the an actual product, and an awful lot has happened in June: We’ve incorporated as an S-Corp (Speramus, Inc.), secured a few alpha clients, talked to several possible funders, and finally hired a programming team, the great guys at MojoTech.

This last item was perhaps the most surprisingly taxing of all. There’s no cut and dry technique to find great programmers; because of the plethora of talent available, you can look just about anywhere for a firm. Options range from outsourcing clearinghouses like VWorker (formerly Rent A Coder), ODesk, and Elance, to just running into people at the bar. Any one of these can lead you to a great firm; no, really, my first conversation with Nick from MojoTech was to discuss our choice of beers. With so many different ways to find a team, how do you get started?

We found a lot of resources on answering that question, but also a lot of conflicting information. Here’s a quick guide on outsourcing your programming from our perspective. In short:

1. Write what your company does in 10 words or less.
2. Think about the Minimally Viable Product
3. Make a spec sheet
4. Throw half of it out
5. Find your long haired CS guy
6. Create a joint proposal
7. Review. Change. Review. Change.

Now let’s see what we mean by each one of these, after the jump.

1. Write what your company does in 10 words or less.

Well, much like luck favors the prepared mind, great programmers prefer clients who know what the hell they’re doing. The first step for us was to figure out exactly what it was we wanted to do. When Speramus was a business plan, we’d conceived it with pie in the sky, long range thoughts; It took us the entire executive summary, almost 250 words, to explain what the company did. Nobody, let alone a busy programmer, wants to read a 250 word document to just begin to understand what you want to do. What was our ten word mission?

Eventually, we got it down to: Speramus helps donors help people.

That’s it. We’re a nonprofit platform that focuses on helping donors. This one sentence helps set the tone for your developer; is it something that excites them? Something that catches their eye? Any programmer can make your product, but a programmer who is interested and wants to see it realize is going to be worth a whole team of apathetic whiz kids.

2. Think about the Minimally Viable Product

We had a really big platform planned when we thought up Speramus: a project base fundraising site, a personalization engine, a donor management CMS, and countless other features we wanted to bring in. Thankfully, we got good advice from our mentors to think about a minimally viable product. What is the least functional product that will help you accomplish your ten word mission? So we took what we wanted to do and trimmed, trimmed, and trimmed some more. What could we live with? What things did we need to do this first alpha test, and what things did we just want? What feature made us special?

Speramus’ alpha will be a project based fundraising structure. The other features are being shelved for future versions, but we think that this first alpha can be contained with just the projects.

3. Make a spec sheet

We’ve figured out what we want to do, but how will it work? What will it look like? A spec sheet will be a fairly personal experience, depending on the skillsets your founders have. The basic idea is to write down a few paragraphs on what you want the user experience to be like, and what the key functions you’d like to have. If you feel comfortable, make sketches of the interface – these are often the most helpful parts. The spec doesn’t have to break down every single click, but instead give the programmer an idea which they can build off of. If you’re technically inclined and want to suggest technical details, put them in as suggestions – your programmer may have even better solutions in mind. Analogies are incredibly helpful: if you’re going to be the Zappos of dog toys, say that. It’ll make the experience much more clear.

It’s important to stay flexible with this document. This spec will probably change as you approach programmers and get feedback; that’s totally fine. This document should be the starting place, not the final spot. Our proposal evolved with every programmer we approached, constantly being recrafted.

4. Throw half of it out

If you’re like us, you’ve probably wrote a lot in your spec that isn’t in your MVP. Here’s the time to take a moment and reevaluate what you really need. We ended up throwing about half of the spec sheet out. Doesn’t that feel better? Ahh.

5. Find your long haired CS guy

There are several different avenues to find your magic programmers, each with its own set of advantages and drawbacks. In all cases, we kept a common set of expectations, nicely outlined in a blog by David Brown. The top things to look out for are a) experience/capability b) reliability and c) passion. We know that we are going to have to come back to these people for updates or fixes, so building a trusting relationship is critical.

Freelancing sites are the least expensive route, but also present the most difficulties. The biggest online freelancing sites are Vworker.com, odesk.com, and elance.com. We generally had the best results with Vworker, but depending on what you’re trying to do another might suit your needs better. Browse the current projects to get an idea for how to price your proposal. For us, and for most Ver0 webapps, this should be between $3-8k, but can go anywhere from $1-25k depending on complexity.

When using freelancers, we found it important to really vet the best programmers out from the spam. Many firms, especially those based internationally, will submit bids without really reading your proposal. We automatically filtered out firms that submitted bids that did not mention any of our features/theme, without formal proposals, or who didn’t communicate well in English. This meant that of the 20 bids we received ranging from $550 to $11000, only 4 were worth actively pursuing, all of which were in the $5-8K range. These 4 responded well, understood the proposal, and submitted well formed bids. Upon further conversations, we felt that two firms really understood and were interested in the proposal.

The next tier up from this is to look for a higher end consultant, a la HNHackers.com. Freelancing sites are usually just people trying to make a quick buck after hours, but the people on hnhackers are generally career programmers who will take you on as an actual assignment. While this usually results in higher quality code and feedback, it also requires you to know more about what skillset you require; consultants are listed by their skills, so you will have to know if you need someone who can write Ruby, PHP, or Python.

Top tier, and usually most expensive, are the local programmers. Look on hnhackers or google for a programming firm near you, or post a proposal on craigslist. Nothing replaces face to face interaction, and being able to meet up with your programmer will smooth over thousands of little niggles in the future. We ended up selecting MojoTech because they passed all of our concerns with flying colors. We felt that the price premium was trivial compared to the peace of mind and long term stability that we gained from going with them. Plus, we really liked Nick and the crew, and that meant more to us than anything.

Once you have a list of finalists, its up to you to decide which one you like the best. If you don’t have a clear choice, hire two to do the first milestone in parallel, and decide as you go. As always, never burn a bridge with any of the programmers you do not select. They might be useful if your current relationship falls through.

6. Create a joint proposal

If your programmer is worth his/her salt, they’ve probably already sent you in this direction. Conversing with your programmer, decide what features stay, what needs to be added, and what can go. Tell them that this is only the first phase, and give them the roadmap of where you might eventually want to go – there might be some features/architecture choices they make now that can be costly fixes down the road.

Once you come to a consensus, group features into 40 hour milestones with logical transitions, and ask for a review after every milestone. Eventually, you’ll compromise on a contract and/or proposal with the milestones you’ve requested and a price estimate on it. Here is where you should run through a quick check list:

1)      Who has ownership of the code? Are there any limitations you should be aware of (GPL)? (You should own all of the code in totality.)

2)      How are you going to pay? Is it a set amount for this one proposal, or will you pay per hour? How will you handle changes to the proposal? (If you’re 100% certain your proposal won’t change, use a set amount. In any other case, even if you’re 99% sure, pay per hour.)

3)      How are you guaranteed that the program will work? Under who decides whether it completes the proposal or not? (This will change based on which programmer you use. Just make sure you’re protected.)

4)      How often will you contact each other? Through what medium? (Make it no less than once a week.)

Properly addressing these few points will help you avoid a fiery shitstorm of legal battles later on. While having a great relationship with your programmer is important, having this down in writing is imperative; much like any relationship, you never know when things will go sour.

7. Review. Change. Review. Change.

Check in regularly with your team. Things will change, almost without question, so be in constant communication with each other. Once your first milestone is completed, it’s a good idea to get someone else (outside of your team and the programming team) to check it. Remember those other programmers you considered for the job and didn’t burn bridges with? They’ll do nicely. Hire a team to check over the code to make sure you’re on the right path.

Well, at this point you should be well on your way towards success. This is how we managed to find a good programmer fit, but if you have any other tips we’d be more than happy to hear them!