Being a SaaS founder, I often wonder if I'd be better off knowing how to code... Any other non-coding SaaS founders making it work?

From PromoPrep’s founder, Steve Lamar:


Founder notes on the three distinct paths available to all non-coding founders:

(Featuring founders from: Moz, SparkToro, Podia, and Butter)

#1: “Invest in the knowledge necessary to hire, retain, focus, and manage great talent in the field.”
#2: What’s a Non-Programmer To Do?
#3: Why I Learnt How to Code


#1: SparkToro’s (previously Moz’s) co-founder, Rand Fishkin, shares Moz’s CEO, Sarah Bird’s recounting of how she took the unquestionably arduous third path of furthering herself enough to lead great tech teams. (Source)

Let’s use software engineering as an example because it’s something so many founders and would-be founders in the startup world struggle with (just look at the thousands of questions on startup-focused forums that begin with “I want to start XYZ but am not technical . . .”). Assuming you’re like me, and this skill is currently a level one [Theoretical knowledge or less] or two [Managerial knowledge], your options to make this a strength are straightforward:

  1. Learn the process and do it yourself.
  2. Start the company with co-founders who have this strength already.
  3. Invest in the knowledge necessary to hire, retain, focus, and manage great talent in the field.

Nearly every piece of advice I’ve ever seen ignores the last one and focuses on the first two. But after Sarah Bird became CEO, I watched her go from the low end of level one to the top end of level two, and turn a fundamental weakness we’d had at the company throughout my tenure (with only occasional success stories like the early link index) into a core strength in her first eighteen months leading the company.

How did she do it? I asked Sarah to contribute so we could hear directly from the source:

“Before Moz, my only software engineering experience was a Computer Science 101 course many years before. My lack of technical depth made me feel insecure about managing engineering leaders and teams. It was pretty easy to discern when development wasn’t going well, but it often wasn’t clear why. Was it because I had the wrong CTO? The wrong engineers? Perhaps the technical problem we were trying to solve was harder than we imagined? Maybe we didn’t have enough resources? Or the right resources? Were we underinvesting in development infrastructure and tech debt? I can spin myself in circles trying to understand the why.

