A Startup Journey: I’m Going Solo

Photo by Devin Justesen on Unsplash

Last time, we had just experienced a deep realization that may have shocked you to the very core of your being:

Wait, It Sounds Like You‘re A Solo Founder???

Yes, it does. And I am.

And I have been since 2016.

While I was ready to start a company, many of my potential co-founders were not.

I’m more than a few years beyond undergrad dorm room days, as are most of my friends. So, many of these potential co-founders had family obligations, or visa concerns, or an upcoming promotion at a great company, or too much financial leverage to forgo a steady salary for any extended time, and so on.

Founding a company from scratch just wasn’t the right next step for them at their life stages, regardless of how talented they were. So, while discussions were always fun, these discussions turned out to be an extended exercise in kicking the can down the road.

But that’s often the way that things work out.

In fairness, I have had several co-founding opportunities that I did not take advantage of, because I wasn’t ready to do so, for my own reasons.

And, realistically, if someone isn’t ready, then including them in the team adds risk to an already risky proposition. Some friends seemed ready, until they talked seriously with their spouses, who put them in check. And while I’m pretty good at team building, I’m not the guy who’s going to push that line — I’d rather keep the friends.

Moreover, I don’t want to end up being the one doing all of the work.

I’m happy to do my share of the work, but I’ve had way too many experiences over the years where I did much more work than others who overpromised and underdelivered, did a lot of work and got exactly zero credit, and picked up someone else’s slack for extended periods of time. It’s not smart to set yourself up for these situations, especially when the ball’s in your court.

But, Wait, Everyone Knows That It Just Won’t Work

I know what you’re thinking. I can hear your thoughts bubbling gently to the surface, like those pretty little bubbles in an expensive glass of champagne.

I know the Silicon Valley party line — “solo founders never work. No one has ever succeeded as a solo founder, because it just doesn’t work. The ideal founding team is very obviously 2.432 founders, all of whom met as roommates at Stanford, co-developed a military-grade AI/AR-enabled squirrel with natural language capabilities in their spare time, while quadruple majoring in CS, Math, Physics, and EE, with double special honors and a minor in comparative literature, in three years, and became soulmates through a Vulcan mind meld performed in CS 242MM: Mind Melding For Fun And Profit. All of the successful teams started this way. Everything else is broken and ipso facto won’t work, because it can’t. Ever.”

Oh yeah, that and “MBAs are evil, and they can’t start companies.” Or maybe it’s that they can’t start companies, because they’re evil? I’m not quite sure on that one… Well, anyway, strike two for me.

And people also insinuate, with an air of enlightenment tainted by condescension, that these statements were made by experts, so we don’t have to worry our own little heads about them, because the experts already did all of that, and experts are never wrong, because they’re experts, so they must have used their expertise to prove everything mathematically and incontrovertibly. OK, yeah, right…

Well, Maybe

Personally, I’m a data guy, and I’ve been that way for a long time. Maybe you’re interested in considering some of the data, too.

So, we have to ask ourselves some of the questions that we raised in the first post in this series.

And as we do, we’ll realize that the samples that form the basis for many of these sorts of statements are biased in several ways.

For example, if a data set is the result of a selection process, then the selectors’ biases can creep into this already non-IID data.

So, conclusions that are drawn by any consumers of this data, including the media who may attempt to digest it for mass consumption, need to be cognizant of the selection process.

Furthermore, when assessing probabilities, conditioning matters.

Ideally (but maybe impossibly), these conclusions should sound something more like “the probability of <a successful event of some sort> in the next <whatever> years for a <some number>-founder team, given and controlling for the conditions under which these teams were selected, the idiosyncratic characteristics of the team members, and the verticals that they address, at this moment in time, <blah, blah, blah>, is <whatever it is>, with <some massive error bars>.” Which is rather hard to do and would certainly require very careful study and analysis, as with most questions in the social sciences.

But maybe one ignores ceteris paribus and asserts that all of the teams had equal footing. But all is not equal in startups, or in life.

And if people believe that solo founders are less likely to succeed and espouse that belief fervently, then what’s the inherent risk? The risk is an outcome that has long been known in education, among other fields.

