LookFar Ventures10 September 2019

How to Build Your Magic Machine: A primer on technical development for Startup Founders

© Chris Reade, November, 2017, update Sept 2019

In my work with startups over the last decade, one of the most important decisions a technically-oriented startup will face is:

“What is the best, as in most efficient, method to use to get the product or system that your new company revolves around built?”

Aka – how do I get the Magic Machine made?

There is much discussion and debate on this topic but not much in the way of something that pulls the options together in a single place.  In this article I will attempt to do that.  I summarize the number of ways that this task is usually accomplished and I will examine the pros and cons of each approach in various terms.

The four (and a half) approaches I see start-up businesses take can be generally described as:

• Technical Founder/Co-Founder
  Either build it yourself or, more often, team up with a software developer and work with them to get the product built.
• Freelancer
  Engage a person who works as an independent consultant, freelancer or similar to get the work done for hire.
• Dev Shop
  Hire a company that builds software professionally to build out the product.
• Offshore/Nearshore
  Comes in both the Freelancer and the Dev Shop version, this option means going out of your country and finding a company or individual who can build the software for you.
• DIY Programs
  I’m including a mention of these here as a footnote primarily.  We’ll examine that market at length in a future article.

In my time I have been the head of a Startup Studio, a Dev Shop owner, a freelancer, a technical founder and co-founder.  I have seen all of these approaches dozens and dozens of times.  I have seen all of them be successful and yield results.  I have seen every one of them fail and end in acrimony and even lawsuits.

Each one doesn’t fit and isn’t appropriate all of the time for all start-ups. It is my hope that this article helps start-up founders make the right decision on this crucial issue.  This article endeavors to clarify what is involved with each way to get software built.

When to start thinking about how to get your product built?

I would argue that the best time to figure out how you are going to get your product built is when you are past the point where you’ve decided to invest significant money or time into your project.  By the time you are at the point where you are going to figure out how to build your magic machine, you should know a lot about it.  That’s a topic we’ve covered in other articles.  In this article our assumption is that you have decided to go forward with the cost and time investment to build your product.

Each of these approaches has different cost metrics in terms of time, money and attention required and right at the beginning is when you need to start to consider the question.

The key to making good decisions early is understanding the lay of the land and what the process is.  This article covers the options for how to get software built.  We will get into the nuts and bolts of running a software development project as a client in another article that will focus just on that.

The argument for thinking about this issue early is that oftentimes the method chosen will help shape the rest of the product creation.  This is because three of the four approaches we’re discussing have options where the person or company may be able to help craft the vision for the new company, its products and its software.

Option 1: Technical Co-Founder (or Founder)

In a perfect world, when you want to build a house you have the skills to build it yourself.  Many of the largest technology companies in the world have been built this way.  Think Microsoft (both Bill Gates and Paul Allen were programmers and technologists), Apple (the Woz was the real technologist but Jobs was certainly technically capable) and Google (Sergey Brin and Larry Page were both PhD candidates in CompSci).  But there are many that were started by non-technical or semi-technical people.  Consider Parker Conrad of Zenefits (Chemistry) or Miguel McKelvey of WeWork (Architecture).

Pros of having a technical co-founder/founder

Where being a software developer or having one as a partner, co-founder, etc. helps out of the gate is in two places: 1) getting the first version, prototype or MVP built as inexpensively and as fast as possible; and 2) knowing what is possible and what is impossible instinctively.

A technical co-founder often acts as a foil to the founder and helps shape their ideas as well as builds the software that expresses that vision and makes it real.  They have skin in the game and they can make investors, especially angel investors, feel like the company and its products have a future.

The primary advantage that most startup founders see in a technical co-founder is the cost.  They often see the co-founder as the free labor to make their vision sellable to outsiders at zero cost.

The second thing that founders prize in technical co-founders is that they bring a technical viewpoint to the product.  They know that Natural Language Processing is no joke in terms of implementation and that adding Stripe for payment processing is the simplest way to go in the beginning.  They are experts in their field who care deeply about the company succeeding.

When it works, this is amazing, because as the company grows, that technical co-founder gets to be Chief Technical Officer (CTO) and they can bring on additional resources, either internal as staff or external as contractors.  The advantage is that you fill an early growth need using the person you already have, who has intimate knowledge of the product, its needs, and where you want to take it.

