Or is it?

I hate sysadmin work. Some people are cut out for it, but for it’s my least favorite part of the job. In fact, if my life came down to a choice between having to juice the bile out of an angry bear’s gallbladder or do more sysadmin work, I’d pull out the rubber gloves and astroglide with a smile.

Unfortunately, bear-bile-milkologists are illegal and, more importantly, paid poorly. Which means that I try to find as many ways to avoid sysadmin work as possible.

Bundler has been purported as one solution to this. Who doesn’t want to never think about their gems again? No worrying about installing dependencies or having weird versions of gems, just easy, simple, one file configure and go. Right?

Well, mostly. If you’re running on one platform, yeah, it’ll work great. But for those of us who develop on a windows box and deploy to linux? Yeesh, forget about it. You’ll have to manually configure so much it’s hardly worth it.

The problem is platform dependencies. To test on your local box, you’ll need windows gems: mingw32-* whatever’s. But when you try and use bundler to deploy this to your production server, it’ll just port over your windows gems, which will promptly fail on the linux box! Bundler isn’t smart enough to realize that the mingw32 gems, though the satisfy the dependency, aren’t actually working.

The solution I’ve found is just to not lock the gemfile until it’s uploaded on the server then rerun bundler install (if you’re sudoing, bundler install vendor/bundle, unless your webserver runs as root). Hopefully this’ll save someone some time and frustration.

We’ve been hard at work getting Speramus off the ground, and we’ve finally reached our first beach head: Speramus v.1 (We do mean point one, and we’re damn proud of it!). No, it’s not a complete, fully functioning beast, but enough that we’re happy to call it a demo, and our lucky beta clients will be getting their hands on it soon. What’s it look like?

Well, why don’t you sign up to beta test and find out?

Once again, our great friends over at MojoTech just continue to amaze. They’re most cordial, efficient, and genuinely nice team of programmers you’ll soon meet. If you ever have anything remotely ruby related, give those guys a call.

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.

Just what's necessary

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.

The other half is pretty. Pretty unnecessary (buh dun tshhhhh).

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.

Epic Beard Optional

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!

What happened was that our old hosting company (UC WebHost) essentially Enron’d us. The CEO sent out an email saying that there was a trojan on the network and that they’d be down doing some maintenance. ETA was only a few hours.

It ended up being 117 hours, to be exact.  Though there’s little evidence as to what happened between then and 4pm today, what we do know is that UC Webhost was acquired by Impact Hosting, LLC as of 4pm. We’d managed to recover the old files from our prior hosting company and have since moved to BlueHost, which we think will end up being more reliable.

Our apologies for the inconvenience. Outages are an extremely rare occurrence and we’re working diligently to make sure that it doesn’t happen again. Feel free to email us with any concerns.

via Providence Business News and RI Business Plan Competition

So remember, there’s two opportunities to support the Speramus you know and love:

1. The Brown EP Business Plan Competition Finals, Saturday, May 1st, at 1pm in MacMillan Hall. The audience even gets a vote on who wins at this one, so be sure to come!
2. The RI-BizPlan Competition, Tuesday, May 4th, at 4pm in the RI Convention Center for Business Expo 2010. This one’s for $40k, so we’ll be amped if you stop by!

I can’t put into words how exciting this process has been for us. With all of the hard work put in, all the helpful advisors we’ve had, and all the kind words of support we’ve gotten, it already feels like we’ve won. Thanks to all of you!

Also, for those of you who are social networking savvy: We’ve started up a blog (http://speramus.com), a twitter (@TalkToSperamus), an RSS feed, and a blog newsletter list. Plenty of ways to keep up on the latest Speramus news!

On a side note, we’ve written a few words of reflection on the competition. A few people have asked why we aren’t in the SII Social Venture track of the competition, so we’ve written up a few words below.

Brown EP is an interesting contest for us because it presents two different application options for entrants, allowing you to self designate as a for-profit business or a social venture. As many of you know, Speramus operates under a triple bottom line and is dedicated to bettering our communities while still making a profit. We’d were a natural fit for the social venture track.

Except that we weren’t. Surprisingly, the competition stipulates that a social venture can be non or for profit, but must limit returns to investors to a very low percentage to ‘keep management and investors focused on the social mission’. Unfortunately, this stipulation cripples what we believe is the strongest advantage of social ventures: allowing people to do good while doing well.

Yes, we are a business, and we try to make money. But the way Speramus makes money is to create value for the nonprofits we serve. Our business philosophy, and more concretely our revenue model, is tied to increasing the success of our clients; the better they do, the better we do. There’s an incentive on both sides to ensure the success of the other.

Contrast this with a situation where Speramus had to isolate our performance from our profits. Suddenly, there’s no incentive to improve the product, because no matter what our profits are capped at a certain, low percentage. Investors have no reason to invest in us as a risky start up that won’t provide any returns, and the platform never goes anywhere. Fundraisers lose the productivity of the Speramus platform, and everyone is worse off.

It is this exact mentality which we’ve seen fundraisers struggle to overcome. Studies have shown that organizations which invest in structural improvements (software, training, and other things which benefit the organization itself) are more efficient and have higher impact than those which strive to use all donations for program expenses. This all makes sense – a better run organization can better deploy the funds that it has. More funding gets better staff, better training, and better service.

But it is the rare donor who gives a gift with the intent of funding structural improvements; donors feel like their gift is being better used when it goes to the program rather than getting better administrators. Something just makes us feel uneasy when a gift goes towards paying a salary instead of the soup kitchen’s food, even if we know that the salary will improve the quality of the soup kitchen several times over.

The same fallacy comes into play by requiring a plan to limit returns to investors. It might feel like a better deal for nonprofits, but upon closer examination it does more harm than good.

Our unique fundraising approach breaks down an organization’s work into small, distinct projects that are shown to high potential donors automatically identified through our HopeRank system, a targeting algorithm developed in conjunction with Decision Science experts at Carnegie Mellon University which considers factors like interest, giving history, and personal context. Speramus’ online service allows organizations to improve the level of service offered to donors at low costs and with minimal additional work, creating a sustainable link that turns one time donors into lifetime partners.

Who are we? For one, we’re the 2nd place finishers in the RI Elevator Pitch Competition, edging out a competitive field of 31 ideas. We’re also semifinalist in both the Dell Social Innovation Competition and Rhode Island Business Plan Competition, and are in submission to a few others. But we’re also students, fundraisers, activists, programmers, and people.

But who are you? Are you a young activist looking to start the next “Kiva for ____”? Are you a current nonprofit development officer looking to increase your online fundraising success? Are you a nonprofit leader looking to redefine the relationship you have with your constituents?

Speramus is looking for beta testers to help us develop software that suits your needs. Your input can help us make Speramus better, helping us make fundraising smarter, easier, and less daunting than ever before. You can take your organization to the very cutting edge of technology, way ahead of those, other guys (We won’t say who, but it rhymes with Shmackbaud and it costs a pretty penny). Oh, did we mention that as a beta tester you get access to Speramus for free, forever?

Let’s talk.