40
27 Comments

🧐 Lessons from hiring and firing my co-founder

If I hadn't brought on a co-founder, we would have launched beta six months ago. Here's why I want(ed) a co-founder, what happened, and lessons learned.

This is a long one. TLDR; at the end.


Pre co-founder

I'd just user-tested a clickable prototype that I threw together in a few weeks using Webflow.

The demand was there, and the momentum was building. The next step was to build a functional product—auth, user dashboard, state management.

I'm a technical marketer, and I've been building websites for going on two decades, but I'd never built anything beyond very basic web apps.

I was sure I could figure it out, I just didn't know if it would take 3 months or 6 months to get there. In my mind, a more experienced dev partner would make this go faster and free me up to focus on other parts of the business.

🤝 The other reasons I want(ed) a co-founder

As I was wrapping up user testing, I got introduced to the MD of a Techstar's program focused on workforce development (our category).

He liked where things were going and encouraged me to apply with the caveat that I was unlikely to get in without a co-founder. This started coming up more and more, "To be successful, you need a co-founder."

The thing is, StepLadder isn't my first startup. Everything else I've done, I've done with co-founders. And having the right co-founder is way more fun than going it alone.

In the end, it came down to:

  1. Someone to make up for my technical gaps (30%)
  2. The desire for a partner (30%)
  3. Peer pressure (40%)

🔎 Finding a co-founder

I started having as many conversations as I could with my network. When my network was tapped out, I went digital. I posted on /r/cofounder, Slack groups, and sent InMail.

