Want to Build an MVP Want to Build an MVP

ebook reader: The Founder's Guide To Building Software

    Print To PDF

The Founder’s Guide To Building Software… and Businesses

(5 minute read / 43 minutes front to back)

Learn how to build software fast and cheap, and scale a technical team.

The TL;DR Version

In a nutshell, this guide provides a proven framework for working with technical advisors, technical co-founders, CTOs, developers, and development firms.

It helps readers choose between the many different kinds of technologists that are available and avoid the most common pitfalls and misconceptions associated with each.

It is written for startup founders, but it is also relevant for established business owners, senior managers, and investors.

No prior knowledge or experience is required to read.

Main Ideas

  • Consider using advisors whenever you attempt something new
  • Technology, in particular, is expensive and complicated – approach it carefully
  • Teams of all sizes need technical advisors – everyone else is optional
  • Equity-based, board-level, technical advisors are not for everyone
  • Specific advisors with specific skill sets should work inside the business to complement and support everyone else

Parts I, II, and III are important and urgent if you are already building software, or are about to build software.

Parts IV and V are for those who want to master the art of scaling an organization.

Part VI is for anyone looking to make the most of a tiny budget.


As an entrepreneur, I often find myself hiring people to do things I can’t do.

When this happens, I usually find myself asking the same questions again and again.

  • Is my team doing a good job?
  • Is my team working cost-effectively?
  • And, is my team solving the right problems… or am I wasting my time and money chasing foolish and misguided solutions?

Perhaps you can relate.

This situation is what this book is about.

It’s about leading.

It’s about venturing into the unknown and managing things that you don’t understand.

Early in my career I thought the key to success was finding people that I could trust, but over the years I realized that I was dead wrong.

I learned that trust was never enough.

Becoming an effective manager meant that I had to be able to inspect the processes that my team followed from day one. I found that even the best intentioned teammates unintentionally wasted my time and money solving problems that didn’t need to be solved. And unfortunately, I found that the worst intentioned teammates abused the trust I placed in them.

So, I changed my tune.

Today, all I care about is alignment – and to achieve alignment, I hire lots of coaches and advisors.

Whenever I need to hire someone to tackle something I am unfamiliar with, I hire two people. I hire an expensive expert with decades of experience and a cost-effective worker bee. And, I ask the expert to coach me how to direct the worker myself, not to manage the worker for me.

I usually pay the expert about 1/10th of what I pay the worker. If I intend on spending $10,000 on something new, I pay an expert $1,000. If I intend on spending $100,000 on something new, I pay an expert $10,000.

Later, when things begin to move faster, I typically hire the expert to manage things for me… and then I hire a new coach to help me manage the old coach-turned-worker; and on and on it goes.

This is how I approach almost every new problem I face. It doesn’t matter how big my organization gets or how much money I have to work with, I always use the same approach.

Here’s what I don’t do: I don’t try to manage inexperienced people all by myself. I don’t hire really experienced people to manage everything for me. And, I don’t bury my head in the sand and pretend that the people I’ve hired will magically get the job done without inspection and support.

Coaches give me control when I otherwise have no control. They provide me checks and balances, and most importantly, the provide me levers that I can pull to achieve results.

And, I wrote this book to share what I’ve learned about this approach with you.

Consider using this approach when you find yourself “leading”… that is, doing things that they you’ve never done before.

And specifically, when it comes to expensive and complicated endeavors like software development, consider that this approach might be the only approach that makes any sense at all.

A Quick Note About Minimum Viable Products

Many readers will interpret this guide through the lense of a widely popular methodology known as MVP (Minimum Viable Product) advocated by Eric Ries in his book “The Lean Startup”.

While the approach itself is not the topic of this guide, readers who are familiar with it should know that the MVP methodology is completely ineffective when the team that applies it is not well aligned.

As a result, the methodology is often severely abused or misunderstood. This guide explains the drives and motivations of all the people you work with so you can apply the methodology powerfully.

Why I Wrote This Guide

There is a serious problem that I aim to help fix.

The problem is that CEOs routinely place their trust in the wrong partners, the wrong solutions, and the wrong processes because they don’t really understand technology and don’t have time to fully learn it.

This means companies fail when they don’t have to; and this affects our community, our economy, and our future.

The interesting part is that we already know how to solve this problem. All we have to do is help leaders understand how to work with advisors correctly in order to identify conflicts of interest and proactively solicit objective opinions.

How I Came To Write This Guide

Today I work in many capacities, including Technical Advisor and Technical Coach – but it wasn’t always so.

Prior to 2016, I cofounded four successful companies and assisted The Honest Company in its rise to multi-billion dollar unicorn status.

In 2016, I left The Honest Company dreaming of sharing my skills with lots of teams as a consulting CTO rather than dedicating all my time to a single venture; but I was not prepared for what happened next.

Most founders rejected my help.

More importantly, most founders rejected the help of everyone like me.

Almost every founder I spoke with refused to hire an experienced CTO until their technical team blew up in a really bad way or raised several million dollars. Even when founders raised significant amounts of capital they tended to stick with the same inexperienced leaders that they started with.

This meant disaster was the most common outcome for startups at every stage of growth. Nearly everyone in the community where I lived and worked had horror stories to share of projects gone wrong, relationships destroyed, and money wasted.

Yet, no one was doing anything about it; in Los Angeles no less, a top tier market second only to San Francisco.

I was completely perplexed.

I didn’t understand how founders could resist hiring experienced people so strongly when the entire community was so aware that technology projects usually ended up on fire (over budget, ineffective, and unable to scale).

Why weren’t investors, incubators and startup influencers coaching founders to get senior leadership onboard? And, why did VCs prize inexperienced technical co-founders so much?

Eventually, I realized that the real problem was that non-technical leaders had no way of understanding or inspecting what CTOs did, and this meant that CTOs were extremely difficult for non-technologists to manage.

It was suddenly obvious to me why founders avoided experienced CTOs like the plague.

Experienced CTOs pushed founders away from the developers that worked for them – and this made founders even less effective at managing the process of software development than they already were.

Ultimately, this meant that most founders needed people to help them manage things themselves, not people to manage things for them (e.g. Technology Advisors).

The weird part was that while the community generally supported the idea of founders working with Technical Advisors, few founders bothered to find them, and those that did usually expected way too much from equity based teammates.

The reason for this was that most people were making a number of assumptions about how founders were working with technologists as a whole, and this meant I finally understood my mission.

I needed to raise awareness about the importance of Technical Advisors, explain how to work with them effectively, and explain why they were not optional like most other kinds of advisors.

I began sharing my perspectives with everyone that would listen and soon developed an approach for working with startups that involved placing specific people with the teams I advised so I could stay in touch with the day-to-day without consuming much of my time – allowing me to remain hands-on and affordable.

Soon, I began to call these people Technical Coaches, but I didn’t consider my approach noteworthy until I had lunch with Sean Kane, the former President of The Honest Company.

That’s when I realized that the challenges which plagued early stage founders also plagued the leaders of unicorns and Fortune 500s – which implied that the approach I was using for small teams could be equally effective for large teams.

Not long after, I became passionate about educating the entire community about how I worked with my portfolio companies. I launched my blog jaycrouch.com, and wrote this guide.

My belief is that all boats will rise if leaders have the tools they need to make better choices. Businesses will have a higher success rate, and the entire community will be stronger for it.

Spread The Word

When you are done reading, please share this message.

Challenge your friends, investors and coworkers to rethink their approach.

And, if you have something you’d like to add – please email me at or [email protected] or contact me through my blog: JayCrouch.com.


Dedicated to: Dedicated to: John, Sue, Sami, Casey, Mazal, Dariush, Justin, Salar, Norma, Joel, Ariel, Chris, Dean, Nick, Sean, Ben, Ava, Michael, Meg, and Espree — thank you for supporting me. You know who you are.


Leave a Reply

Your email address will not be published. Required fields are marked *