Five years as a startup CTO: How, why, and was it worth it? (2024)
distinctplace.com
distinctplace.com
First, this post was from 2024, and as another commenter mentioned, it doesn't look like Helios Companies (www.helioscompanies.com) is a going concern anymore. That's not that surprising - the change in the interest rate and VC funding environment killed off lots of unprofitable fintechs that were originally funded in 2021 or earlier.
I'm not saying money is the end all and be all, and this guy certainly got a lot out of it. But assuming this company is now defunct and he didn't get any substantial payday out of it, would he do it again knowing what he knows now? When you think about it, we all have relatively very limited time in our careers - while VCs can fund 100 different companies with the expectation that 95% will fail, workers don't have that luxury. Putting in 5+ years of lots of late nights and blood, sweat and tears can be tough if the outcome isn't a winner.
So I'm left wondering if the author feels like it was still worth it.
To be honest, I find it kind of bizarre that your company doesn't appear to have any public web presence. I also worked at a B2B-only fintech very recently, and we still had a website. Heck, my neighborhood barbershop has a website. I know it sounds like I'm knocking y'all (and maybe I am a little), but I'm honestly just curious. If I were a tech leader at a bank and got a direct sales call from a vendor and they said they didn't have a website, I'd just assume it was a scam. It must be working for your company so I'm very interested in how you haven't found the need to have a website in 2025. That I think would actually be a more interesting blog post!
The amount of bad / low quality leads that they generate is insane if you're in any market that isn't purely D2C. So many people hours wasted dealing with churn.
That's not even accounting for the sheer volume of spam it'll generate from other businesses trying to cold-pitch random SaaS products and contractor outsourcing companies.
My favorite / most hated tactic is calling someone in the org and telling them that they're trying to return my call, hoping that the message will get passed along and the actual details (such as who they represent because I certainly never called them) get lost along the way.
I know it sounds silly but not having a website is probably the future of the web.
Now if you search nothing matches.
https://www.linkedin.com/search/results/people/?firstName=Sh...
So even if he has a Linkedin page, it's clearly not meant for anyone to find....why?
I personally loved the takeaways. They resonated with my startup experience, esp: "Not all business problems require technical solutions". I think as devs/engineers, we're in love with technical solutions, but they are not always the right choice. Other options include:
* customer support
* duct tape solutions with platforms like Zapier
* saying "we are not going to solve that problem" and letting folks that need that solution go somewhere else
I know more technically inclined than not that can easily identity this situation. At least my CEOs have a tendency toward thinking we should pursue any path that likely leads to some income stream...
Sales driven growth is great until it isn't.
- Jira Epics (describe the why from the business standpoint)
- HQ meets two times a week to re-asses priority (drag up Epics up or down, or change priority) and monitor status
- Two week sprints where engineering leads along go through epics
- New sub-tickets created by engineering (including design) and assigned to specific people.
- Once thing are getting done, they are move to QA test status. After testing it either goes back to engineering or to Release Approved status.
- Engineer initiates and monitors the the release via CI/CD Jenkins pipeline.
That's pretty much it on the high level, unless I'm forgetting something.
One important note here - some time ago we made a decision to ignore "good ideas"/backog. We don't keep them in Jira until business is sure that we really need this particular functionality and ready to start building it right now.
That was somewhat radical and took some time to get used to, but it allowed everyone to focus on what's important now vs nice to haves to keep people busy with things noone really needs.
Overall there is no "generic" advice, everything is very org and stage specific. Common sense is the main guiding principle.
If the author is reading - can you elaborate on this?
Aside from writing end-to-end test automation, the best SDETs add value in many other ways. They triage bugs, use their deep product understanding (frequently the best on the team) to refine requirements and build test plans, coordinate bug-bashes and large scale releases, measure and report on quality metrics, and much more. All of this takes considerable load off other members of the team (SWEs, PMs, EMs, etc), allows the whole group to ship with much higher confidence, and increases the number of defects caught before making it to production.
If you have an organization where end-to-end tests are easy to write and very quick to execute, then I think the need for QA folks is greatly reduced. In my experience, once there's enough complexity and scale to a product, it's basically impossible to have a rapid TDD loop with enough end-to-end coverage that allows devs to ship features with perfect confidence. Combine that with all the other "hats" QA folks wear, and I think it's is a role that pays dividends in product quality and the efficiency of others across the org.
At the end of the day someone needs to answer a simple question - "Is the product functional right now / after the last release?".
If you don't have QA team you either rely on your product person to "give it a spin" or your engineering who are generally not very excited about clicking through the product multiple times (more often than not, they'll just leave it at the unit test phase and move on).
In small orgs that product person could be your CEO or CTO, meaning this will give them an easy false-escape into "micro-management" mode (aka feeling productive by doing low priority tasks) vs forcing them to make strategic decisions or worse, they'll just block the entire pipeline.
QA creates a natural quality gate looking at the product from the user's perspective, putting pressure at the engineering to deliver quality work and gathering leadership feedback at critical points only.
At the moment our engineering is ahead of our sales - which gave me some capacity to lift my head up and test my skills relevance against the market on the fractional/advisory capacity potentially turning into revenue stream with more control from my side.
You know how it works for us with engineering minds - you always consider worst case scenarios and try to mitigate them before they become real problems.
Based on my experience it typically works in cycles, where you need some sort of fresh blood every five or so years to re-kindle the spark and keep going.
It's been great five years for me and my family, exactly what I was looking for before the transition from stable corporate world.
I guess it depends a lot of personality and the type of work you enjoy. I thrive at early stages, where most things a built on common sense and you have enough power to shape things into something meaningful.
These days I try to appreciate "the process" (day-to-day) over "results" (exits).
You don't really have too much control of how things unfold in your life really, be blessed you are alive and kicking.
Do I say money is not important? Of course not - it's very important, but in a challenging times you have to test your limits and re-assess your priorities (whether you like it or not...)
It's easy to look at things in hindsight - the question is what is the alternative? 5 years of what?
Then, in a group, probing together for 12 factor app or AWS well architected type principles as well as something like BSA security principles, gets you a very long way.
The framework doesn't matter, just something to cause a beat of design, ops, and threat modeling and "rugged manifesto" thinking.
Even more questions to the business / CEO ( Why this, why now )
"why", "how", "can we", "who can"?
Just try to be humble in the world where nobody knows anything (including yourself)... :)
I knew someone who chose to major business despite he got an offer for top biology degree in my country, for this exact reason. By the way, when he told me this decision we were both only 17.
(I really should ask whether he still thinks that's what business is all about today though.)
Every job sounds much easier from the outside.
I helped found a startup[0] and have been around a number of them, in slacks and on email lists[1].
I think that domain knowledge is so so important for startup success. Even more important than technical expertise.
Why? Because the main problems for 0->1 startups are business problems, not technical ones:
* where do possible customers hang out
* what problems will they pay you to solve
So in that case, a good CEO who knows the domain is critical. They'll have good answers to these questions, which will help guide the technical decisions. Or they'll know who to talk to in order to find the answers. There's no shortcut to that knowledge; you have to spend years to get experience in the domain. Learning and reading about the domain can help, but you still have to spend the time.
The main exception, and it's a big one, is if you are building something in the devtools space, where you can be your own customer.
0: https://www.thefoodcorridor.com/ (I left after a few years, but they are still going strong!)
1: https://ctolunches.com/ (free email list for engineering leaders, so many good discussions happen there)
Especially with the existence of AI, it really makes no sense and is some weird hierarchical system built by business people
Can you recommend any resources for learning how to do this work yourself?
1. pick a vertical (construction, legal, accounting, etc)
2. look at how to apply ai (compliance, voice customer service, email)
3. find sales people from a would be competitor or old school b2b saas in that area, and pay them 150$ an hour to tell you what customers are paying for
4. at the direction of how to do sales, come up with the product and either do the sales yourself without building, or pay someone to do cold calls and pitch the product
5. build the product
- the lean startup: https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous...
- Amy Hoy's blog: https://stackingthebricks.com/
- working in the domain you are interested in for a year. Go be a realtor. Go work in a lawncare business. etc. etc.
- read Patrick's advice about how he found customers for Appointment reminder: https://www.kalzumeus.com/2010/05/14/unveiling-my-second-pro...
edit: added link to Patrick's piece
But your argument still has validity even if it takes 2-3 years to gain the knowledge, so let me address that.
My response is: if I wanted to be an expert in <startup domain> to the point I didn't need a co-founder CEO, I would take the time, the years I mention above. But that has costs (opportunity costs if nothing else).
Instead, I prefer to be an expert in software development. This gives me less control in each given startup as you point out, but more optionality across startups (and other companies)[0]. This choice also means that I give input on the hard decisions that company leadership has to make, but I don't have to make the final call. Frankly, that's more weight than I care to bear.
That's a personal choice. I've watched friends be CEOs of successful startups and it's not always (nor usually, even) fun or easy.
0: I wrote more about that optionality here: https://www.mooreds.com/wordpress/archives/3445
This idea often gets repeated here but it’s based on ZIRP from 2010s driving up developer salaries to a point where every kid with some portion of a CS degree thought he was the next Zuckerberg. “Technical” contributors became convinced they were the only contributors. Lots of stories about “idea guys” and useless upper management who Just Don’t Get It (meanwhile most guys posting things like this have never even seen a balance sheet). It’s a popular idea here because it establishes devs as the smartest guys in the room, but it doesn’t have a lot of bearing on reality. Plenty of devs have neither the aptitude nor inclination to learn the business side of things, as evidenced by some of the lifers who post here about upper management.
This attitude will change as market cools off, no code and LLM output improves, and overseas contractors become more accessible.
> Especially with the existence of AI, it really makes no sense and is some weird hierarchical system built by business people
LLM code output can be tested as it is generated, whereas its advice on accounting and contract law can only be tested by domain experts, who you can just pay for this advice without involving the LLM.
"If you are a technical founder, you do not need a non-technical cofounder."
https://x.com/snowmaker/status/1948160642399314188
Its really not up for debate, at this point it is a borderline scam to work for a CEO that isnt significantly better/bringing in capital. You are basically giving them free labor
If nobody in your startup team wants to handle sales, marketing, finances, and business operations, you're going to end up with working software that nobody's paying for.
Or are we talking about Dropbox and Airbnb?
I never contested that. My point is that there are plenty of devs who think they should found a startup based on the mistaken idea that they can learn the business side of things overnight.
Assuming that passing some tests means it’s good code is as dumb as asking the LLM accounting and contract law advice.
It can be superficially correct and completely broken.
This also applies to developer output. If you don’t have someone qualified in the loop to foresee problems and perform testing, you could end up with something that falls over later on, but by the time that is consequential you can pay someone to do that kind of testing. By contrast, a dev who decides to be his own lawyer only gets to test the validity of his contracts if he hires a lawyer or gets sued.
I don’t think you have a salient point here.
The existence of bad surgeons doesn’t make performing surgery on yourself the better alternative.
A sufficiently-motivated analyst can hack together an app and test it as he goes. Yes, there might be scaling issues and edge cases, but he’s putting together a proof of concept; once he has validated the market, the developers who build the app “correctly” are effectively interchangeable. There are questions of professional ethics if the software is touching anything to do with medicine, personal information, or other sensitive issues like that, but that does not represent a majority of development. If you mean “good” in the sense of being artful or efficient, then no one cares.
I don't think it is just the ZIRP/2010s. Here's a post I wrote about developer arrogance in 2004, well before the ZIRP era: https://www.mooreds.com/wordpress/archives/134
Of which LLMs are effectively a dev tool that happens to also be a tool for every other industry vertical in the world economy.
I've been a solo founder as well multiple time co-founder / CTO at venture-backed startups so I'm certainly capable of starting something myself, but I think this combination is an excellent model. A couple of other things that make it work: the CEO has sales skills, and does not have much of an ego and is willing to listen to someone who has been through all of this multiple times.
Yeah! You definitely need to have a good CEO as a partner. A bad CEO is worse than no partner at all.
Those are some great attributes of what makes a good CEO and partner.
The typical B2B SaaS startup never gets that far.
You're looking at a survivorship bias subset. If someone had an automatic path to get to that promised land then it would be an easy choice, but it's never that easy.
A 500K ARR SaaS is also hardly a path to financial freedom. That's too small to hire a competent engineer while also paying yourself a high salary, so you're basically on call all of the time. You're also doing sales, customer support, and possibly fretting a sudden 100K drop in your ARR if your biggest customer cancels their contract because the economy changes.
All of your comments in this thread assume success. Great if you can get it, but it's not guaranteed.
> People dont know but it helps in both dating life and social situations.
Much less than you think. Some people are impressed by it, but spend some time in a startup-heavy area everyone will see right through the "I'm a startup CEO" schtick for someone who has a $500K ARR B2B SaaS, or even just someone trying to fork off and do their own thing.
While it is impressive to start and run a successful small-scale SaaS, it's far from guaranteed. Thinking it's a route to dating success is just weird.
Even after all the layoffs and cost-cutting one of them went through, the end result was mediocre paying jobs for a few people at most, with constant on call and fire fighting. One ended in a "acquisition", which was actually a pennies-on-the-dollar fire sale, with no payouts to the founder or any employees. The former CEO still talks up the big acquisition. It sounds like success if you ignore all the details.
This happens a lot. A company wants to recruit someone who has good skills but has been trying, unsuccessfully, to get their own startup off the ground. They offer an "acquisition" on paper which purchases the company and brings them into the company for a token amount. This gives the founder an easy out, a job, a hiring bonus, and a way to update their LinkedIn to show that they built and "sold" a company.
This only makes sense if you assume the startup will fail and you ignore all of the high-paying engineering jobs out there.
If financial freedom is the goal, the easier and far more reliable path is to pursue the well-trodden road to a job in Big Tech and put some minimal effort into the promotion process.
The average startup founder does not walk away with financial freedom or even a functional company. The average outcome is that the startup doesn't work out and they pay the opportunity cost of having lost out on years of career income.
Even the acqui-hires and small time acquisitions that happen in my local startup scene rarely leave the founders with more money than they could have earned at a regular 9-5 engineering or EM role.
It's only a select few who get that coveted large exit that turns into financial freedom after 5-15 years of grinding.
It matches my personal experience (the most technical CEOs I work with consistently underperform) and the industry averages (the majority of the companies that make it big have CEOs who aren’t deeply technical).
That includes YC to- from Coinbase to Dropbox, the CEOs are hardly strong technical people (some have CS backgrounds, but they don’t really have a career as accomplished technical individuals and aren’t exactly know for their incredible CTO careers).
They all failed at sales, scaling, retention, and generally running the business.
I did work for one very successful company that was founded by an engineer. However, he was focused almost exclusively on non-engineering business functions from the start.
If you want to be a CTO and do engineering things, don’t assume founding your own company is the best way to get there.
This also applies to most non-technical, “business folks”-led businesses as well.
A startup is a kind of ponzi scheme benefitting the founders (and VCs).
Successful founders will happily tell everyone and their dog how being a founder was so much work, how they didn't go on holiday for a few years, how they worked long hours, etc. And mostly why they deserve to be rich now while none of their employees is. None of them will talk about how being one of the first employees was also so much work, usually with a pretty bad salary and order of magnitudes fewer options than the founder.
I always wonder how the founders can genuinely believe that they are actually worth thousands of me. I am pretty damn sure that with a thousand me, we produce more than the founders alone.
I don't think that anything in the law says that if your title is "CEO", then you can fire cofounders. I'm guessing it depends on the contract the cofounders sign in the beginning.
> often with the board on their side
I have seen the CTO convince the board to fire his cofounder who was more the CEO? Well I don't know if the titles were written in the contracts, they changed over the years. But the guy who got his cofounder fired went from calling himself CTO to calling himself co-CEO to getting his "buddy" fired.
Engineers generally never acknowledge the value of knowing _what_ to build, only whether something is built.
As an engineer, I don't pretend to know or understand what the market wants or what people are willing to pay for. That's a problem I leave to business/product-oriented people. In exchange, they leave the building to me.
Nobody knows what to build, that's why VCs give money to many startups, almost all of them bankrupting.
The sole value of the founders is to be able to convince VCs for as long as they can. VCs generally have no clue about the technology, so it's about getting good at selling bullshit. Granted, I am not great at selling bullshit, so it doesn't make me a great founder.
Now if we get back to knowing what to build, if you give me a thousand me, we can try a whole bunch of different ideas hoping that one works. This is what VCs do, and it works for them even though they have no clue either.
No, a founder is never worth thousands of employees, period.
And I'd like to note the asymmetry here: I am arguing that I am not thousands of times less valuable than them. I am not remotely saying that I am better.
I kind of enjoy working with partners, especially when everyone "knows their lanes" and agreements are properly defined. It just tends to blow up at some point it seems like... :)
The main goal is to keep a pulse on finances.
In any case, "start my own" is still on my todo, it's just... not that easy to pull of :))
You're a startup when you're testing a new business model. If you realise that it works, then you're a business.