For example, how can one be confident that he or she mitigated his or her own subconscious biases when interacting with or advising solo founders?

What unstated judgments leaked out of their facial expressions and word choices?

Maybe none, but maybe some… And maybe little Billy and Sarah will never grow up to reach their full potential, even though they could have done so much more.

Anyway, my point is to raise the possibility that there are direct and indirect biases in much of the data that support these assertions that should be more deeply considered.

So, like much of the biased news, opinions, and other stuff flooding my Facebook feed in recent times, I take these as directionally-useful anecdotes worth considering, but not as scripture or immutable laws of the universe.

A Quick Note To Solo Founders And Potentially-Solo Founders

Of course, a great co-founder or two is ideal. Don’t read the prior discourse as saying that you should go it alone.

I’m simply saying that it’s possible, as you’ll see in the data that I cite below, and that you should draw your own conclusions and make your own decisions after doing so.

But a sub-optimal co-founder can derail your company. Search the web for examples, and think twice before compromising.

Furthermore, I’ve spoken to investors at top-tier firms who claim to be fine with solo founders, obviously depending on many factors. So, ignore the hype if you are committed and ready, and be so good that they can’t ignore you. Make them work to reject you, if they do.

But, you really have to have a thick skin to go solo, even beyond joining a startup as a member of the co-founding team or early team.

As a solo founder, I’ve been told many things, like

  • “it’s just too hard for one person to start a company”
  • “solo-founder startups always fail”
  • “you did all of that yourself? that’s crazy. you should definitely outsource or at least get some interns, you know, if you can’t get a real co-founder”
  • “aren’t things so hard? I couldn’t imagine starting a company without a co-founder”
  • “you’re bootstrapping? you should raise money and get a co-founder”
  • “VCs only invest in multi-founder startups and never invest in solo-founder startups”
  • “if you don’t have a co-founder, then that must mean that you can’t convince someone else to join your company, so don’t make me the first sucker”
  • “Ben needs Jerry”

The last one is my favorite.

But I wonder — just how much bandwidth does Jerry really have for coddling Ben?

Maybe Ben’s neediness is the real problem.

Maybe Jerry just wants to push some dope code, yo, instead of all day “it’s going to be OK, Ben, just let it out…me and my shoulder are here for you. We can work on company stuff tomorrow or the next day… But for now, let’s get you a dry hanky and open another tub of ice cream. Who wants Chunky Monkey?”

But the bigger problem is that the language used in these statements often includes extremes, such as “never” and “always,” without clear proof. You might get a fervent stare, or a vague anecdote, but rarely any solid proof.

Some Data

And the even bigger problem is that directly contradictory findings are readily available to anyone with internet access or a nearby library, and a willingness to question their own assumptions and beliefs.

Let’s start with a resource that I mentioned in the first post in this series. For people who prefer a more balanced treatment of the solo founder question, Noam Wasserman wrote an excellent book, published in 2012, that I’d recommend to anyone considering starting a company — The Founder’s Dilemmas: Anticipating and Avoiding the Pitfalls That Can Sink a Startup. Chapter 3 is devoted to the solo founder dilemma. Draw your own conclusions, but that text does not really support the “you have to have a co-founder or else you can only fail” chants.

More recently, and well after I had decided to go solo, I found a very interesting article on TechCrunch from 2016, which considered data pulled from the Crunchbase API to further investigate this question. In this case, Haje Jan Kamps pulled data on the founding teams of 7,348 companies that had raised more than $10 million each.

His findings suggested that not only could solo founders be successful, but also that they could have great exits. Really great exits.

Of course, the conclusions are only as good as the data behind them, so it’s possible that some of these teams had founders who weren’t on Crunchbase.

But how likely is that? If I’m a founder of a company that raised more than $10 million and had an exit, then I’ll be on that company profile page, without question. I’m already on the Next Mountain Crunchbase company profile page, with no venture funding and no exit. It took maybe five minutes to set up the company page and add myself.

I guess that it’s also possible (but extremely unlikely) that most multi-founder teams just don’t use Crunchbase, even after raising $10 million. Uh huh.

