Buy it or Build it?


On a warm Sunday morning in April of 2014 -- a time before I learned how to create with code -- I open my laptop in my kitchen and started to download the android APK. As the download finished I unzipped the compressed files and felt optimistic: I was going to start building the android version of an app that my cousin and I wanted to create.

The minutes turned into hours as I guessed and googled my way through the basic setup process. Just as I finished setting up the environment for development I heard a gentle knock on the metal screen outside my door. It was Stan, my cousin, and co-founder, right on time for our meeting to discuss the design and what our next steps would be.

“OK, so I got the ball rolling, let’s start by adding a login screen,” I mentioned timidly.  

We sat down at the kitchen table and stared at my laptop, essentially expecting our good-hearted ambition to put lines of code on the editor. We stumbled through getting part of a standard login design to render on the android emulator.

Given that both of us were completely clueless about code, I suppose it would be a little generous to call that the first pair programming session either of us had.

Between A Rock And A Hard Place

A week prior we decided to hold off having our app built and try to build it ourselves. A couple of questions are all important ones for anyone considering the endeavor to form a founder-funded startup: “Can we build it ourselves? Should we try and learn to build it ourselves? And finally, should be pay to have it built?”

Our thought process was simple: if we could make a passable prototype we could use it as a visual centerpiece for our pitch. It would be used demonstrate our idea and get enough early adopters excited about our app to propel us forward. Each time we talked together we reaffirmed the pros and cons of our choices.

PROS:

Ownership - “It's our baby, we built it from the ground up, with our own hands.” Just the ability to say that would give us great pride and we would learn invaluable skills along the way.

Cost - Free. Who can argue with that price tag? Well, kind of free, time is not something you can get a refund on or recoup.

Accountability - We are a cohesive team, we would do everything in our power to make something of which we were proud. We would not clock out at 5 pm or cut out early for happy hour.

Decreasing Technical Debt - We would learn a new, invaluable skill and understand how our product works from every angle, minimizing technical debt.

CONS:

Momentum - The struggles of learning a new skill, trying to balance productivity with realistic goals could dampen the fire in our bellies to just an ember. Well, maybe less than that.

Time - We both had demanding careers and couldn’t work on our dream full-time -- at least not until we had a product in the marketplace.

Quality - Despite our best efforts and complete lack of training, it would be obvious to even the most casual observer that our product was not "ready" for production and deployment.

TICK-TOCK

Hours went by. Our egos were imploding and fuming. We were essentially playing mental chicken: who would say they were completely lost first? After getting one page to render we called it a day.

After a month of fruitless effort we were essentially facing the same question we had a started with: buy or build?

“OK, so I don’t know if I can do this,” I started in a somber tone, "at this rate, it will take me a year to get a prototype up, and that one guy said he could get one up for us in a month or less.”

“Yeah man, this isn’t going to fly, huh?” He confirmed.

“If we do this, at least one of us has to go part-time and focus primarily on this project,” I suggested.

However capable and driven we were, we had to come terms with our lack of progress thus far and make a change.

To weigh out our options we searched for a tool to guide us -- and I remembered one I learned in ECON 101:


The Guns vs. Butter Paradigm


"In macroeconomics, the guns versus butter model is the classic example of the production possibility frontier. It models the relationship between a nation's investment in defense and civilian goods. In this model, a nation has to choose between two options when spending its finite resources. - www.investopedia.com/ask/answers/08/guns-butter.asp

As a new startup with an idea, our finite resources were time and capital.

As we continued down our current path of making our app in-house we had to find a balance between the two and maximize our potential output, to do so we asked ourselves a few questions:

With Regard To In-House Development:

We knew that we had a few important questions to ask ourselves:

1.) Can we spend enough time learning code to produce an MVP?

2.) Can we afford to go part-time at work?

3.) Can we scope out our MVP properly given our lack of technical experience?

Outsourcing Option:

Then, we knew we had to add a couple of other, harder questions to the ones we already asked:

1.) Would it be more productive to focus our efforts on our careers and use our increased incomes for production?

2.) Could we make enough surplus income to make a difference at this stage in the process?

3.) Would the cost of outsourcing be high enough to create a barrier to entry?

The questions were reasonable, yet we felt like something was missing because the conversation felt lopsided, so we looked for another way to analyze our options.

We Found Another Tool: The Project Management Triangle.

                                                               

"The project management triangle is used by managers to analyze or understand the difficulties that may arise due to implementing and executing a project."

Traditionally the PM Triangle has 3 constraints: time, scope and cost, but since our MVP was already scoped out thoroughly, it was more appropriate to consider quality over scope in our situation.

Our MVP Triangle:

Time:

- In-house: Can we be patient enough with ourselves to learn what we needed to learn?

- Was there pressure to roll-out an MVP right away? Could we take our time in stealth mode?

Cost:

- Make more & spend more on outsourcing or make less and save on production.

Quality:

- Could we get enough of a positive response with an MVP made by early stage engineers?

- Could we gain more momentum faster with an enterprise-grade product?

As our conversations ebbed and flowed.

We came to the realization that the core value we wanted to hold everything else up against and balance everything else upon -- was quality over anything else.

With that in mind, it was much, much easier to make decisions that carried us through design, development and finally launched in March 2016.

Our Balancing Act

So what did we end up doing it? Did we outsource? Did we hunker down, study and code?

Surprisingly enough we ended up doing both!

We put our capital toward hiring a phenomenal team of engineers. “That guy,” I mentioned earlier was Paul Keck, of Boundless, was an integral part of helping us move forward. Paul was also the impetus as my growth as an engineer. His expertise in technical project management and software development made our goal a reality.

In turn, I slowly phased out of my former career as a Technical Recruiter and started studying software development full-time. Months passed as I cut my teeth in code and eventually I reached a point where I could build features while decreasing technical debt and cost of production.

Looking into the future I am more confident than ever before in the viability of our venture, the relevance mission, and our product.

My Two Cents, choose your own adventure:

For any aspiring entrepreneur interested in coding or for one who has a background in mathematics, engineering or a financial field: Lucky you! Leverage your technical prowess and passion for learning what you need to know in order to build your vision.

But before you get cracking, please refrain from building or even making layouts until all business fundamentals are achieved.

Here I linked to an earlier blog that goes through the process of identifying customers, users, and opportunities for income generation.

For those professionals who are more interested in the "what" rather than the "how":

Don’t feel obligated to learn code, but be prepared to communicate clearly about your idea.

There is simply no excuse for bad communication when it comes to building your dreams, if you can’t convey your vision in a quick, precise manner you will end up stumbling through many pitches.

Look on my website where I've linked an audiobook that will help anyone get their technical literacy up to snuff for a conversation about software/web development, and another link to a post I wrote regarding making a pitch.

For those interested coding their product, but intimidated by it:

If I can learn it, I know you can too. Given enough grit, effort, and passion you can make your product. Every year it is easier to learn to code with the advancement of different learning modalities.

Here I’ve linked an article on how I learned to code and another where I explore the thoughts that kept me from getting started sooner.