Scaling Back: A Retrospective

Reflecting on the past two years.

TL;DR - Silicon Ally is shifting to part time - we will have no full-time employees going forward. We’ll continue to build features and maintain infrastructure for our existing projects and clients. We’ll also continue contributing to new and existing open-source tools for nonprofits. Our existing clients should expect no functional changes.

What we started #

When Grady and I started Silicon Ally two and a half years ago, we were at an inflection point in our lives and careers. After years in big tech (and a brief foray into startups), we realized we had acquired the knowledge and skills to directly serve the causes we cared about, rather than just donating to them.

The core idea of Silicon Ally was that there are already plenty of nonprofits doing excellent work, but most under-invest in technology because of the upfront costs. We thought that if we could help a few nonprofits operate more effectively, that would be far more impactful than the donations we had been making.

Pivoting to full time philanthropic work, we chose to start Silicon Ally rather than joining the organizations we wanted to help. We wanted the autonomy to choose the projects that we wanted to work on, and the flexibility to experiment with how we ran our organization and approached our work.

Over the last two and a half years, we’ve gotten to execute on this vision. We’ve worked with half a dozen nonprofits, we delivered a handful of big projects, made extensive open-source contributions, and helped our clients be more effective. The appreciation of our clients, and the launch of a few awesome projects are testaments to the real impact that we have had.

However, while we produced a lot of great software, we failed to produce a financially sustainable model for its development. Failure isn’t a dirty word - it’s pretty much a requirement for eventual success at anything even remotely difficult. The important part of failure is learning from it, and this post is a retrospective to attempt exactly that.

What went wrong #

In short: we ran out of money.

In slightly longer: we’re suspending full-time work because we’re unable to pay ourselves consistent salaries. While we’ve both been fine to skip a paycheck or two, our finances continue to be unstable despite our assorted efforts to the contrary. There’ve been a number of contributing factors.

Boom and Bust #

When working on large projects, there’d naturally be periods of lots of work (e.g. leading up to a launch or milestone or demo), followed by periods of very little work (e.g. while a client played with what we built and figured out what they wanted next). In a large enough organization, those peaks and troughs tend to smooth out since each project’s cycle is mostly uncorrelated, but we never got to a sufficient scale to make that happen.

Business Development Time #

We pretty seriously underestimated the amount of time it took to find new clients. This was mostly due to our own hubris and skewed perspective as software engineers. Our thought process sounded something like: “we’re literally offering free, high quality software development, it should practically sell itself”.

It most certainly did not.

We experimented with a bunch of mechanisms for finding work including RFPs, Job Boards, Cold Calls, and Network Searches, but none were able to routinely generate work, all the while eating up lots of time. And when we did find work, there was still a larger-than-expected lag between an org saying “we’d like to work with you” and “let’s start building”, sometimes on the order of 4-6 months, further straining budgets.

Beyond that, we were unwilling to use external “lead generation” and similar services (despite being inundated with offers), believing that doing the outreach ourselves was a better alignment of incentives, as we’d be the ones on the hook for doing the actual work. Plus, if our whole schtick is that we want to work on what we think are the biggest problems, it doesn’t make a ton of sense to spend our time working on any random available project.¹

Pricing Models #

We never really figured out a good way to charge for projects. Payments for early projects were done in lump sums after certain milestones were met (initial prototype, MVP, external launch, feature complete, etc). The nice thing about this approach is that everyone agrees on price and what’s in scope ahead of time, so there are comparatively few surprises. The downside is that it’s a lot of upfront planning, there’s a risk that our estimates are off,² even well-specified requirements can have miscommunication about needs, and not all projects can be fully scoped out from the beginning.

We later tried hourly work, which is a better fit for projects where the “final deliverable” isn’t totally known ahead of time (in reality, most projects look like this). Clients like it because it’s less of a big investment, especially when working with a young and comparatively untested organization like Silicon Ally. Hourly work allowed us to do more iterative development, crafting individual features, getting feedback, rinsing, and repeating. The downside is the more boom/bust nature of it, mentioned above. The other big (and to us, surprising) downside is that it turns out that we were legitimately terrible at invoicing for all of the hours that we work.

Even with two of us working full-time (e.g. 80 hours/week total) on a project, we’d frequently bill for less than 40 hours in a given week, subconsciously discounting all the time spent outside of direct feature development (designing + researching things, chasing down bugs, writing emails, grooming issue backlogs, etc). We’d also just occasionally forget to log an entire day (or more!) of work. Given that we’re already offering steeply discounted services, we did not have the margins to survive these kinds of mistakes.

This is by far the dumbest and, in retrospect, most obvious of our failures. Turns out you won’t consistently make money if you don’t consistently charge for your services. We did eventually correct this, using dashboards and visualizing the hours we’d logged to spot any gaps or anomalies, but by then we were already in a “bust” phase.

Too Much Unpaid Work #

We sunk a lot of time into two projects that ended up not generating the revenue we expected (read: any revenue). One was a CRM migration toolkit that we hoped to reuse, but couldn’t find secondary use cases for. The other was an internally-driven project, which we eventually planned to fund by pursuing grants and corporate donations. We spent several weeks doing research, scoping out the project, and pursuing funding sources, which ate up what little financial runway we had.

These headwinds made our (relatively conservative, but consistent) initial financial model fail. At its core, Silicon Ally was a bet that we could find and execute fee-for-service nonprofit projects at a rate that could sustain modest salaries. That ended up not being the case.

What we learned #

When we started Silicon Ally, we knew lots about building robust systems, and very little about the world of nonprofits. We figured it out as we went: building (and open-sourcing!) useful software and tools, turning clients into avid fans³, and creating the culture we had always wanted in our past jobs. We learned how to operate a fully remote organization, became passable product managers and UX designers, learned how to file a Form 990, write contracts, and deploy systems that are both robust and inexpensive to run. We built up the muscle of turning unknowns into plans into actions. We became unflappable - confident (occasionally overly so) in our capability to figure out new challenges and tackle unknown problems.

We grew personally and professionally, and (critically) had a lot of fun while doing it.

What’s next #

As mentioned at the top, we’re still dedicated to Silicon Ally. We’ll continue to build features and maintain systems for the orgs we’re already working with. We have ambitious initiatives we’re going to take on over time, independent of any single client. We intend to use this as an opportunity to build up Silicon Ally’s coffers, continuing to work as unpaid part-time volunteers (who happen to also be the board of directors) while continuing to charge our existing, subsidized rates.

That way, as we come up with software that we think many nonprofits can benefit from, we can invest in building that out (e.g. hiring UX + PM help as needed, paying for hosting) as part of an open-source ecosystem.

Though this isn’t what we hoped when we started Silicon Ally, the story is also far from finished.