But any way you slice it, Haje Jan Kamps’ study is very compelling.

Edit: 2019.03.05 — another interesting read that explores founding team structure is The Co-Founder Mythology by Mark Suster at Upfront Ventures; it’s from 2011, but it’s still very timely.

But You Just Said That You Didn’t Exit Yet, So That’s Solo Founder Failure, Right?

I know that someone, somewhere is going to point out that I already mentioned that Next Mountain has yet to attain unicorn status. Maybe it never will, I admit that.

However, that does not mean that adding a founder would instantly insure success, or that lack of a co-founder is the cause of the company’s failure. There’s that whole correlation/causation thing.

And finding a great co-founder is not trivial. I know what would be most helpful in a co-founder, because I am pretty honest with myself about where I do excel and where I don’t currently excel.

Plenty of multi-founder teams are far from unicorn status — either succeeding gradually, pivoting, figuring things out, kicking the can down the road, dying slowly, dying in free fall, walking while dead, or admitting death. Indeed, most startups fail, as a quick web search will easily show you.

And many companies have multiple pivots and take seven to nine years to exit. Or more.

Anyway, at under two years, it’s hard to judge, even if Next Mountain becomes a side project. And if Next Mountain does fail, that failure still doesn’t prove anything. It’s a single data point. It’s not a proof.

But Isn’t More Always Better?

As I mentioned above, I’m not saying that solo teams are better than finding a great co-founder or two (and very rarely more).

There are obvious and often-cited advantages to a multi-founder team:

  • more is (or might be) better—more hands are theoretically available for essentially the same total amount of work, to the extent that the work itself is easily broken up or parallelizable and to the extent that the team is skilled to do the work
  • complementary skills — well, unless everyone has the same background and fungible resources are less valuable than complementary resources (this also applies to heavily front-end or back-end teams)
  • support structure — so you may have a shoulder to cry on, if you’re into that sort of thing (it’s fine if you are, but I probably don’t want to start a company with you; see the Ben & Jerry discussion above), but in fairness, it can also be nice to have camaraderie
  • potentially more funding — VCs may feel more comfortable with the company’s scaling ability
  • potentially higher acquisition offers — acquirers may pay more to incentivize founders to sell, especially in an acqui-hiring situation, although the payout per capita may not be higher; that’s an interesting question that I don’t know the answer to
  • generally easier to sell as a good idea to friends and others — Ben has Jerry, so the company is more than one person, which must be good, right mom?

There are some potential downsides to a multi-founder team, if the caveat that you should find great co-founders isn’t heeded.

Let’s explore some of those, as words of warning and red flags. Think your investors don’t see these issues? Think again.

Jockeying, Complexity, And Inefficiencies

For maximum efficiency, multi-founder teams should clarify each person’s role without ambiguity. This is not to say that each person should only have one responsibility, but they should have a clearly-defined role — something that they’re in charge of and responsible for.

Nature favors more entropy rather than less, so managing team entropy through clear and sensible structure in a fast-moving company is important. I’ve seen a lot of proof of this concept, directly and indirectly. Managing code entropy is similarly important.

I’m sure that someone will comment that there are companies that have succeeded wildly while operating as a rumpus room, but that just seems like a recipe for disaster. And I haven’t ever knowingly witnessed an example of that sort of success, so I’ll believe it when I see it in reality.

And if the co-founders happen to over-index on the business side, or on the technology side, then they still have a lot of roles to fill.

The business side, including sales and marketing, isn’t trivial to learn in five minutes. Nor is the technology side, from design to architecture to scaling.

Can a cadre of MBAs co-opt some unwitting developer into taking an emaciated salary and a tiny slice of equity to build out the next Google or Microsoft from scratch? Will they resort to outsourcing? How hard could it be, right? Everybody’s doing it, so it must work flawlessly…

Just budget for “tweaks” (i.e. massive changes that you’d guess are trivial) to the product and little timeline “slips.” Oh, you mean you haven’t ever developed a product spec or a wireframe? Well, then you’re in for some fun!