I lined up ~25 calls and spent the next few weeks in Zoom hell. I narrowed things down to three candidates, but there was one that checked more boxes than the rest.

  1. Low expenses and able to take risks
  2. Strong founder-problem fit
  3. Planned to relocate to Denver (where I'm at)
  4. Experience with the tech stack I started building with (NextJS, Firebase, GraphQL)

We talked for three more weeks, and then he flew here to hang out for the weekend. Unprompted, he also set up a repo and starting building a POC.

The whole process took about a month and a half—which was a month and a half I didn't spend building or talking to potential customers.

💵 Agreeing to milestones and equity

There weren't fireworks, but we got along OK (for strangers) and decided to move forward together.

I'd ported the front-end over from Webflow to NextJS, migrated the content to Contentful, and had a good base for him to build on.

We agreed on a product roadmap to launch the beta within two months. We also agreed that speed was our strategy, and we needed to build and ship quickly.

As co-founder and CTO, he would get 40% with standard terms (one-year cliff, four-year vest). He would also continue to hold down his day job until we hit ramen profitability or received funding.

😩 Failure to launch

We had set a beta launch date of October 30th. Given the front-end was already built, he was confident that this was a conservative timeline that we would have no problem meeting.

To make the launch date less arbitrary, I scheduled us to pitch at a local startup event two days before launch. Even with the pressure of the hard deadline, we ended up missing the date.

In response, we scheduled three working sessions per week and pushed the timeline back to November 30th, which then turned into December 30th, then January 30th, and then…

🧐 Where things went wrong

1. This was my co-founder's first startup and he underestimated the commitment. When we initially discussed how much time he could dedicate each week, he replied, "25 hours." My response, "That's unrealistic; how about 15?"

Even at 15 hours per week, he quickly started experiencing the challenge of coding all day at his day job and then finding the motivation to keep coding nights and weekends.

2. Early tech decisions and unwillingness to pivot ground us to a halt. The initial back-end tech stack decisions quickly led to things becoming overcomplicated and overbuilt.

Rather than pivot and simplify, he kept doubling down until it became an unmanageable mess. This was really where the train went off the tracks.

3. Too much trust too early; too little verification too late. Steve Jobs is often quoted as saying, "It makes no sense to hire smart people and then tell them what to do." That's how I operate. Usually, it serves me well.

However, our relationship was too new and there weren't enough guardrails from the beginning. I wanted my co-founder to own the tech stack and feel empowered to make decisions without me getting in the middle.

Unfortunately, I let things continue to slip for too long before digging into his code and verifying things for myself.

🤒 The beginning of the end

Our first hard conversation happened at the beginning of December—three months in. Up until then, we had course correction conversations but no come-to-Jesus talks.

We agreed that things weren't going as smoothly as they should and we needed to ship faster. So we re-affirmed our commitment to launching at the end of the month, a deadline that we again missed.

Finally, after hearing for two months that we were just a week away from implementing front-end features that relied on state management, I decided to dig into the code. It was a mess.

So, I spent a weekend refactoring our entire codebase and replacing Apollo with Redux. The result was a parity build with working state management.

☠️ The split

It was February, three months after we were supposed to launch beta—and with the previous repo, a launch date wasn't anywhere in sight.

We discussed the current state of the project and how it had become overcomplicated. I walked him through the new repo with working state management that I deployed on a different host (Vercel).

He looked at the new repo and agreed to wrap up the missing features in a week. When that day came, he hadn't made any progress.

The stress and pressure had caught up with him. He needed a break. We agreed to meet back up when he was ready.

A few weeks later, we met over beers, mutually agreed to separate, and parted on good terms.

🧩 The aftermath

Immediately after ending things, I felt like I got punched in the heart with a shot of adrenaline. I was now the only thing holding back the launch of our beta.

So I got to work, and for the first few weeks, I made quick work of the backlog.

I got things 95% of the way there and then ran into some bugs. In the frustration, I lost momentum. I was burnt out and decided to take a break of my own.

In that time, I had several networking calls—and received feedback like:

"StepLadder may be the coolest solution to this problem I've seen… if you can actually pull it off." and "As a hiring manager, I'm so excited for this."

Just like that, the spark was back.

🚀 The future

It's been seven months since I fully validated the demand for StepLadder and just over a month since my co-founder and I split.

This weekend, I'm wrapping up QA and getting things ready to launch on Monday.

I absolutely believe that you don't need a co-founder to be successful, but I still want to find the right partner in the future, even after this incredibly trying experience.

There are smaller projects—like Hired Hemp—that I fully intend to bootstrap solo. But this problem is too big to take on alone.

✍️ Lessons learned

Startups are hard, and finding a co-founder who is the right fit for your startup is even harder.

Between the search, the initial calls, the ongoing meetings, and the ramp-up period, and the split, I probably lost three months of productive time.

Had I kept my head down and not gotten distracted by the stigma of being a solo founder, I would have been able to launch our beta on my own back in October.

I still want a partner, but next time I'll take it slow and have a better process in place.

👉 My final thoughts (TLDR;):

Do it for the right reasons.
The fact that 40% of my decision was influenced by peer pressure likely clouded my judgment. Don't rush and don't bring on a co-founder just because solo founders are heavily stigmatized.

You can't force chemistry.
My co-founder and I got along but there wasn't an overwhelming sense of chemistry. To be fair, we're both introverts and I take a while to warm up to people. But when things didn't start to click after a few months, I should have taken it as a sign. To make it long-term, the chemistry needs to be there.

If you're even remotely technical, learn to code.
At my first startup, we built the servers our code ran on and used early MVC frameworks. Things are way easier now—more ways to learn, more communities to support you. It only took me a month to upskill my knowledge gaps enough to finish the development solo.

Take your time and figure out smaller things to build together first.
If I had a do-over, I would have started things off with a small feature or project. This would have been enough to understand working and communication styles better, how we approach challenges and what we could actually do together.

Give people a chance, but end things quickly if you know it's not going to work.
I was ready to part ways at least a month before we finally did. Calling it quits earlier would have been better for both of us.

Hire hackers and keep it simple.
Startup dev mentality is way different than enterprise dev mentality. Make sure that whoever you bring on has a hacker mentality and is comfortable moving fast. To move fast, keep things simple.

Even if you're not technical, trust your gut. If things seem more complicated than they need to be, they probably are. Hit pause, ask questions, and regroup if necessary.


There are two sides to every story. This one is mine. Thanks for reading! I hope someone can learn from this giant wall of text (or the TLDR;).

  1. 4

    Thank you for sharing these lessons you have learned.

    It's so interesting that when you said you felt peer pressure to find a co-founder was 40%. I think this is something that isn't talked about enough.

    1. 1

      Yea, and it was completely out of character for me. I've spent my whole life—particularly in the business world—not caving to peer pressure. But there's just so much stigma associated with solo founders.

      Over and over again, really smart and experienced people kept essentially saying, "Solo founder startups rarely work... If you don't have a co-founder nobody will take you seriously."

      The truth is, startups in general rarely work. If there's one thing I hope people learn from this story it's to trust your gut and don't bow to the pressure to bring on a co-founder just to bring on a co-founder.

      If you want a co-founder, take your time and only partner with someone if the chemistry is there and after you've had a chance to experience what the working relationship will be like.

  2. 3

    Awesome story!
    I've been telling people for a long time - it's rarely a good idea to look for a co-founder too early, pretty much for the reasons you've outlined above.
    Been there, done that, will never do it again!

  3. 3

    Great post, @rionmartin ! I really agree with you on every point. Especially on the "it's like dating" comment :) Peer pressure can be really harmful. My whole life I was listening to everybody, trying to learn maximum from their advice. My assumtion was "the more people you listen to, the more you will learn". I was wrong. Now I brutally filter all the incoming information. The peer pressure you're talking about also falls under this category. You shouldn't take and apply other people's advice until you're 100% sure about it.

    1. 2

      Thanks, @elnur! The strange thing is that I was the opposite. I spent most of my life going against the grain and rejecting peer pressure. I've never fit in or found my tribe. I've always been kind of an outsider and I embraced that.

      But in this case, solo founders are so aggressively disparaged that I finally caved. Again, I still want partners. However, the chemistry has to be there, the working styles have to be complimentary and peer pressure can't factor into the decision.

    1. 1

      There's that QA I mentioned :). Just fixed it.

  4. 2

    Just some rando on the internet, but I'll throw in 2 cents. If you had a working prototype in Webflow, you already had most of the front-end done at that point regardless of framework you settled on because it can be exported, componentized, and integrate any necessary state management. Maybe I'm misunderstanding, but it's sounds like you just needed a full stack that focused on API development for the CMS / data services and help wire it up to your front-end. Typically, on a bootstrap project, you make the code testable but you do unit testing and integration testing on the most critical paths because launching is more important than perfection...being practical. It's also a good idea to make up some flow charts of the logic because it is so damn easy to get lost in a class method and forget big picture without visualizations. Takes a few minutes and saves days of working on the wrong things.

    This story sounds like a cardinal sin of programming was committed: "Premature optimization is the root of all evil..." I would suggest asking related questions around this topic to differentiate between the mindsets you spoke of. That's exactly why I don't want to set foot in an enterprise setting. I'll freelance or work with start-ups and small companies: people that think bottom-line, practical first - optimize later, efficient, automation, high-impact, etc. That comes from being forged and battle tested in quite literally battle but also multiple business environments.

    I've made bad calls or misplaced trust in people as well. Can happen to anyone and even the most diligent because people can change. One such person cost me a lot. However, I've gained a lot of emotional intelligence from those experiences. I think you have the right attitude about checks and balances and nipping things at the bud because of the dynamic that people can change over time, and I get the sense that you don't mean to erase them over a small slight but rather take mutually-beneficial corrective action before it gets out of hand.

    1. 1

      The cardinal sin was definitely committed. And the biggest challenge with committing it in a startup is that things should be quickly iterated on. What happened is that I believed we were on the same page—speed is the strategy, things will change, the point is to ship, iterate, find what's working, and then refine—but once he started down the road of premature optimization and overcomplication, he just couldn't escape.

      In terms of what was needed. The CMS was fully wired up prior to him joining. It was more about state management, storing user data, configuring any cloud functions, and CI/CD. My role was front-end; his was back-end and devops. Everything was mapped out with flowcharts and supported with user stories.

      Bringing on a CTO to bridge my technical gaps was really only 30% of my decision. Equal to that was my desire to have an accountability partner, someone to be in the trenches with, and someone who could focus on dev so I could focus on marketing, user development, and biz dev. The rest was influenced by the stigma of being a solo founder.

      I knew I could figure out the dev side if I spent the time to do it, at the time, it just seemed to make more sense to have a more experienced partner take that over.

  5. 2

    This CTO/co-founder problem is an old one and I think most issues just come from this "peer pressure" thing. Most success stories of startups are describing a group of friends, but you can't find a friend by recruitment.

    The problem with the indiehacker-scene is that the stories of success are taken as a blueprint that has to be followed as is written.
    For example: Some one was successful selling an info product through a twitter audience? So, you'll need a twitter audience first no matter what.
    Or, another example: You don't feel confident with code - you'll need a CTO. Because all successful startups have a CTO.

    The point I actually want to make is that in a position as maker it is necessary to find solutions to problems. And, it is not necessarily always a good option to a follow path other people went.

    For example, myself. My skillset is basically a CTO-skillset. And, I'm building something at the moment. But - I don't try to get a CEO co-founder onboard first. Or a Chief Marketing Officer.

    Anyway, in my opinion the "I have to have a CTO before I start"-mindset is a barrier. There are actually other options available:

    • hire a dev as employee to build
    • go to one of these dev agencies (I saw here once an agency that cost $1.500 a week but they promised to deliver in 2 weeks)

    My final point is the necessary knowledge to have. When you are a maker/entrepreneur of a SaaS you have to understand how the product is build. That means, you have to understand infrastructure, backend, code deployment and how that works in general. Because that is where the business sits (infrastructure costs, speed of development). I mean if you are a CEO of a beer brewery, you know everything about the process of making beer. You may not be able to do it on your own - but you know the details of every step.

    1. 3

      "I mean if you are a CEO of a beer brewery, you know everything about the process of making beer. You may not be able to do it on your own - but you know the details of every step."

      100%.

      I was once asked, "What is your advice to non-technical founders who want to build a technical product?"

      My response, "Become technical."

      Even if you hire a CTO, dev, or agency, you need to have an understanding of product management and the dev process to be able to direct those resources. That doesn't mean you can or should do each step, but you need to understand the process.

      I've seen several founders burn through piles of cash outsourcing dev only to receive products that don't live up to their expectations and never make it to production.

      1. 1

        On point summary.

        As you've described it for the technical implementation, it is also important to have a similar approach to marketing. Personally, if I would do proper marketing on my own - it would fail (because I don't have enough experience). But, I have to have a degree of knowledge that allows me to evaluate the results of the work I would outsource to a professional.

        Unfortunately - and this is a topic slightly off from this conversation - in B2B spending money doesn't mean quality.

        Anyway, to delegate important work and being able to evaluate the results is what a good CEO is made of.

  6. 2

    Great post and it seems like you learned some good lessons. After this experience, what do you think would be your new criteria for bring on a co-founder?

    1. 1

      While my previous co-founder ended up not being a good fit operationally, there were also many areas where he was a fit. Those still matter.

      He is passionate about the problem and had the risk tolerance to take a chance. So, I don't think my criteria will change, just my approach. It's hard to know how you will work together until you've actually put the time in on a joint project.

      Going forward, I'll likely propose working on a smaller project with any potential cofounders to get a feel for what a working relationship would feel like.

      It's kind of like dating. Someone can check all the boxes, but you still might not click. That often takes time and the right circumstances to figure out. That's what I think was missing here.

  7. 1

    Thanks for sharing, I had really similar experiences with my first startup making educational robotics kits while I was in college. I had very little experience and was desperate for help and brought on two co-founders that I didn't know super well.

    A few months later, I realized we didn't work well together and things fizzled out pretty quickly.

  8. 1

    Good read, thanks for sharing.

  9. 1

    Good story and lessons learnt Rion - Venkat

  10. 1

    Thanks for sharing. You mentioned overcomplicated and overbuilt (vs hacker mindset) - can you elaborate? Was the code quality bad, or just not appropriate for the stage you were at?

    1. 2

      Yea, definitely. The code quality was fine. In fact, his code was wayyyy higher quality than mine. The problems were more with the tech decisions and the ability to get the implementations working properly.

      The only decisions I had made were NextJS on the front end and Contentful for the CMS. The plan was to use Firebase for auth and NoSQL, but those choices weren't set in stone.

      The idea was that any CTO co-founder would be able to make the majority of tech stack decisions beyond the front-end framework and CMS. We did end up going the Firebase route and he decided to use GCP for hosting to keep things in the Google ecosystem.

      The first issue was that it took 3-4 weeks to configure and get CI/CD working properly on GCP—don't ask me why, I'm not sure on that point. With that CI/CD came four development environments, which in my mind is way overkill for a beta (not hacker).

      Throughout the journey, GCP issues were a constant annoyance, and early on I suggested we try moving to Vercel—but he had already put so much work in that he didn't want to switch.

      The second overcomplication was using Apollo for state management. This never became fully functional despite 2-3 months of work (not hacker). The codebase for the implementation kept growing and becoming more complicated, but it was still broken.

      There were other overcomplications, but those were the two big ones. The hacker mentality would have been to get things working, then optimize, and then worry about redundancy and robustness.

      1. 1

        Thanks for sharing, I got it. Which GCP stuff was he messing around with? I'm on a Google stack as well (Firebase, Cloud Functions Node.js), but I'm also self taught so haven't done anything related to CI/CD (still not even sure what that does or means!).

  11. 1

    thank you for sharing,
    I have only one comment - if you are non tech person "learn to code" must be "learn about coding so you know how much you do not understand and do not try to be a CTO", if you going to have a CTO let it decide how to build the project and you concentrate on the rest of the business, any attempt to get involved on technical level will end up hearting your company.
    that said, if things are not going well and deliveries are getting postponed more than once you definitely need to make changes.

    1. 1

      Good point on the context. I updated the post accordingly. My point isn't that you should learn to code so you can be the CTO. It's that if you are remotely technical, you should try building first before bringing on a co-founder. The barriers to building and deploying web apps have never been lower and doing this will ultimately help you have better conversations when/if you bring on a CTO.

  12. -1

    This comment has been voted down. Click to show.

  13. 2

    This comment was deleted a year ago.

    1. 1

      Agree that the co-founder title for a post-rev company that is several years old doesn't make much sense. In this case, StepLadder was very early stage—pre-rev, pre-product, pre-users.

      My next partner may not have a co-founder title. This will depend on where the business is at and what milestones we've already hit.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 28 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 14 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments