This is generally true. I had a technical cofounder for the first 4 years or so, but once our tools were built it was less clear what his ongoing role would be.
This is because at that point, our focus turned to licensing our (patented) technology to businesses. We still have B2C customers who use the tools that he originally built (and which have been updated by contractors after he left), but now the vast majority of our revenue comes from our B2B licensing.
We are pretty unique in this regard, since most startups aren't able to generate much revenue from licensing in this way. Specifically, when we work with our licensees, we provide a JS library that they plug into their own platform. We don't need engineers to do integration work, or provide support.
My technical cofounder provided a lot of value in getting us to where we are, for sure. But needing a technical cofounder to launch doesn't necessarily mean you need one all the way along.
The clients don't want us mucking around in their code, which is why they have their devs do the work. There are some cases where having a dev on our end could help unblock their devs, but these are pretty rare cases. In general, it's very easy for folks to use our tech, and I'm able (thanks to a couple years of CS back in the day) to help out with the vast majority of questions that come up.
In terms of changes, there aren't any material changes. We've had licensees up and running for 7 years without changing any code.
Usually a company with software need to develop new features, reengineering to reduce infrastructure costs and improving performance bottlenecks, maintenance, etc. Do not you have that in your company? And if you do, who is leading those initiatives?
We are not innovating on the core product, which has remained static for many years. Instead, we are pushing adoption through our licensing partnerships. We now have over 250k students using our reading tech through education platforms that we work with. Building more of these partnerships, based on the data we have gathered from our existing partners, is the focus.
Sounds like at that point you're not really a tech company. Your tech might as well be some off-the-shelf stuff as far as you're concerned, if you're not actually working on it any more.
Interesting perspective! So if Dolby had stopped making new versions of its technology and just licensed what it had until people stopped buying it, then it wouldn't have been a tech company? What kind of company would it have been?
A sound company, or whatever the technology in question does? If you're in a position where it's viable to not be making new versions of your tech then presumably that means you're in a field that's at least somewhat mature as its own thing. I think there's a temptation to equate "on computers" with "tech" whereas for a lot of fields doing it on computers is pretty much commodified now.
In our case, we're growing via adoption of our first generation core product. I could definitely make a second version, but it wouldn't help overcome the primary challenge we face with adoption, which is that the technology looks unconventional, and isn't well-enough known yet. Making a more complicated version wouldn't help with this, and might not even improve the efficacy. It would also require internationalization, whereas our current version is language agnostic.
So it's not that we won't ever create a newer version, just that it's not the primary focus.
I mean not all businesses need to thrive. If the thing generates significant profits for a while then the founder can retire and either sell it or just let it die. If it's not a publicly-traded company there's no fiduciary duty to do anything more than that.
If we were riding on momentum I would expect our revenue to be stable/shrinking, not growing (as it is). I agree that in the long term this is true, but when you start as a tiny speck, you can grow for a long time as awareness spreads. For example, we started our in education and are now getting interest from news/media organizations. This is without changing the core functionality at all.
>> My technical cofounder provided a lot of value in getting us to where we are, for sure. But needing a technical cofounder to launch doesn't necessarily mean you need one all the way along.
This is a good point, but it should be clear that you would not have gotten to this point w/o the technical co-founder.
The problem is that once you get to this point, less than honest non-technical people seek to marginalize and eventually consume the equity/payout of the technical co-founder that often took the original risk.
It is critical that technical co-founders maintain equity and FIGHT hard for what they have earned and enabled, do a fair extent of the value they added.
What so the person who "provided a lot of value in getting us to where we are" got ditched in the end? Is that your story? Use people and then chuck them to the curb once everything u need has been extracted?
Absolutely not — he vested founder's shares just like me. And then I continued to work with no salary and no additional vesting for years after that. Also, I was working full-time while he was working nights/weekends.
I assumed he got some $$$ - but did he want to be removed or did you tell him he was no longer needed? Was he just as sure that he was no longer needed as u were?
>> What so the person who "provided a lot of value in getting us to where we are" got ditched in the end? Is that your story? Use people and then chuck them to the curb once everything u need has been extracted?
Technologists beware -- some business co-founders will treat you honestly and you'll be paid fairly. And some will not. You need to read this comment and realize that both outcomes are possibles, especially once lawyers, VCs, and other business people get into the mix.
> especially once lawyers, VCs, and other business people get into the mix.
This is unfortunately true, since the VCs are only interested in the forward-looking value of the enterprise. They would prefer to dilute other shareholders (including founders — and especially former founders) to maximize future fundraising. And lawyers, of course, are happy to tell the VCs how to do this, regardless of what protections were put in place initially.
This is because at that point, our focus turned to licensing our (patented) technology to businesses. We still have B2C customers who use the tools that he originally built (and which have been updated by contractors after he left), but now the vast majority of our revenue comes from our B2B licensing.
We are pretty unique in this regard, since most startups aren't able to generate much revenue from licensing in this way. Specifically, when we work with our licensees, we provide a JS library that they plug into their own platform. We don't need engineers to do integration work, or provide support.
My technical cofounder provided a lot of value in getting us to where we are, for sure. But needing a technical cofounder to launch doesn't necessarily mean you need one all the way along.