Our open source 2019 Profit & Loss
2019 was our 4th (formal) year in business — and in a lot of ways, it felt like things started to click for us. We tweaked our billing model to be a little more forgiving, grew our team to 19, and started putting in place some new hires to help us button up our ability to create great work.
Rather than talking about work details, this post will cover 2019’s business: what we learnt, how profitable we were, how this effected our team, and where we’re going in 2020!
Historical Posts:
2015 & 2016 | 2017 | 2018
2019 — In a nutshell
- Did $1.715+ million USD in revenue
- Grew our team to 19
- Started building out a (secret) design offering
- Went to Prague, Likeminds, the Glass House, and did a cute ski trip
- 🔥 Doubled our profit share pool for the 2nd year running ($51k to $110k)
- Kept working on our podcast humans+computers with Human
- Sebastian Odell took our 12 week sabbatical for the first time ever!
Note: Net Income on our profit & loss statements is after profit share, and therefore not indicative of our effectiveness at face value.
You can find our Profit & Loss Statements on Github, too:
Things we learnt
Moving to Typescript
Every project we launch includes Sentry for bug tracking, and I get notifications for pretty much all of them. After 4 years of this, I can safely say the majority of bugs that come through our error tracking are trivial mistakes likeTypeError and friends.
Sanctuary has grown to ~10 developers, and it’s no longer possible for a senior, veteran JS developer to check every line of code for safety. For that reason, we’ve switched to using Typescript exclusively for all projects, and nowadays heavily encourage functional programming.
We’ve been saying Typescript is the best business decision we’ve made all year. It’s made an enormous difference to our software reliability— pretty much all we see now “real” business bugs, that we can fix super fast!
You can read a bit more about this shift here:
FICA Tax in Profit Share
For the last couple years, when we’ve distributed profit to our team, we’ve not accounted for FICA Tax. FICA is taken out on top of bonuses given, and for this reason, we’ve actually paid more than our Profit Share calculator intended the last couple years.
So! I made a PR to our calculator that now accounts for FICA before calculating profit share. More here:
Billing with a not-to-exceed Cap
When we first started sending out proposals, we wanted to create a sense of safety for a clients — they were taking a chance on us, and we were (and still are) super grateful! For that reason, we’d work to “fixed cost” SOWs. Our quoting process is modular and open, and clients
However, we were losing money on scope creep. See — in our efforts to be hospitable, we would agree to small features / changes that weren’t in the SOW; and when they inevitably added up, we’d end up doing the last week or two of a project for free, cutting into our bottom line.
So! We started billing by “time and materials”, with a not-to-exceed cap. We’re still using our open and transparent quoting formula, but it works like this:
- Our estimate might be 10 weeks @ $5,200 per developer per week
- Our SOW will note that estimate ($52,000 USD), but not that under this SOW, we’ll not exceed 120% of the estimate ($62,400 USD)
- As the project goes on, we’ll bill monthly for the development resources, keeping our payroll in check
We haven’t gotten any pushback here — and instead we’ve found that a structure like this incentivizes the client to keep the SOW tight: it’s now a group effort to avoid scope creep!
Introducing our Skill Tree
Around mid-year, we started consulting with Eva Green (on recommendation from pals Playlab) by way of a general audit of the studio. The process was amazing, as Eva interviewed each team member one-on-one, allowing insights and candor that isn’t usually easy to share (albeit everyone generally speaks their mind at Sanctuary).
We found one big gap in the way we were doing things: people didn’t have a clear understanding of how to progress in their careers, or grow their salary!
So — as a way to help everyone from juniors to project leads understand where they sit, and the direction they’re heading, we’ve introduced a Skill Tree. Each year, we sit down with the individual, and work through the skill tree to assess their level of contribution. This ultimately maps back to a salary band, so that we can openly and honestly set salaries in a (virtually) bias-free way.
In one-on-ones (I’m hoping to run these at least once a quarter), we’ll talk a bit about how an individual can grow and climb through their current salary band by focusing on key areas!
📈 Sanctuary over Time
Gross Revenue Growth
Because our profit is shared at the end of the year, we instead like to use gross revenue as a crude metric to help measure the general growth in velocity of incoming business for the studio.
2015 ($127k) — 2016 ($420k): 3.3x Growth
2016 ($420k) — 2017 ($813k): 1.93x Growth
2017 ($813k) — 2018 ($1131k): 1.39x Growth
2018 ($1131k) — 2019 ($1715): 1.52x Growth
On average, Sanctuary Computer’s gross revenue has grown at a rate of 2.04x per year (down a little from last year, but still looking good!)
Profit Share Pool Growth
What actually matters: our ability to generate profit, and share it amongst our team. Growth is dependent on a lot of variables. Read more over here.
2017 ($26,673) — 2018 ($50,996): 1.91x Growth
2018 ($50,996) — 2019 ($110,301): 2.15x Growth
Profit Share Unit (PSU) Value Growth
A Profit Share Unit (or PSU) is vested for every full month a team member spends at Sanctuary Computer — capped at 48 (or 4 years). An individual’s profit share is: PSU issued x Value per PSU
2017 ($313.21) — 2018 ($366.88): 17.14% Growth
2018 ($366.88) — 2019 ($409.85): 11.71% Growth
Average Growth: 14.35%
🌟 2019 in Retrospect
Last year, I kinda lied
In last year’s post, I said that I was “firing myself”, and moving into a CTO role. To some degree that was true: I was overseeing high-level architecture on a bunch of parallel projects, dipping into each when necessary, and helping developers code their way out of various problems.
BUT. I’d be lying if I said I moved away from being an individual contributor.
In 2019, we shipped our first our first operating system for Light. It turns out that building a phone OS is incredibly hard; both from a technical level, and a team to team level. You can read more about how it was built here, but what that article doesn’t cover is that I personally:
- Travelled to Taiwan & China 5 different times for a total of roughly 80–100 days (working 14 hours straight on most flights)
- In the days that I was in Asia, I’d often work 10–14 hour days so that I could support the NYC team on the inverse timezone
- Worked almost every weekend in 2019, usually both Saturday and Sunday
- Didn’t take a single vacation or sick day in 2019
- Personally wrote thousands of lines of mission critical Java, Flow, Elixir, and system level code
I’m proud to say that everyone else at Sanctuary kept a 32 — 40 hour week in this time period. I was the only person effected.
In the times that I was away, the team did an awesome job keeping things running — but of course my being on a different timezone meant there were some things slipping through the cracks — most specifically, it ended up being my job to also ship a dental insurance calculator on a very tight deadline. This was the straw that very nearly broke me in 2019.
Without this level of effort, I’m not convinced the Light Phone II would have launched at all; so while it was completely insane, it has now equipped our studio with a couple huge competencies: hardware, and telecom. These are big, exciting categories, and we’re excited to do more work like that in the future.
🌟 2020 Gameplan
OK, so can I be a good manager now?
Sanctuary Computer is now 19 people (plus two contractors), and we’re planning to add at least 2–3 folks to the team before the end of the first quarter.
Last year’s insane workload highlighted more than ever the key organizational problem we have: that I’ve built myself into a bottleneck. I’ve done this in a two key ways:
- To date I’ve not hired anyone more experienced than myself, meaning that the hardest and most time sensitive tasks fall to me, and there are a lot of them these days
- I’ve conducted the “technical discovery” phase for all of our projects, meaning that I continue to own the architecture and key decision making responsibility for all of the work we do
In order to attempt to “build myself out” of this position, this year, we’ll be making a key strategic hire: a dedicated tech lead. This person should have 10+ years of programming experience, and should be able to comfortably slot into and lead any of our projects, be it requiring an expertise in React, Redux, Ember.js, Rails, Elixir, Node, Kubernetes and more.
In addition, I’ll be teaching developers how to run “technical discovery” phases, so that I can ultimately distribute the responsibility of making architectural choices and guiding design, dipping in only to mentor, consult or pair program directly with the designer or developer, rather than owning the entire product, start-to-finish.
The result: I’ll slowly (over the course of the next 18 months) be able to focus on helping and empowering the team, rather than shouldering 100% of that responsibility myself; ultimately making Sanctuary less dependent on my contribution, and thus much more resilient.
Nurturing Sustainability
Somewhere in 2019, I cowrote an article with Rachael Yaeger (for VAULTE magazine), speaking to the responsibility that we all have as creatives. As we sit and watch our planet melt around us, it’s easy to forget the place we can have the most impact: by working to reshape the culture around the type of work our community creates and praises.
As such, this year, we’ve collectively decided that we’re going to refocus the studio on doing work that causes no major damage. Some of initiatives we’re planning are:
- Making the studio carbon neutral & offsetting where we can
- Moving to servers powered by renewable energy
- Offering an “innovators” discount for entrepreneurs working in sustainable farming, renewable energy, ocean cleanup, and other such industries
- Defining a “rubric” for how we pick and choose our clients, so that we can go into new client engagements after vetting their impact
- Pushing founders to introduce sustainability into their launch and marketing strategies
These days, Sanctuary team members pretty much only find satisfaction by working on projects that “do no harm”. The work is always better when the team is proud of the product.
Moving to React Hooks
We’re fluent in Typescript now, but there’s still a problem — we’re writing class components most of the time! That means we’re still inherently using this in plenty of cases.
In order to create more predictable and testable code, we’ll be moving to functional components, and React Hooks for virtually every use case, as this will allow us to knock this out of our React lexicon for good.
Investing in UX Design
For the last few years, whenever a client came to us with an “idea” (and not much more), we’d string together a team of freelancers to conduct the discovery and design phases.
This works OK, but there’s a couple key problems: we care deeply about design, and for that reason we’d work only with very experienced (read: $expensive$) contractors — they’d chew through a large chunk of a client’s budget, meaning there wouldn’t always be as much left for development as we’d have liked. We’ve always felt like billing extra on top of a contractor’s time is unethical, but in hindsight, we often lost money during these phases when you factor in our time managing all of the parties.
Worse still — our developers would often feel left in the lurch as they discover parts of the website or app they were building that had been forgotten by the designer. We’d end up having to just “design in dev”, which is time consuming, and given timelines, often results in the least thought-through parts of the system.
So! This year, we’re building out a high precision UI/UX studio that will stand on separate legs to Sanctuary Computer. The idea: to have an in-house, highly aligned, but loosely coupled experience offering to build better work faster, and with feeling.
🤫 This offering is still mostly “secret” — more on this coming mid year!
Building products for creatives
Last year, we built some nice open source projects on the side:
- You may have tried Basement.css:
But what we haven’t yet released are:
- our decentralized build pipeline, named Crystalizer
- our SSR-at-the-edge CDN, named Spirit Fish
- our bookings tool for Shopify, named Salon
- our open-source accessibility regression tool, named Candelabra
- a few early stage super secret ideas around Figma
Our forever goal is to build tools for creatives so that we can generate at least 10% of our yearly revenue from internal products. In 2020, we’ll be doubling down on this RnD, as we’re finally getting to a place where our stability and speed is strong enough to do this.
Let’s keep chatting!
Wanna talk more?
Please reach out at hello@sanctuary.computer — we’re friendly and open and would love to chat in greater detail on some of the specifics here.
Ultimately, we believe that large, full service agencies are becoming less appealing to clients out there, and instead, we’re hoping to encourage a world where nimble, specialist companies work together to carefully create intimate & unique work for clients, at realistic prices.
So get in touch! We’re always down for a margarita @ forgtmenot.