Cons of having a technical co-founder/founder

There are many issues that you often see in this approach.  They can be roughly grouped into: 1) they get bored/tired/burnt out; 2) founders have no idea if they are capable or not; and 3) they have an out-sized expectation of how critical their expertise is.  We’ll look at these individually.

1. They get bored/tired/burnt out

As the technical co-founder it often feels great to be in charge, to have complete product control. Often technical co-founders have a day-job in technology and don’t have that freedom in their workday so building a Magic Machine of their own that might free them from the hum-drum of a “regular job” is irresistible. At first.

As the months pile on and the product isn’t complete; as the fights over what features are really needed continue to escalate and the other founder(s) just don’t appreciate or understand how hard building commercially viable software really is, it is easy to get burnt out.

As the risks of having a technical co-founder go, this is the one I’ve seen the most in start-ups. Software development is a frustrating profession and a co-founder doesn’t have a team around them like they do at their regular work. Being the technical founder of a start-up is old-school: you are on your own.

There are ways to combat this issue if you are the non-technical co-founder or the technical one, but those we’ll tackle in another article. It’s too involved to get into here, but suffice to say, this is a serious issue that gets too little attention.

2. Founders have no idea if they are capable or not

You have this awesome idea for a dog-sharing service.  You have a friend of a friend who is a developer at a local company.  He seems like he knows what he’s doing and is willing to come on as a 40% owner with you.

But the first version crashes every time you try and run it on your phone. You have to create accounts on the website first and it only works on Android.  He can’t give you a report of how many visitors have come to the site or downloaded the app.

At this point you want to “fire” your free help but how can you do that when they own 40% and can legitimately say they had a hand in the idea?