Here are the top things I did to become a better leader of technical people and teams:”

  • Ask questions during skip levels (meetings where a senior manager meets with team members who report to the managers below them) with engineers that go beyond identifying problems and into concrete solutions. For example, asking, “What good development practices did your last company have that you don’t see in play here?” surfaces best practices.

  • When you find an engineer on the team who can articulate different strategies she has tried, and the why behind them with conviction and clarity, give her power to try implementing some of those changes here. Be her champion, even when she ruffles some feathers making change. If some of the strategies don’t work out, praise the effort.

  • Read everything you can about different engineering cultures and best practices. Read dev blogs for companies like Spotify, Netflix, and Airbnb. There are a lot of great books, blogs, and conference talks about best practices. Invest time to consume as many of these as possible. For example, I follow Edmond Lau (a software engineer who worked at Google and Quora, and runs the blog) and Jez Humble (who works at UC Berkeley and runs pretty closely. Go beyond the slogans into the meetings, habits, and platforms high-performing teams employ.

  • Take notes about the technologies and practices that you hear about in design reviews and one on ones. Then go back to your computer and google them like crazy. Read everything you can about the technology. While reading, keep in mind that engineers are famous for indulging in so-called religious wars about why a particular technology is “so much better” than another one. Learn to spot it when an engineer moves beyond advocacy to naive devotion to a particular tech. Take everything with a heaping spoonful of salt. You need to know the lovers, the haters, and the companies that are using the tech. There’s no such thing as the “perfect solution,” and beware anyone who tells you otherwise. It’s all trade-offs.”

  • Recruit technical leadership with a teaching orientation. The best way to “ensure that your CTO is going to make you a better CEO is to hire a CTO who likes to teach. Make it clear that you’re looking for someone to drive change and educate you and the team. Beware CTOs who try to “shield” you from the details. Being able to explain complex things simply is a job requirement.

Ultimately, leading technical teams comes down to curiosity and courage. You must be humble, ask questions, and read a lot about engineering. If incremental changes aren’t getting better results, you need the courage to change technical leadership. Keep changing and trying new things until you start seeing positive momentum, and then get out of the team’s way.”


#2: Podia’s (previously Carbonmade’s) founder, Spencer Fry, in this decade-old post, expands on the many early-stage things that kept him busy as a non-programmer. (Source)

Product Development & Road Map

As the business guy, you’ve got to look at everything with a big picture mentality. Think macro, not micro. I’ve got to think about what we can do today that will bring us to where we want to be in six months, one year, two years, maybe further along. You don’t want to spend all your time thinking too far in advance (dreaming, in other words), but you definitely need to have some sort of road map.

Managing Cash Flow & Budgeting Bills

I’ve told a lot of entrepreneurs that I think managing cash flow is one of the most important challenges. Sadly, this is something you learn over time and with experience. It’s really instinct — knowing whether $500 is better spent, for example, on marketing or development. It can’t really be taught.

Customer Service

Providing excellent customer service singlehandedly transformed Carbonmade from a side project into a profitable company. I can confidently say that, as pro-active customer response is the most significant “update” to our product we’ve released to date. When Carbonmade began, we were still a full-time consulting company, and we didn’t have time to respond to our customers. As the company began to grow, I stepped in and made it my initiative to handle all incoming e-mails right away and add a human touch.


Probably because we are a self-funded company that’s never taken financing, we get a lot of investors reaching out to us. While we’re not opposed to taking financing at some point, we’re in the unique position of not needing it right away, if ever. And that’s really attractive to outside investors!

Marketing (AdWords, Text Links, Banners, etc.)

Marketing has definitely taken over my life the past few weeks and will continue to do so…


Working with lawyers is not an inborn talent. If you don’t know what your needs are in advance, you can spend a lot of money needlessly. If you don’t do your preparation and carefully outline everything you think you need before going into a meeting, you’ll lose time, which is in turn billable hours.


#3: Butter’s co-founder and CTO, Adam Wan, reckons with the curtailed circumference of possibilities one can find oneself in, without the right technical skills and reflects on why he eventually decided to go all in. (Source)

Not Knowing What You Don’t Know

Talking and connecting to other software engineers, I realized how deeply complex, complicated, and challenging was the thing I was trying to build. I was way over my head.

With their guidance and advice, I started to map out ways on how to tackle this issue. I was mostly trying to figure out the architecture for how the app would run. However, the gap between understanding basic things like “frontend” and “backend”, and actually planning out a product launch is huge.

I was still unable to estimate deadlines and resource allocation accurately. I was unable to innovate properly, as my ideas were not informed by any technical foundation, but from just pure imagination.

I Couldn’t Find a Technical Co-founder

Firstly, a co-founder should be someone that you’ve built a connection with and trust. Unfortunately for me, the tech and startup industry was very distant from my social circle. I didn’t know many software engineers, and those that I did know were acquaintances at best. I didn’t have a Wozniak that I could trust and hole up in a garage with.

Secondly, due to my inexperience and naivety, I was not a very attractive candidate as someone else’s co-founder. Co-founders are business partners, when you go into a startup, it’s like entering into a relationship. At the time, I didn’t have the entrepreneurial or startup credentials or experience yet.

I Couldn’t Afford Real Software Engineers

Throughout the whole process of talking to several engineers, many declined equity and instead offered to build my app for a certain fee. This was my introduction to the high price of building software.

The investment that I had received would only get me to a version 1 of an MVP - this was a very risky transaction and went against the advice I was receiving about building startups. The advice being, you should position your startup to be able to develop and reiterate your product as many times as possible based on user feedback. It meant that I needed the flexibility to build ten different MVP iterations, not one.

I spoke to other founders in the scene who have burned through investor money by hiring contractors. I also spoke to founders that have built MVPs with cheap “nightmare contractors.” There didn’t seem like a middle ground, cheaper contractors have a high risk of failure, and competent engineers know their worth (and are already rewarded by the market, so they don’t need you).

What coding has done for me

Almost five years later, learning to code has opened up for even more opportunities than I had anticipated. I was able to build my initial startup idea as originally intended. After my first startup failed (in Q3 2016), I started doing software consulting on the side. Over the next three years, I was also able to work with many exciting projects along the way.

The reason I love startups is that I loved building out ideas and concepts. To me, programming was an art of problem-solving that required critical thinking skills and creativity. Software became a method of expression, a canvas for me to scratch that “wouldn’t it be cool if” itch. It empowers me as a maker and a builder to be independent. If you’re a non-technical founder and you resonate with my story, perhaps it doesn’t hurt to give yourself a few weeks to learn how to code. It may just change your life.