Or can a dynamic developer duo figure out sales and marketing overnight? What is your brand? Before you answer that, can you define the term “brand?” (And you chose the correct company type, remembered to file your 83(b) election on time, and instituted vesting for everyone’s equity, right?)

It’s possible to magically get it right, and advisers can help, but in my experience, sales and marketing are tough to just “do.” Just like building a scalable and performant system is not easy, closing a major deal and driving market demand are not easy. Good customer service is not easy.

I know, I know, growth hacking will save you. Have you done any? And you can integrate a customer service bot. Sure.

Even getting a single paying customer that you don’t know, or even one that you do know, is not necessarily easily done. Try it if you don’t believe me.

Most things are tractable, but nothing is really trivial, and everything has an inherent cost, in a fast-moving company.

In an early-stage startup, people find themselves in a lot of roles. My current role is a combination of CEO, CTO, CFO, CDO, CSO, CMO, office manager, and janitor. Oh, yeah, and extreme action blogger.

Before that, as a member of a six-person team that scaled to around 120 people while I was there, my role included components of management, data science, analytical consulting, IT, engineering, QA, DBA, ops, procurement, barista-related services, light construction, interior design, and so on, at different times and at different stages of the company’s life.

Wearing multiple hats is a necessary component of startups — if you don’t have someone responsible for some particular role, or if the someone that you do have is already running at full-throttle, then you’ll find yourself doing it. Or, it won’t get done. If enough people won’t do things that aren’t in their job description, then the company can enter a death spiral.

As a further example, and because you, dear reader, may be tempted to consider it, I’ve never been convinced that more than one CEO is a good thing.

Where does the buck stop? What if they disagree? Who breaks the tie? Is it a massive consensus of everyone, and the CEOs simply function as poll takers?What if the CEOs have deep and irreconcilable conflicts? Can they make tough team decisions? What if one CEO needs to go, or be demoted? What if they are both the wrong choice to lead the company? How does the rest of the company feel about transitions and non-transitions? Is the right vesting structure in place? And so on.

And from an investor’s perspective, would you like to invest in a company that refuses to take a stance on a single CEO? Or might you lower the valuation just a little bit, if you even invest at all?

To get a flavor of these dilemmas and decisions, I’d recommend reading Ben Horowitz’s The Hard Thing About Hard Things. Opher Kahane, serial entrepreneur and CEO at Origami Logic, recommended it to me, and it’s full of great advice.

Early in a company’s life, if members of the team focus their time and energy on fighting low-payoff battles among themselves, jockeying for titles, and otherwise not moving forward as a unified whole, then they’re barreling down the path to losing.

That’s a crazy train that you don’t want to be on.

In addition to the CEO level, I’ve seen the infamous “two-in-a-box” management structure in too many companies, as they grow. As a report with several solid-, dashed-, and dotted-line reporting relationships, what do you do? Who do you listen to, when people disagree? And don’t tell me that managers never disagree.

The tech industry is famous for layoffs, and I saw firsthand some major downsizings, including a thousand-manager layoff. Many two-in-a-box relationships eventually find themselves in peril, and for good reasons.

Finally, as a candidate searching for jobs and contacted by recruiters, I’ve always looked into reporting structure complexity and ambiguity, especially for companies at Series B and below.

I recall one that was just past Series A with four or five levels of management between data science and CEO. Wow. That’s aggressive.

Hiring is a key consideration for startups, and you don’t want to scare or confuse candidates.

More Funding Isn’t Always Better

Paul Graham has discussed some of the risks of raising funds and then making questionable choices here and here, and in video form here.

Even though I don’t agree with all of his opinions and advice (for example, I’m not as negative on MBAs in startups, but maybe that’s because I have an MBA, so I know how it’s been useful to me), I am a big Paul Graham fan, and I recommend most all of his freely-available resources, including On Lisp.

As an aside, PG deserves a lot of credit for making so much information available to founders and demystifying much of the startup process. Furthermore, Sam Altman, Michael Seibel, Jessica Livingston, and many others at YC are doing a great job of supporting founders and building the ecosystem.