Having a technical co-founder is great but it’s really hard to know if they’re any good at software development.  Joel Spolsky says that good developers vs great ones is 10x (https://www.joelonsoftware.com/2005/07/25/hitting-the-high-notes/).  I would argue the other side: that poor or mediocre software developers are 1/50^th or worse.  The reason for this is that mediocre developers don’t yield mediocre software – they typically yield no software that you can expect anyone else to use.

But as a non or semi-technical co-founder how would you know who’s good, who’s great, and who’s mediocre or worse?  Reputation is one of the best ways to know this but it’s hard to find the right people to ask, by which I mean, people who are in a position to know the difference and will be honest with you.  Again, there are ways to handle this but it’s outside the scope of this article.

3. They have an out-sized expectation of how critical their expertise is

This one is touchy and doesn’t show up typically until the MVP of the product is out the door.  The simple way to understand the problem is to imagine hearing some version of this sentence from your technical co-founder: “You wouldn’t have gotten this business anywhere without my ideas and know-how”.

The problem is that, often, the non-technical co-founder is the one with the ideas and the technical one is executing the vision.  However, the origin of the ideas and the required domain expertise can take on a lower consideration in the mind of the technical co-founder, because they had to take those ideas and turn them into a working product.

This is a problem because, as my first attorney used to say, “everyone’s your friend until there’s a little money involved”.  As investment starts rolling in and the person with the industry/domain expertise continues to be critical, and the technical person’s ability becomes less critical (usually because staff members are now working on the product), their ego can get bruised.  However, they are a substantial owner and may have technical ownership of some key assets of the company (domain name, code base, etc.).

Summary

On the balance the technical co-founder solution has the best upside of the four ways to get a technical product built for a start-up.  But, it has some really serious pitfalls that can sink your start-up just as easily as not generating sales can.

Option2: Hire Freelancer(s)

Even if you have the requisite skills to repair or build a house there is a role for a Contractor.  For example, if you’re an electrician, you don’t frame the house out yourself.  In the same way, just because you’re a DBA, (database administrator) doesn’t mean you should try and write an iOS App from scratch.

So, whether you’re a technical person or not, there are solid reasons to hire a freelancer or several of them. We’ll explore the positives and negatives of this approach in this section.

Pros of hiring a freelancer

The upside to freelancer(s) over technical co-founders is that they don’t own equity, they’re easier to check references on and they take direction well (usually).

A good freelancer who is well rated has most of the upsides of the technical founder except cost.  They are not free and the good ones can cost as much as a Dev Shop.  A key positive of this type of engagement is that you can usually find someone with expertise in the technology that you are using.

So, to stick with the iOS example, you can certainly find an iOS native developer with experience in gamification or in working directly with the phone’s camera.  In this regard the freelancer is better than the co-founder in that the technical co-founder has the skillset she or he already has and will have to learn whatever new tech the product needs to be developed in.

The other big upside over the technical co-founder is that you can usually figure out if they’re any good or not.  Every one of the platforms that are out there have ratings and most have comments and feedback beyond the rating itself.  That can help you figure out if you want to work with someone.

There are several ways to engage with this type of contractor.  Typically speaking they work either hourly or by the project or by the sprint (typically two-weeks of work).

It is outside of the scope of this discussion to get into the best practices of doing each of these, but it is critical to note, that a startup founder of a company with a technical product must get educated on the subject of the Software Development Lifecycle (SDLC).  This means having a good, high-level understanding of how software projects are executed.  You don’t have to become a software developer, but if you’re going to work with them directly as freelancers, you better understand how the process works.

Cons of hiring a freelancer

The downsides, generally speaking, of a freelancer are somewhat similar to the technical co-founder problems.

1. They lose attention or focus on your project

One of the big ones, which is analogous to the “they get bored or burnt out” problem, is that the important part of freelancing is the first four letters – free.  People often get into that lifestyle because they choose their own projects, their own hours and don’t have a direct supervisor.

This means that these folks are not your employees – they have limited loyalty to your project, and will put it on the back burner if they get a bigger or better paying project.  They may also get offered their “dream job”.

The somewhat good news is that you can just hire another one but there are a lot of switching costs involved in that as well.

2. They want to build your product their way

Another major downside is that these are usually highly skilled professionals, often with five to ten years of professional software development under their belt.  That means they have definite ideas about how products should work.  That can work to your great advantage in that they have built many more products than the typical startup founder has.  But it can also mean you have to fight the freelance developer(s) to get things to work the way you envisioned them.

A lesser issue with freelancers, but still one worth considering, is the question of intellectual property.  Most platforms have sample contracts and legalese to protect your rights to the work product.  But  it is not as easy as it might seem to sue someone in another state and very difficult to do so internationally.  The key phrase in the United States in this area is “Work for Hire”.  However, as with everything you do with your startup, a good attorney is one of your most key investments.  You absolutely must get a lawyer to read any contract with a freelancer.

Summary

Freelancers are professionals and they have ratings and portfolios that you can review to gain comfort.  There are a lot of them and they’re pretty easy to engage with.  But, they have a distressing tendency to disappear or drop off their engagement when it is least convenient for you.

Option 3: Hire a Dev Shop

The software development firm, or “Dev Shop” in industry parlance, is a company that builds software and systems professionally.  They vary in size from 3 people to large ones that employ thousands of people.   Typically, however, the ones that will work with startups or smaller projects in general, top out at around 30 people.

The best part of working with these companies is that they have a large skill set, a lot of experience in building and deploying software, and can scale with you until you can afford to hire internal teams.  The really good ones also have consulting capabilities to help you figure out marketing, strategy, design and other go-to-market needs.  Some are industry-focused and therefore know a lot about the niche that you’re working in.

Of course, all of that comes at a cost, and Dev Shops are typically not cheap.  Similar to freelancers they are mercenary by definition. Unlike freelancers, they can almost always be counted on to stick with the client because they aren’t resource constrained.  If staff turnover occurs, they can always put another developer in place of the one that leaves.

It is not uncommon in startups, that I have worked with, for the Dev Shop to stay involved, even as the company scales.  They become either the tip of the spear doing the new features of the product or become the back office that handles the maintenance.

Pros of hiring a Dev Shop

The good part here is that these companies have, as their mission, to build software.  They aren’t sidelining dev work between full-time jobs or working nights and weekends.

They also have the resources internally to take projects from conception to go-live.  You don’t have the learning curve that even the technical co-founder does – these folks do this stuff for a living so they tend to be pretty good at it.  They will tend to know the latest tools and have access to hosting, streaming, and other services, that would be too costly for you to buy on your own.

A good Dev Shop also has internal product managers who take a lot of the burden off of the startup founder.  You have to manage them like any resource in your new company, but you can count on them to deliver the goods they agreed upon, as long as you structure the contracts and deliverables correctly.

As with freelancers, this group needs careful consideration of the terms of payment and delivery of product.  It’s again, outside the scope of this article, but critical to get educated on how best to work with a Dev Shop.

Cons of hiring a Dev Shop

1. Affording them is more than just what you’ve budgeted, but what happens when they go over budget.

The obvious first issue is cost.  You can expect to pay for the expertise and the know-how to get professional software made.  Depending on how you raised your seed capital, what your timeline is, and how much you want to “babysit” the product development, will determine whether this is doable.

2. Unless you’re open to advice, they will do exactly what you tell them

The other major con is the flip side of a major pro – Dev Shops are almost as mercenary as freelancers.  They care a lot about their reputations so they will generally provide a give-and-take on small matters but if you run out of cash to pay for features they will simply stop working.  The positive side to that is that they are almost always 100% professional – they may not love your product but they’ll execute the build of it with diligence and rigor.

That said, you must also consider how big their shop is.  Typically if the shop is less than 5 full-timers you’re probably going to be a big slice of their revenue and they will want to maximize that.  Over 50 is also harder to work for because your project might be too small.  We’ll cover this topic in another article, but if you go the route of the Dev Shop you should consider how big your project is to them as a way to understand if you’re going to get what you need from them.

As noted above, there is a lot of nuance to working well with this kind of provider, and we’ll cover it in another article, but the best advice here is the same across all options – be as clear as you possibly can be about what outcomes you want.

Summary

Dev Shops can be pricey and each one will want to work with you slightly differently, but they’re typically stone-cold professionals.  Finding the right one to work with in your market or region can be tricky, but the right one will also have contacts and industry experience that can help you build the best product you can.

Option 4: Go Offshore

For Microsoft, Google and every major tech company you can think of, going offshore has been part of the strategy for at least the last twenty years.  The world is indeed flat, as Thomas Friedman famously declared in the book of the same title. And nowhere is it flatter than in technology development.

For the startup founder going offshore is a siren song.  You get the professionalism of a Dev Shop for a third of the price of a freelancer.

As with everything, the reality is often not quite as rosy as it’s made out to be by the sales brochure.  Working with a near-or-offshore team can be rewarding and can save a lot of money.   However, this approach   can also end up with the same money spent on freelancers or a domestic dev shop and no product to show for it or a product that breaks easily or doesn’t scale.

Pros of using an offshore firm

Offshoring or Near-shoring (using a firm in a country closer to your own) is a well-developed economy now.  There are best practices, solid understanding on how to engage with them, whom to work with, and more and more talent coming available across the world now more than ever.

Done right it can allow you to get two things that you want as a startup founder – a business savvy product manager who understands what your product does and wants to succeed at getting it built, paired with technically proficient teams that can execute it properly.

“Done right” in this instance means shopping around, getting references and being willing to take the time to really sweat the details on managing the production of the software.

Cons of using an offshore firm

As with every product there is a lot of sales-y advertising and hucksters telling you that you can have everything you want for almost nothing.  Don’t believe it.  While you can knock a very good chunk of cost off of your MVP or product build, there will be significantly more hand-holding and management, and you can get burned badly on the quality.

We’ll break down the issues that are commonly experienced in going offshore next.

1. Poor code quality, unscalable solutions, too many shortcuts.

While it is outside the scope of this article to discuss how to maintain code quality, it is important to realize that this is a thing.  Unlike onshore dev shops, these folks are never going to have to look you in the eye, and while they work on referral a lot, they aren’t as protective or concerned about  their reputations.

Insisting on doing the Quality Assurance yourself, asking for results of unit testing and other metrics ensures they are doing the work you expect.  This also tells the Project Managers involved that you’re watching.

Another issue that crops up a lot is the extensive use of libraries that you may have to license.  This one can be a huge cost hit that you don’t see until near go-live or after when someone sends you a cease and desist letter.

Lastly, while MVP may have the word “minimal” in it, if the product can only handle 20 users at a time you probably won’t get to build the “real” version.  Asking for and understanding what load testing was done will help stop this from happening.

2. Time Zones and Cultural Understanding is harder than you think.

“We work while you sleep”, “Our PMs work on your time zone” and other marketing statements don’t change the fact that working more than three or four time zones outside of the one you live in is tough.  Not impossible to deal with by any means, but tougher than you think it will be.

Further, some cultural misunderstandings are inevitable.  I had a friend build a product for a hotel-oriented product. Western style hotels were not in his offshore team’s experience so he had to work through their understanding of what “normal” user behavior was.  These type issues can be worked through, but they are an issue.

Summary

Working with offshore firms can be incredibly rewarding – inexpensive, quality systems developed similarly to a dev shop in your market. It can also be a nightmare where you never get a workable product and run through as much cash as if you’d used a freelancer or dev shop locally.  The key here is having eyes open and knowing the process.

There is a potential overlap between offshore and dev shops.  While we’re going to cover it in the article on how best to work with them, you should be aware that some Dev Shops are actually off-shore firms in disguise.  You need to ask about where their work is done – if they hesitate the answer is off-shore.

Option 5: DIY Programs

DIY Programs are “low code/no code” frameworks that let you crank out a working app or website without engaging any of the professional options I’ve outlined here. The question here is how far you intend to take the process.  For prototyping and testing they can work really well.  They can help you get your thoughts in order in a way that can be extremely productive.   The downside can be that if you’re using these tools, and aren’t a developer of some sort, odds are good that you’ll end up with an unusable and unviable solution.

Pros of using a DIY program

The great thing about app building or website building tools is that they are typically fairly cheap and can get you something that works reasonably well.  These programs or systems are great at getting you out the door and delivering something that works.

In my experience, when founders come to us with a tool or site they built using one of these tools, they are often a useful jumping off point.

Cons of using a DIY program

There are always, without fail, limitations to these systems, that their web sites don’t go into or mention.  We’ll outline a few below.

1. No code access or ability to troubleshoot

A huge problem with using a code builder is that it’s typically a closed-loop system.  This is great in that it means you don’t have to know what’s going on below the covers.  But it means that you don’t know what’s going on below the covers.  So when something doesn’t work the way you want it to, which is going to happen, you have limited or nonexistent ways to address the problem.  Usually, you just have to live with the way you can get it to work.

2. Security and maintainability are minimally addressable

These programs have to build to an unlimited number of use cases by definition. This means that they have to make adverse or Hobbesian decisions about security, access, and other issues.  This can leave security gaps or let outsiders into your product.  Additionally, when they update their security with patches, you typically have to patch your product to take advantage of them.

Which brings us to be root of the issue:

3. You’re building your business on top of something you don’t own

In all of the other examples in this article, you the startup founder owns the outcome.  Good, bad or indifferent, you have title to what you paid for.  In this scenario you don’t.  That has many issues around it, from funding to licensing, to unit costs, etc.  For example, Google and Facebook have great tools but they change their Terms of Service and even the existence of their products as sutis their business needs, not yours, and since their stuff is usually “free” they don’t give much support when they cancel projects.

Summary

Using a DIY tool to build a prototype, to test assumptions and prove out market thesis is a fantastic idea that we suggest to startup founders often. They can be the easiest way to show someone else what you had in mind – an actual, functioning version of what you’re trying to bring into the world.  But to think you can build a business on something you have no title to or control over, is questionable at best.

Recap

When I started building technical products for other human beings to use I was still a teenager.  I didn’t know there was an option other than building it myself.  After over twenty years building them myself, leading companies based on them, building products for other people’s companies, and ultimately helping them get built without my involvement, I can say for certain that the magic is there – you can build your Magic Machine and it can change the world.

But in order to get there from where you are now, you have to understand the lay of the land, what the options are and what the pros and cons really are.  It’s just too easy to get excited and go down the path that’s right in front of you, rather than think through a product road map and make sober-minded decisions about what the best route is going to be.  If there is ever a moment to measure twice and cut once, this is it. And there’s no guarantee that you’ll be right but at least you’ll have thought it through and be in a good position of understanding to make a change.

But making that choice, whether you off-shore your product build, work with your best friend who happens to work in software, or any of the ways it can go that I’ve outlined here, the key to success is having your eyes open and knowing the bad things that can happen so that you can avoid them.

_______________

About the Author:

Chris Reade began developing software at age 13 building games on the Apple IIe. He has built software for many successful startups as well as systems that power billions of dollars in transactions.  He is from New York, where he started his companies before moving them to New Orleans in 2000.

Written by