Note 54: The Canary Phase
No one ever said the learning process would always be easy.
Why, hello strangers!
Apologies for my recent absence (yet again) and complete failure to get anything out before Halloween (including that cosmic horror story I haven’t had time to edit in the last three weeks). As per usual, business life has largely consumed writing life, as I spent a good portion of the last few weeks dealing with the aftershocks of October’s financial cruicible where I spent a good amount of time and mental energy getting institutions that owed me money to pay up. I’ve also been dealing with some shenanigans from groups who want me to work for them as we try to get contracts set up so that the intellectual property I’ve been generating for them can actually become theirs (upon payment for the work). Rather than dwell on this in the introduction, let’s jump right into it.
F*ck you, pay me.
The problem with going all out as I did last month to meet my tax obligations to Uncle Sam (not specifically taxes, but to my own retirement account, which determines my final taxable income) is that bills don’t pause for a few months while I catch my breath. I still have to pay rent for my small office, the Amazon bill that keeps my servers online, several software service subscriptions, etc. Running a software business is relatively cheap compared to most other businesses, but there are still regular expenses to cover. And in order to do so, I had to lean on a couple of clients to finally pay their invoices, else I have to abandon ship and find a Real Job to pay for the debt that I’ve accrued in the service of those clients and on their behalf.
One client in particular (a large public university) was a particular challenge. For them, I put together a text messaging system to supplement an existing study for rates that I’d usually take a pass on. I took on the job because they were a referral from another client, and the work it would take to get them running was actually well within the small budget that they allocated. I set them up back in September, and they’ve been collecting data since then.
Their invoice went into overdue status some time ago, and when I’d reach out to check up on the status, I’d get a response along the lines of “our financial department is slow”. About two weeks ago, I started getting more insistent (it’s amazing how quickly something will move when you CC an administrator’s boss), and made very clear that their “our financial department is slow” doesn’t translate into fiat currency that I can use to pay my bills. With enough daily arm-twisting, the funds finally showed up in my account. I don’t know if that client will work with me again, but I won’t shed a tear if they decide to go in another direction. Well, I will shed a tear, but a month or two later than when I should.
I’ve been dealing with similar issues all year, and with an eye to avoiding these situations in the future, I’ve started deploying something I call the Canary Phase in all new projects.
The Canary Phase works like this. Instead of jumping in and beginning any sort of software development or heavy design upon commencement of the project, clients are required to pay a small invoice for a small up-front task such as some basic design, requirements gathering, or feasibility investigation (I work with researchers, so this isn’t always obvious). Once we complete that initial task, I invoice the client and all work stops until that initial invoice is paid.
If the client can pay that invoice in a timely manner, that’s great - we can continue onto the bulk of the real work and I can be confident that the folks behind me getting paid have their act together. If it’s a massive undertaking to get that initial small invoice paid, then I know that I’m dealing with a bunch of knuckleheads and can adjust my level of service correspondingly. And while the knuckleheads are wasting time not paying me, I’m not out any major time or effort - I can work on others’ projects until the knuckleheads wise up and do their jobs. If my research client is frustrated at the halt in work, they get to be the one setting the knuckleheads straight, not me.
This process allows me to manage my own financial risk, assess which institutions are worth pursuing for future work (and which ones to leave on the side of the road), and gives me some data on how quickly I can expect to see payment from them so that my own cash flow modeling is built more on observed behavior than hopeful thinking on my part.
I’ve already sent out a couple of proposals with Canary Phases built into the project planning and haven’t received any push-back. It still hasn’t made it through the full gauntlet of university lawyers quite yet, so I’m not ready to declare success yet. However, between clients not paying their bills on time, other clients attempting to abuse the flat-rate quote I gave them (no, you don’t get carte blanche to translate it into an hourly billing arrangement), and other issues encountered over the past year, I’m starting to enjoy deploying my own inner Mike Monteiro:
It’s unfortunate that I have to start acting like a mob enforcer from Goodfellas - but it’s a mentality that will serve me well in the next phase of this company.
Revisiting being a “product company” versus a “services company”
When I started my company after leaving graduate school, the original thesis for the business was that I would do some consulting with academic clients in my network to pay the bills, while I worked on products that would decouple my earnings from the time and effort I put into them. While I did some work I’m proud of during those early days, it’s fair to say that none of those products really took off in the manner I hoped for. I built a number of fun and engaging consumer-facing mobile apps, tried my hand at creating a home automation company (at precisely the worst time), and a couple of other things that never really took off. With those dreams dashed, I accepted that I would be a Services Guy - by providing custom software development as my Service - and the Product Guy was consigned to the pages of my own personal history (the Mad Scientist in my personal Laboratory of Failed Monetization Experiments).
However, the Product Guy has been sneaking back into my life as of late. In the process of becoming a more effective and efficient Services Guy, I created a constellation of open source software components that allows me to assemble systems (like the text messaging service for the slow client above) in a fraction of the time it would take me a couple years ago. In the past, the complexity equation was greater on clients’ end of things as they’d ask me to build something custom and complicated than my own technology accommodated. However, as I built system after system, a series of patterns began emerging, and those patterns found expression in components like my dialog engine (let’s capture your complex workflow as a state machine than a series of one-off Python functions), data exporting system (I dare you to try and ask me for a data format I can’t accommodate), backup (would you like those files stored on Dropbox or Amazon?), and so forth.
What I’ve noticed - especially in the past half year - is that my initial consultations with clients are not so much about how we’d cook their secret sauce from scratch, but rather what spices and recipes that I already have that I just need to tweak slightly to see their sauce through to completion. With the exception of a few projects and areas, my own technology stack’s ability to deal with complexity is exceeding clients’ ability to express. It’s gotten to the point where I’m often the one suggesting innovations in their work, as they haven’t been thinking that many steps ahead. It’s allowed me to play the role of researcher or innovator much more frequently in these engagements.
Now, given that my tech stack is starting to run ahead of my service market, this presents a solid opportunity to take what’s routine (and frankly boring) and start packaging those items up as standalone products that clients can purchase instead of my services. Do you need to survey people via SMS with fraud detection and adaptive questionnaires? I’ve got you covered. Are you looking to gather behavioral data from a mobile phone to answer a research question? Let me point you to Aisle 15. Looking to build an augmented reality experience for your local community? Let me direct you over here.
With all the financial challenges I’ve been dealing with as of late, the question of whether I should pack it in and go get a Real Job was one I certainly pondered. In the past, what kept me pulling that trigger was my client relationships and the folks I’d leave in a lurch if I wrapped this business up. Recently, what’s kept me going has been the recognition that I’m sitting on a bunch of great technology that still has a way to go to realize its potential. So with that in mind, I’ll keep on truckin’, but the business emphasis moving forward will be less about “let me be your bespoke academic developer for your snowflake research project” and more about “let me sell you a product so that you don’t have to hire an expensive custom developer”. The queries and interest I’m getting for projects these days are more similar than not - I might as well run with it.
The great thing about a viable product company is that one’s financial rewards are no longer coupled to the time and effort expended, but rather to what extent the product has achieved product/market fit. This simply means that a company has found a product that people want and the company can sell it. A lot of start-ups expend tremendous amount of human and investor capital trying to find that intersection between their offerings and the people that will pay for it, and I realized over the past month that I’ve basically achieved that. I have plenty of research clients paying me for similar things, and I’ve gotten much more efficient at delivering on their requirements. I can either continue imagining myself as a super-efficient services-delivery person (where I’m still personally the limiting factor in any growth) OR I can start looking at this enterprise as an early product stage company that has achieved product/market fit, and start working on enacting the business structures that will allow me to hand off work to others and begin scaling the company far beyond what I’d be able to do as an individual (even if I were one of those mythical 10x programmers).
This has been an exciting realization for me, because one of things I’ve struggled with the most is seeking outside mentoring and examples of folks who built successful services companies. If I were advising someone seeking to do this kind of work as to what they should do, I’d advise them to join an existing successful services firm, and learn how those businesses operate from the inside. That’s a step that I largely skipped, and I end up learning tough lessons about cash flow and problem customers the hard way.
However, by switching the direction of the company in a products-oriented direction, I have access to entire networks of people and knowledge from my days spent in the start-up world. In many respects, I already crossed the product/market fit chasm and came through with several viable offerings intact. My own project pipeline lately has been more of a “pull” (from clients seeking very similar services) than a “push” (from I pitch custom development to clients), so the trick will be migrating from a services mindset where each client is special to a product mindset where each customer is mostly like the one before.
If it’s not clear from my ruminations above, I’m still in the very early stage of transitioning this company from one model to the next. I have quite a bit of work to “productize” this technology I’m sitting on, but the infrastructure to do so has been in place for some time. Several of my existing client projects themselves are scaling from a handful of sites to as many as twenty or seventy, so I’ll be doing that work regardless. So the plan for me over the next month in a half is to take what’s currently floating around in “Theory Land” in my head and pin it down enough so that I can kick off the new year with a plan to reach out through my network to find some other folks I can discuss this with, either for advice OR potential staff that might be helpful in navigating this turn.
This may also open the door to potential investors, but I’ll be very cautious about this, given that I believe investors have killed more viable organic businesses than they’ve helped. That said, I wouldn’t be opposed to investments from silent partners who trust me to see this to a point that makes them some money as well. The Bezos investment in Basecamp (née 37signals) would be a model I’d certainly entertain.
In the interest of not exceeding the mail limit for Substack, I’m going to put a pin in this “week’s” Note here.
I have a ton of books to review for you all, including a really fun one about Victorian amusements from Astrophysicist Extraordinaire Brian May. (I hear he plays the guitar as well.) The Book Reports will come back, but I want to note that I’m in the home stretch for my 2021 one hundred books read challenge. I’m terribly behind on that, and we’ll see if I can manage to knock out 32 books before 2022 is upon us. I’ve already resolved to finally read the nine Harry Potter books (a void in my cultural literacy), and I have some graphic novels lined up, as well as the remainder of the John le Carré George Smiley books. It’s going to be a hectic time reading, and should be fun to see if I manage to pull it off this year.
Next week’s also Thanksgiving and I’m working hard on getting ready for that. I’m largely planning to replay last year’s menu, and I’m looking forward to having more folks over this year now that we’ve all gotten the jab. Should be a fun time, and I’ll check in before then.
In the meantime, let me leave you with a trailer for what we’ll be watching while everyone battles their own personal Tryptophan Demons:
I’m going to miss these days when studios aren’t so busy dropping quality content on their streaming services.
Until next Note (hopefully next week), o7 CMDRs!