And I say this as someone who has received an official Y Combinator form rejection letter. In fairness, it’s a well-written form rejection letter.

It’s also not a regret that I have — never applying might have been a regret, and it’s worth applying to YC or another accelerator, because the application forces you to answer useful questions, regardless of the final outcome. And if you do join YC, then you’ll have some outstanding peers and advisers to learn from.

End of aside.

But back to the topic of this subsection, bootstrapping or taking a more reasonable funding round (not low, but reasonable) can

  • force financial discipline and creativity
  • lead to further funding in the future at reasonable terms, because you don’t have an inflated prior valuation that is unattractive to investors
  • lead to acquisition offers that leave you better off than if you had to overcome a big funding hurdle (guess who gets paid out first)

So, it’s worth considering the right amount of funding for your startup, and on what terms, not just a big number that seems impressive.


Over the past two years, I’ve built full systems, then pivoted. Several times.

You can argue about whether these pivots were the right decisions, but I value flexibility, and I learned something from each of them.

The company that I joined prior to this one also pivoted early on. Many companies do.

But when you take on a co-founder, or otherwise have employees dependent on you and your actions for their financial livelihood, you lose some flexibility. Maybe you gain some fire under your buttocks, but you lose some flexibility in pivoting. You give up some option value.

Flexibility is also the reason that I didn’t seek funding (other than in a failed attempt at joining YC, but I had applied for the acceleration, colleagues, and advice more than for the funding).

Frankly, I wanted the freedom to build things without answering the “are we there yet” question from friends, family, and investors. Of course, I may have been wrong, but I made that choice based on deep consideration.


Groupthink can rear its head in most any situation involving a team. Consider answering these questions:

  • “OK, everyone, what do you think about my new design for our financial CRM app and how it happens to feature my precious miniature chihuahua-terrier, Lucky Bones, but in emoji form? Don’t you just love how he smiles at you when you move your mouse over his nose? Smile again, Lucky Bones!”
  • “Sure, yeah, you know, I was going to write tests, but this is just a prototype, right? We need to get this thing out fast, or we’ll lose our early-mover advantage. And we’ll have plenty of time for testing later.”
  • “I was thinking that we can focus on security and scaling later, so what do you think about skipping that whole, complicated SSL thingy, and also just storing our customers’ passwords in plain text, at least until after the investor presentation?”
  • “We could really use some funds, so should we sell our customer email list to some advertisers? They seem pretty legit.”
  • “An outsourcing shop just reached out to me on Snapchat, and we’ve been meaning to get an Android app done, so should we just send them our codebase in a zip file and get a quote? They sent me a deck that I glanced at briefly, and I looked at their website for 12 seconds, so I think that we should do it. We could even really step on the gas and give them access to our codebase, as well as to our staging and production servers. Otherwise, I don’t know how we’ll get a mobile app out soon enough.”
  • “We really don’t have time for documentation, so can we just agree to go ahead and do that later? I mean, everyone knows that C++ is pretty much self-documenting anyways, and I write really clear code, if I do say so myself.”
  • “Can we take on my cousin’s roommate’s friend’s nephew as an unpaid intern with no official paperwork? He, or was it she? Maybe it was a niece. Anyway, they want to be a data scientist, and I bet they have some great ideas for our customers’ data. Can you believe it? They didn’t even ask for payment, they just wanted us to email them a zip file of the data!”

And so on.

Can you stand up to this silliness and say no?

Can you say no when Lucky Bones is smiling at you?

Really? Because this is just the tip of the iceberg.

Other considerations

We’ve only scratched the surface here, regarding founding a startup.

Teams need to resolve issues very frequently, and things move fast, so it’s important to set yourself up for success as well as you can.

I chose to found solo, because that was the best option at the time, and because I’d rather try it now than regret never trying it later.

And, I knew that I would learn a lot.

I also follow technological progress and believe in the possibilities that it brings, as we’ll discuss in the next major section.

Technology, Yo!

A big problem that I have with accepting the myth that solo founders never work is that it wantonly ignores the temporal aspect of technology — technological capabilities are constantly growing, so many of the beliefs that have spewed forth from a bygone era need to be reevaluated.

