While I thought this was a pretty good read, I didn't really feel like it answered the question in the title: "was it worth it"?
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.
I work with him at this company. We are still going, just don’t have much of a public facing side, because most of the sales are direct b2b. We’re working on showcasing more of what we do, but it hasn’t been our top priority.
Thanks very much for the correction. FWIW, the reason for my apparently faulty assumption is that when searching for your company online, the top result is the Crunchbase entry, https://www.crunchbase.com/organization/helios-companies, and it shows web (www.helioscompanies.com) and LinkedIn links that are both defunct.
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!
I know it's weird, I'm a long time software guy myself, and would be surprised too if I didn't see this for myself. The thing about us is that our customers are banks. New banks are joining because they already know about us from the other banks. Our founders do the literal legwork of flying places and talking to people, establishing direct relationships, and talking on the phone. This is actually one of our strengths, we are not primarily a tech shop trying to sell tech to banks, but rather our founders are former bankers themselves who are trying to help solve their problems first, and sell tech as a side effect of that.
Speaking as former CTO of a bank, the procurement team and risk team still typically attempt to validate online presence and run some kind of risk score SaaS on you, lack of presence is a minus and conversations ensue. When I brought in firms like yours it took extra energy to advocate for if they didn't tick these nominal boxes. Clipping every little bit of hair is an ROI based decision, where leaving hair on it can help filter for banks that are "easier to work with" when you are still subscale, fewer resources than prospects. Put another way, being turned down during early stage can be good ROI.
Thanks very much, this is really helpful. I do honestly think this would be a great blog post! So many of us (like I just did) approach these problems from a "tech first" approach, and that's often not the right strategy, depending on the domain.
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'm not affiliated with this company, but I personally believe that not having a website (or any public presence) is the future of our industry. The issue is that any information you put out there can now be used by AI to emulate you. This can be used by competitors to quickly reach feature parity with your product, it can be used by bad actors like scammers, and just generally is harmful to you.
I know it sounds silly but not having a website is probably the future of the web.
Wow that is a wild take. I would not trust a business without a website, I did a quick poll of friends in tech and they all felt similar for b2b and consumer.
From 2024. Sorry, should have added that to the title when I submitted it.
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
> 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...
You know the best selling pop psychology self help book The Subtle Art Of Not Giving A Fuck might actually be a good business book for people who haven't internalised that you have to say no to most things in order to be able to emphatically say yes to the actually important things.
Even having worked on many such projects, it can be hard to tell if it was the correct choice. In any case, it came at great expense to the other projects we could have improved
> When I was younger I thought QA was the thing from the good “old days” that should be replaced with the automated tests suit. After accidentally hiring one great QA engineer I quickly changed my mind. Today I would say it’s one of the most important departments on my list. The amount of my time saved by QA team is insane.
If the author is reading - can you elaborate on this?
Not the author, but I'm a VP of Eng, and one of my sub-orgs is QA. Here's my take...
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.
I'm curious about the simple, lightweight change management process listed in the article. Anyone have any tips on doing this well? I kind of hate the part of having to convince everyone of something "obviously better" :)
- 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.
We are still going, but it's a bumpy road. One of main products got delayed by partnering financial institution, which sent us into money crunch mode.
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.
I don't look at this like that, not any more at least.
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?
All sorts of questions - "What's the best way to do X?", "How would it impact security?", "Why we need this?", "What happens if this fails?", "Remind me how this works?", "Am I thinking in the right direction?"
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)... :)
One could do worse than asking for major decisions to come with a (ultralight, readme like) platform/product enhancement proposal (PEP).
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.
Generally speaking if you are capable of leading a startup as a CTO, you should just found your own, with the legal CEO designation, so that you can control what happens to the equity. CTOs in general are very naive about how all of this works once PMF/traction is hit, and how little power they have over the platform they built
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.
100% agree. I'm a CTO for a vertical SaaS, working with a first-time founder with deep domain expertise. He came in with a thesis as to why our target customer was still using Excel, even though it was completely unsuited to their needs. Almost everything he thought at the beginning has been borne out, and there's no way I would have figured out this market on my own. There's also no way he would have built a usable product without someone like me - his original plan was bloated and we narrowed it to the core where we have very specific value.
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.
> 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.
I have hardly come across aspiring-CEOs who do not have much ego and listen to other founders, let alone founders or serial-founders. After some founder dating last year, I am a bit jaded, though.
Also speaking from similiar experience, ^^^ this is the best combo. Where both parties have a certain degree of humility and self-awareness and understand how their skills, personalities, and personal circumstances (ability to travel, life stage, etc.) compliment one another.
Right, sure, there is an initial pain of building domain knowledge. But that one year of knowledge building, distribution, early customers, then dominates who has control over the cap table for a decade. Why not just do this work yourself? Its some weird myth that someone capable of being a technical leader cannot also flesh out the distribution
Especially with the existence of AI, it really makes no sense and is some weird hierarchical system built by business people
> Its some weird myth that someone capable of being a technical leader cannot also flesh out the distribution
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.
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
You don't need a non-technical cofounder, but you do need a founder willing and capable of handling non-technical things.
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.
>at this point it is a borderline scam to work for a CEO that isnt significantly better/bringing in capital
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.
>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.
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.
> 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.
That same thing happens with accountants and lawyers. I’ve dealt with terrible of both that were just good enough to not get disbarred or lose their license.
> I’ve dealt with terrible of both that were just good enough to not get disbarred or lose their license.
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.
Maybe AI has changed things, but I think it takes more than one year to gain sufficient domain expertise.
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.
You're trying to have a serious discussion with someone convinced he can build deep domain knowledge in eg banks and their needs, how to sell to them, plus the associated network, in a year while also writing code. Oh, and just assumes "early customers", ie you're also going to learn how to sell. Because how hard can it be :rolleyes:
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
Why can't everything you just described be done by someone who doesn't have the CEO legal title? The CTO can be the CEO in title, but fulfill the duties of both, with consultation from the "CEO" (pick whatever title you want). Basically inverting the non-technical-founder / CTO relationship, in favor of the technical founder who needs non-technical expertise and guidance, but still wants to maintain overall control of the business.
There are a lot of defunct startups in my city that were started by engineers and CTOs. Some of them had good ideas and a few even had great execution of the product.
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.
IMHO it doesn't matter whether you are CEO, CTO, CFO, C-whatever-you-feel-like-O, as long as you are a founder.
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.
Maybe, but there are levels to the game. The CEO has legal rights to fire cofounders, often with the board on their side. Early stage this doesnt get exercised often. But when the CTO has ten million of equity to vest over two more years, questions get asked behind closed doors about whether they are worth that amount. Thats when the "professional CTO" is brought in. Its extremely common, and letting him vest that amount is coming out of the pocket of the CEO and the investors
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.
> I am pretty damn sure that with a thousand me, we produce more than the founders alone
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.
> Engineers generally never acknowledge the value of knowing _what_ to build, only whether something is built.
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.
This may be your option for maximum control and leverage, but do remember that your day to day will be different, especially as the company grows. As someone who enjoys technical/product work and doesn't particularly enjoy fundraising, sales, or marketing, being the CEO is actually quite a trade-off for my personal fulfillment.
Sure, but you should just be aware that "wanting to do engineering" probably is stopping you from financial freedom/a more interesting life. Just be aware of the tradeoff
> aware that "wanting to do engineering" probably is stopping you from financial freedom/a more interesting life.
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.
I find this a cynical and possibly incorrect take. I'll admit, if your goal is to become a billionaire and command vast sums of cash from your many vacation homes I'd agree with you, but financial freedom and an interesting life is absolutely within reach without having to take a career path that doesn't bring you fulfillment. Those CTOs that get pushed out once the company reaches their series C almost certainly achieve financial freedom.
> some typical b2b saas that makes 500k-5M in ARR.
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.
There is a non tangible level of status that comes with being CEO of a profitable startup. People dont know but it helps in both dating life and social situations. After the startup, employers consider the CEO the guy that was responsible for the success. Its a huge deal, most people have no clue how the whole thing works
> There is a non tangible level of status that comes with being CEO of a profitable startup.
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.
$500K ARR often sounds more impressive than it is. How much of that is profit? Probably not much. Every SaaS startup I've worked for was bleeding money on cloud costs and employees.
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.
> 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.
Being the CTO at a company with a handful of people (where everyone likley has a C-title) doesn't absolve you from the responsibility of those tasks though. You really don't get to focus on "only" CTO roles until the company is much, much larger.
I'm not sure if it's a cynical view. Isn't it what business guys do in most people's minds? To bring together investment, marketing and product because they don't just magically blend.
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.)
Alot of CEOs dont start out thinking this way, but it definitely occurs to them as they run the business that its the case. Once the platform is built with sticky customers, the CTO is replaceable with a generic high performing engineering manager. Not always, but for run of the mill b2b saas, they are
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 :))
I really think society has built some weird narrative that if you did a technical undergrad, you arent fit to run a small startup. Ycombinator busts this myth constantly, and actually prefer technical founders.
Cynical view is that technical founders who don’t know who business work are easier to manipulate into bad decisions for their business, as long as VC makes money.
I think it’s more of a realism vs optimism take - deeply technical people focus on what can go wrong, because they know better. Which is a good thing for a technical person - the best CTOs are great because they prevent implosions, not because they’re naive and optimistic
It’s not a “narrative” - technical-minded people tend to be more realistic/pessimistic, which has severe implications on company growth.
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).
I believe it depends on the industry your business is in. In many businesses, technology is only a small component, and other factors such as connections, sales, and marketing can be more important than the technology itself.
A business is a startup when its goal is to raise investment with the understanding that it will use all the money towards rapid, aggressive growth, and then raise the next, much bigger round of investment, or get acquired, or go bust.
What's the current term then for a newly founded business that is pursuing some other strategy? For instance, bootstrapping to organic growth, or self-funding toward a long-term profitable "lifestyle" business?
I like to say a startup is a business where growth is far and away the primary goal and it becomes a regular business as that shifts toward revenue or stability or specialization. I don't think it HAS to be VC but a big chunk of VC cash is a great way to bet everything on growth so it might be the defacto definition anyway and I'm splitting hairs.
My definition is that a startup hasn't found its product-market fit yet. As soon as you are profitable, you're a business, whether or not you take investments to grow faster.
You're a startup when you're testing a new business model. If you realise that it works, then you're a business.
While I thought this was a pretty good read, I didn't really feel like it answered the question in the title: "was it worth it"?
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.
I work with him at this company. We are still going, just don’t have much of a public facing side, because most of the sales are direct b2b. We’re working on showcasing more of what we do, but it hasn’t been our top priority.
Thanks very much for the correction. FWIW, the reason for my apparently faulty assumption is that when searching for your company online, the top result is the Crunchbase entry, https://www.crunchbase.com/organization/helios-companies, and it shows web (www.helioscompanies.com) and LinkedIn links that are both defunct.
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!
I know it's weird, I'm a long time software guy myself, and would be surprised too if I didn't see this for myself. The thing about us is that our customers are banks. New banks are joining because they already know about us from the other banks. Our founders do the literal legwork of flying places and talking to people, establishing direct relationships, and talking on the phone. This is actually one of our strengths, we are not primarily a tech shop trying to sell tech to banks, but rather our founders are former bankers themselves who are trying to help solve their problems first, and sell tech as a side effect of that.
Speaking as former CTO of a bank, the procurement team and risk team still typically attempt to validate online presence and run some kind of risk score SaaS on you, lack of presence is a minus and conversations ensue. When I brought in firms like yours it took extra energy to advocate for if they didn't tick these nominal boxes. Clipping every little bit of hair is an ROI based decision, where leaving hair on it can help filter for banks that are "easier to work with" when you are still subscale, fewer resources than prospects. Put another way, being turned down during early stage can be good ROI.
Thanks very much, this is really helpful. I do honestly think this would be a great blog post! So many of us (like I just did) approach these problems from a "tech first" approach, and that's often not the right strategy, depending on the domain.
"Having a website" is such a double-edged sword.
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'm not affiliated with this company, but I personally believe that not having a website (or any public presence) is the future of our industry. The issue is that any information you put out there can now be used by AI to emulate you. This can be used by competitors to quickly reach feature parity with your product, it can be used by bad actors like scammers, and just generally is harmful to you.
I know it sounds silly but not having a website is probably the future of the web.
Wow that is a wild take. I would not trust a business without a website, I did a quick poll of friends in tech and they all felt similar for b2b and consumer.
...and your CEO took down his LinkedIn page? Hmmm....
It's not down, but it's under an abbreviated name (I had the same question until I found it).
From 2024. Sorry, should have added that to the title when I submitted it.
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
> 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...
You know the best selling pop psychology self help book The Subtle Art Of Not Giving A Fuck might actually be a good business book for people who haven't internalised that you have to say no to most things in order to be able to emphatically say yes to the actually important things.
Even having worked on many such projects, it can be hard to tell if it was the correct choice. In any case, it came at great expense to the other projects we could have improved
That's fair. Depends on the CEO, PMF, and the bank account size.
Sales driven growth is great until it isn't.
> When I was younger I thought QA was the thing from the good “old days” that should be replaced with the automated tests suit. After accidentally hiring one great QA engineer I quickly changed my mind. Today I would say it’s one of the most important departments on my list. The amount of my time saved by QA team is insane.
If the author is reading - can you elaborate on this?
Not the author, but I'm a VP of Eng, and one of my sub-orgs is QA. Here's my take...
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.
Pretty much what cialowicz said.
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.
I'm curious about the simple, lightweight change management process listed in the article. Anyone have any tips on doing this well? I kind of hate the part of having to convince everyone of something "obviously better" :)
It pretty much boils down to:
- 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.
I wonder what happened with this current company, helioscompanies.com ? Did it go under and is that why he's looking for a new role?
We are still going, but it's a bumpy road. One of main products got delayed by partnering financial institution, which sent us into money crunch mode.
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.
So how much money for 5 years of effort?
I don't look at this like that, not any more at least.
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?
* How much stress? * How many hours?
I respect the honesty that went into that writing.
The author states that a CTO should ask questions rather then give orders. What kind of questions?
All sorts of questions - "What's the best way to do X?", "How would it impact security?", "Why we need this?", "What happens if this fails?", "Remind me how this works?", "Am I thinking in the right direction?"
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)... :)
Thanks!
One could do worse than asking for major decisions to come with a (ultralight, readme like) platform/product enhancement proposal (PEP).
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.
https://ruggedsoftware.org
Generally speaking if you are capable of leading a startup as a CTO, you should just found your own, with the legal CEO designation, so that you can control what happens to the equity. CTOs in general are very naive about how all of this works once PMF/traction is hit, and how little power they have over the platform they built
Disagree.
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)
100% agree. I'm a CTO for a vertical SaaS, working with a first-time founder with deep domain expertise. He came in with a thesis as to why our target customer was still using Excel, even though it was completely unsuited to their needs. Almost everything he thought at the beginning has been borne out, and there's no way I would have figured out this market on my own. There's also no way he would have built a usable product without someone like me - his original plan was bloated and we narrowed it to the core where we have very specific value.
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.
> 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.
I have hardly come across aspiring-CEOs who do not have much ego and listen to other founders, let alone founders or serial-founders. After some founder dating last year, I am a bit jaded, though.
yup
Also speaking from similiar experience, ^^^ this is the best combo. Where both parties have a certain degree of humility and self-awareness and understand how their skills, personalities, and personal circumstances (ability to travel, life stage, etc.) compliment one another.
Right, sure, there is an initial pain of building domain knowledge. But that one year of knowledge building, distribution, early customers, then dominates who has control over the cap table for a decade. Why not just do this work yourself? Its some weird myth that someone capable of being a technical leader cannot also flesh out the distribution
Especially with the existence of AI, it really makes no sense and is some weird hierarchical system built by business people
> Its some weird myth that someone capable of being a technical leader cannot also flesh out the distribution
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.
> This idea often gets repeated here but it’s based on ZIRP from 2010s ...
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
ycombinator, the best very early stage investors of all time hold this opinion:
"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
You don't need a non-technical cofounder, but you do need a founder willing and capable of handling non-technical things.
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.
>at this point it is a borderline scam to work for a CEO that isnt significantly better/bringing in capital
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.
If you find mentors, or just pay people 200 an hour to meet once a week, a lot could be learned. I agree the gap is large, but it can be overcome
What’s YC’s track record in the new LLMs-can-code era?
Or are we talking about Dropbox and Airbnb?
most of the recent series A ai companies are YC companies, they are absolutely crushing it
What are their names?
Jared has an (unfinished?) degree in CS and Econ so that’s a bit rich for him to say. Why’d he bother with Econ if it’s so UsELeSs?
>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.
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.
> 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.
That same thing happens with accountants and lawyers. I’ve dealt with terrible of both that were just good enough to not get disbarred or lose their license.
I don’t think you have a salient point here.
> I’ve dealt with terrible of both that were just good enough to not get disbarred or lose their license.
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.
Maybe AI has changed things, but I think it takes more than one year to gain sufficient domain expertise.
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
You're trying to have a serious discussion with someone convinced he can build deep domain knowledge in eg banks and their needs, how to sell to them, plus the associated network, in a year while also writing code. Oh, and just assumes "early customers", ie you're also going to learn how to sell. Because how hard can it be :rolleyes:
> But that one year of knowledge building, distribution, early customers, then dominates who has control over the cap table for a decade.
Can you recommend any resources for learning how to do this work yourself?
I'd recommend:
- 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
One shortcut would be to:
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 best combination is a technical CEO founder with deep domain expertise. Confirms what you say about the dev tools space exception.
Of which LLMs are effectively a dev tool that happens to also be a tool for every other industry vertical in the world economy.
Why can't everything you just described be done by someone who doesn't have the CEO legal title? The CTO can be the CEO in title, but fulfill the duties of both, with consultation from the "CEO" (pick whatever title you want). Basically inverting the non-technical-founder / CTO relationship, in favor of the technical founder who needs non-technical expertise and guidance, but still wants to maintain overall control of the business.
Just remember that every startup is not a SaaS business...
[dead]
There are a lot of defunct startups in my city that were started by engineers and CTOs. Some of them had good ideas and a few even had great execution of the product.
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.
> They all failed at sales, scaling, retention, and generally running the business.
This also applies to most non-technical, “business folks”-led businesses as well.
IMHO it doesn't matter whether you are CEO, CTO, CFO, C-whatever-you-feel-like-O, as long as you are a founder.
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.
Maybe, but there are levels to the game. The CEO has legal rights to fire cofounders, often with the board on their side. Early stage this doesnt get exercised often. But when the CTO has ten million of equity to vest over two more years, questions get asked behind closed doors about whether they are worth that amount. Thats when the "professional CTO" is brought in. Its extremely common, and letting him vest that amount is coming out of the pocket of the CEO and the investors
> The CEO has legal rights
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.
> I am pretty damn sure that with a thousand me, we produce more than the founders alone
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.
> Engineers generally never acknowledge the value of knowing _what_ to build, only whether something is built.
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.
This may be your option for maximum control and leverage, but do remember that your day to day will be different, especially as the company grows. As someone who enjoys technical/product work and doesn't particularly enjoy fundraising, sales, or marketing, being the CEO is actually quite a trade-off for my personal fulfillment.
Sure, but you should just be aware that "wanting to do engineering" probably is stopping you from financial freedom/a more interesting life. Just be aware of the tradeoff
> aware that "wanting to do engineering" probably is stopping you from financial freedom/a more interesting life.
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.
I find this a cynical and possibly incorrect take. I'll admit, if your goal is to become a billionaire and command vast sums of cash from your many vacation homes I'd agree with you, but financial freedom and an interesting life is absolutely within reach without having to take a career path that doesn't bring you fulfillment. Those CTOs that get pushed out once the company reaches their series C almost certainly achieve financial freedom.
I'm not really talking about unicorns, I am talking about some typical b2b saas that makes 500k-5M in ARR.
> some typical b2b saas that makes 500k-5M in ARR.
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.
There is a non tangible level of status that comes with being CEO of a profitable startup. People dont know but it helps in both dating life and social situations. After the startup, employers consider the CEO the guy that was responsible for the success. Its a huge deal, most people have no clue how the whole thing works
> There is a non tangible level of status that comes with being CEO of a profitable startup.
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.
$500K ARR often sounds more impressive than it is. How much of that is profit? Probably not much. Every SaaS startup I've worked for was bleeding money on cloud costs and employees.
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.
> 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.
Being the CTO at a company with a handful of people (where everyone likley has a C-title) doesn't absolve you from the responsibility of those tasks though. You really don't get to focus on "only" CTO roles until the company is much, much larger.
One perhaps (cynical) view is that CEOs with business background are basically just arbitraging between investors and product teams.
I'm not sure if it's a cynical view. Isn't it what business guys do in most people's minds? To bring together investment, marketing and product because they don't just magically blend.
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.)
Alot of CEOs dont start out thinking this way, but it definitely occurs to them as they run the business that its the case. Once the platform is built with sticky customers, the CTO is replaceable with a generic high performing engineering manager. Not always, but for run of the mill b2b saas, they are
CTOs just arbitrate between dev teams and product teams.
CPAs just arbitrage between cash flows and legal requirements.
Nah, CTO is usually deep in the code base, hiring, firing, coding, pulling long hours to ship features, etc
In the same way that engineers are just arbitraging between the company and the computers, I suppose.
Every job sounds much easier from the outside.
Yeah. Everyone’s just arbitraging. Not sure why the problem is
Yes! That’s exactly what we’re doing. It’s not as easy as it sounds.
Definitely hard emotionally if the ceo job entails a lot of “managing up”
author of the post:
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 :))
This is of the classical genre of HN cynicism framed as advice that if you were to follow you're pretty much guaranteed to never go anywhere in life.
nah I have been in the venture scene in nyc for a while, have seen the same song and dance play out over and over
Completely different skillsets. Lots of deeply technical startup CEOs kill their startups by not acknowledging that.
I really think society has built some weird narrative that if you did a technical undergrad, you arent fit to run a small startup. Ycombinator busts this myth constantly, and actually prefer technical founders.
Cynical view is that technical founders who don’t know who business work are easier to manipulate into bad decisions for their business, as long as VC makes money.
I think it’s more of a realism vs optimism take - deeply technical people focus on what can go wrong, because they know better. Which is a good thing for a technical person - the best CTOs are great because they prevent implosions, not because they’re naive and optimistic
It’s not a “narrative” - technical-minded people tend to be more realistic/pessimistic, which has severe implications on company growth.
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).
I believe it depends on the industry your business is in. In many businesses, technology is only a small component, and other factors such as connections, sales, and marketing can be more important than the technology itself.
I would take a market-domain expert as CEO over a CTO any day of the week. Unless of course your product is to sell to other software providers.
[dead]
I was happily surprised to see the role and importance of QA being acknowledged.
where does the startup end and the small business begin?
A business is a startup when its goal is to raise investment with the understanding that it will use all the money towards rapid, aggressive growth, and then raise the next, much bigger round of investment, or get acquired, or go bust.
What's the current term then for a newly founded business that is pursuing some other strategy? For instance, bootstrapping to organic growth, or self-funding toward a long-term profitable "lifestyle" business?
A "new business" or a "small enterprise"
Solid definition. Being on the VC treadmill, and all of the “vibes” that come with that, is really what it boils down to.
I like to say a startup is a business where growth is far and away the primary goal and it becomes a regular business as that shifts toward revenue or stability or specialization. I don't think it HAS to be VC but a big chunk of VC cash is a great way to bet everything on growth so it might be the defacto definition anyway and I'm splitting hairs.
By your definition OpenAI and Databricks are startups.
My definition is that a startup hasn't found its product-market fit yet. As soon as you are profitable, you're a business, whether or not you take investments to grow faster.
You're a startup when you're testing a new business model. If you realise that it works, then you're a business.
Seeking or taking funding is my personal rule-of-thumb.
Good read, thank you. It feels nice to read something that was fully written by an actual human being.
My pleasure.