It’s as if some people either haven’t kept up with or have completely ignored the ongoing IaaS, PaaS, BaaS, and everything-else-as-a-service revolution, as well as many huge improvements on the software side.

While I plan to discuss several of these technologies through this series of blog posts, at both a high level and at a much more technical level, let’s explore some services and software that make it much easier to build a company than it was in rather recent years.

You can, of course, do it the hard way. And you may need to operate at Google scale. Eventually. But as a startup, you’d be surprised how far you can get using services. And doing so can make a lot of sense financially, at a time when you need to be very financially sensible.

For example, a couple of years ago, I met some non-technical entrepreneurs whose developer had spun up a very beefy five-node Cassandra cluster from scratch…to back a site that was getting around 100 visitors per month. That’s #overprovisioned, #overkill, and #overbudget.

You also have to decide how much time you want to spend scaling clusters, given that services can do that automatically for you (just set reasonable upper limits and thresholds, and set up monitoring, of course).

Overprovisioning computing resources is a great way to burn through all of your seed capital, but on the upside, maybe you can raise more capital afterwards, if that’s a metric of success for you.

And customers are unlikely to care that you spent 1,000 hours tweaking the server configs instead of just using some PaaS offering. When was the last time that you really, deeply cared about how some app on your phone was made or what database it used more than you just wanted it to work as advertised? (Not that you shouldn’t care, but you didn’t, did you?)

Also, software is constantly evolving, so that it’s much easier to write, test, and deploy. Operations is becoming much easier to handle as a solo developer or small team. At one point, I had nine autoscaling and easily deployable environments running on AWS, across staging and production environments. It’s definitely doable, and five are still running right now.

Let’s consider some recent hardware and software advances. This is a moving target, and these lists are incomplete and will grow and evolve, but they will get you started.

Base Infrastructure

Serverless Infrastructure

Managed, Scalable Database Services


  • Apple — many exciting new features, including AR and ML
  • Android — also, many exciting new features

Frankly, these lists keep growing impressively, and additional lists could be made, including scalable and fabulous services for APIs, IoT, AR/AI, ML, big data, computer vision, blockchain, and more.

The more that I use serverless computing, the more I like it. It’s fantastic how easily you can add services and capabilities to your platform with serverless. Or, you could go full serverless — it’s really impressive.

I should apologize for leaving out many exciting tech offerings and focusing on many of the technology vendors that I know and/or have used (keep up the great work, everyone!), but let’s move more to the software side.

Programming Languages And Frameworks

Wow, where to start on programming languages and web frameworks?

As you can see from the wiki links, this is too big a can of worms to open in an already large post (as is databases), but I’ll mention that JavaScript, Java, Scala, Kotlin, Python, Ruby, Go, and so many other great languages can be used to develop and scale apps, with or without a web framework.

Libraries And Tooling

This is another wow, where to start?

Cross-platform software has broken many traditional silos. Angular, React Native, NativeScript, Xamarin, PhoneGap/Cordova, and other technologies make mobile development and deployment much easier than it traditionally has been.

Moreover, libraries are getting so much better. I want to discuss some of these great libraries, but there are so many to discuss that I’ll need to push that to at least another post.

Educational Resources

I mentioned several educational resources in the first post in this series, and each technology often has amazing written, and in some cases video, documentation. Explore some of the resources above and see for yourself.

The Bottom Line

The bottom line is that if you’re ready for the journey, but you can’t find a credible co-founder, then consider going solo.

Success is never even remotely guaranteed in startups, but if you pay attention and think, then you’re sure to learn a lot.

And startups are pretty hard in general, so keep reading and learning every step of the way (as I’m finishing this article for you, dear reader, Medium just showed me this post, from 2014, and it’s well worth the read).


Let’s wrap it up here. We’ll continue the journey soon, so I’m going to hit publish.

Posts In This Series

I’ll update these links as I go. It’s not very DRY, but neither are my eyes as I write these posts (just kidding).


Connect with Jason on Medium, LinkedIn, Quora, AngelList, and Twitter.