Ready to Hire an Engineer? Read This First

It's 2018 and the gig economy is evolving to rapidly overtake the old paradigm of working as a cog in a company until retirement.

With services like AWS, Zendesk and Shopify, it's easier than ever to create a one man operation that looks like a huge company. It's my hope to enable more people in this world to grab their own slice of the pie.

As a software engineer, I've built minimum viable products (MVP) for clients looking to create a SaaS product that serves a niche in the market. I've created this guide for two kinds of people:

• Non-technical aspiring founders with their first big idea
• Freelance engineers to help focus on the most important thing — bringing success to your client

Startups fail for the same reason 90% of restaurants fail. It seems daunting to even try given that statistic until you realize that 90% of people don't perform the due diligence it takes to be successful.

Just watch an episode of Kitchen Nightmares! With the right preparation, the odds of success can be stacked in your favor.

Before you start looking for an engineer

Don't be an "Idea Guy." Your idea is probably shit!

Non-technical people often have the misconception that they can just create the software and people will come and use it. They have the idea and it's just a matter of hiring an engineer and things will just work out.

If it were that easy, I wouldn't bother finding clients! Technology enables the business but there are far more factors involved if you want people to actually sign up and give you money to use it.

Engineers are expensive and there are plenty of ways to vet and refine your idea to make better use of our time when you have something worth building.

The purpose of the minimum viable product is to have just enough to learn what your users need and no more. Dropbox got away with just a video. Pandora was a set of Excel macros.

Your idea is an initial seed — don't try to execute on the full vision. Look for those one or two features that you believe make your app a instant buy and focus on how to deliver that to test your hypothesis. Worst case scenario — you have money left over to pivot into a different idea.

Does it solve a pain or offer a sugary convenience to your users?

Consider Gum-tastic (note: not a real app), an app to have gum delivered to your location from your smartphone. Is it a good idea?

Consider the running costs.

• The overhead of maintaining a crew of drivers to deliver said gum
• The cost of developing the app — an engineer is around $10-12k per month, full-time
• maintaining gum inventory

These factors don't immediately disqualify the business. For many businesses, the overhead may be even higher. The real question is, who wants gum so badly that they will pay a price for the gum that factors these costs in?

Frankly, I don't see Gum-tastic working out given that I can easily walk to a convenience store where the relative overhead for supplying myself with gum is going to be significantly lower.

Then again, you might be in an area where the super-rich have no such qualms about paying $10 for a pack of gum if Uber rides are any indication of real-world costs.

If Gum-tastic seems contrived, consider the now-defunct startup SpoonRocket, which delivered meals cheaply to consumers through an app in select locations in San Francisco.

They are a great example of how VC money can send your startup in the wrong direction. Angel investors want unicorns and will push business to expand until economies of scale kick in.

Instead, the glut of VC money allowed the founders of SpoonRocket to negate asking obvious questions like whether users would pay for the food over existing alternatives at a price that reflects their actual overhead.

They subsidized the cost of the meals by selling them at or below cost. At $5-$8 per meal, users loved SpoonRocket. When SpoonRocket started to run low and were forced to charge a realistic amount, their users disappeared.

In contrast, consider Eaze, a startup positioning themselves in much the same way as SpoonRocket, but by delivering marijuana to your door.

The product itself has a high markup that users are willing to pay. In addition, the product has a stable shelf life. Users are more than happy to pay for the convenience of weed delivery at a price that allows Eaze to pay their bills.

It seems obvious in retrospect, but this is why most startups fail.

Do it manually until you need to scale

One thing I ask business owners when trying to help them scale their businesses is to ask them what they still use Excel for. Businesses, at their core, are a process involving the coordination of people to provide a good or service in exchange for money.

Software is useful to the point that it reduces the marginal costs of running the business.

Telephone services existed before we had computers. Human operators tirelessly routed calls manually and the price of long-distance communication reflected that.

Even with the high cost, users paid. The service and the software that eventually took over enables us to talk to each other today at rock bottom prices.

The phone companies would never have made that investment in automation if there wasn't a market for humans to communicate with each other over long distances.

As a new founder, step back a bit and consider the business process you are trying to create and see how much of it you can get done without software. ZeroCater, which manages food catering for corporations, started out as one guy, Arram Sabeti, with a spreadsheet.

Because he was doing it all by hand, he knew exactly what needed to be created. When the business started taking up all of his time, he brought in an engineer to write a Django app that codified the processes that he himself learned building the business. The software did in seconds what had previously been several days of work every week.

You can't just throw money at the problem.

As I elaborated on earlier, software is only going to be as successful as the business processes they are automating. A failing business process is not going to be magically profitable with software.

As a consultant, my success is the success of my clients. It's less about the code I write and more about the questions I ask.

One benefit of bootstrapping your startup out of pocket is that it makes you pay attention to the bottom line. Had SpoonRocket held to the discipline of being profitable ASAP, they would have found a way to succeed or shut down long before wasting millions in VC capital.

One month is the magic number

In my first meeting with a client, I try to establish what the solution they are trying to solve is. Usually, I am greeted with grand plans of what the product will be to the entire user base.

The vision is something fully featured and my mind quickly tallies the thousands of man-hours required to bring this vision to life. Assuming their budget can support this vision long term, I work with them to pare down to a set of features that can be delivered in one month.

Why one month? Software complexity and planning is insanely hard. After six years, I've determined that one month is enough time to create something that delivers value while being short enough to force everyone involved to focus on delivering only the most relevant features.

My goal is to give my client something he can charge for. This makes his customers happy because they have something they can use. This makes him happy because he has revenue he can use to continue development and, finally, this makes me happy because I have data points I can use to inform future features to develop.

Document your business context and domain knowledge

As an engineer, I know technology. I have a stack I am comfortable delivering features in and a body of knowledge I can rely on for building almost any feature my client would want.

The thing I'm missing is the context for that feature. As a founder, your greatest asset is the domain knowledge you bring to the table. The most direct way to ensure your success in getting the software you want is to document it so that I can refer to it and develop a reasonable understanding of what it is you want.

Too often, software in its conception is like an elephant being fondled by three blind men. Similarly, without the luxury of knowing what a lion looks like, things can get pretty weird.

Unfortunately, more money does not negate these issues. This is one of those places where there is no substitute for time and proper documentation to allow the engineers to get up to speed with your needs.

After an initial meeting with a client, I always ask them to create a wiki with a set of target users, associated user stories, and scenarios. Along with this, I highly recommend Figma for collaborative wireframing. This creates an explicit trail of context for future development and eases onboarding as more engineers get hired.

Find your early adopters

Tesla was not the first company to market an electric car. What they DID do was make an electric car that the rich would want. Elon Musk understood that the average person was not so price insensitive that they would pay the markup needed to drive cutting-edge development.

By targeting the rich, he found a userbase of early adopters willing to pay a premium for a premium product. It's only recently with the Model 3 that Tesla markets to the middle class. In a similar vein, you're more likely to find success if you identify your early adopters.

It's never too soon to bring in early adopters. If anything, they are the best people to put in front of a wireframe. It's tough for me to make a case to cut or put a feature aside when the client is looking at the wireframe and offering to put money down as soon as it's delivered.

A good early adopter will be happy to provide feedback as they've paid into the system and have skin in the game to make it usable for their own purposes.

As a founder, your idea may be informed by your own experience in a particular field. You may already have such people in mind. Before even talking to an engineer, create some mockups in Figma and sit them down with the wireframes.

You might find they love a part of the idea you only viewed as an afterthought.

Finding a great Engineer

Engineers can't be evaluated on a linear scale. Depending on his or her experiences and interests, he or she may be great for some projects and poor for others.

I myself would not be a good choice if you need strong artificial intelligence, but I'll be great at making a real-time GraphQL API or real-time streaming data if that's more your speed.

One thing is for certain — hire global. The world is getting smaller thanks to communication, and it's getting easier than ever to find a top-tier developer.

More engineers are going remote first and prioritizing heavily the contracts and projects that allow us to live life from where we want.
You also won't be competing with Facebook and Google to hire top-tier devs.

What you can offer is flexibility. I myself took a significant pay cut to work while traveling the world. Ideally, you should be looking for someone who can not only code but can be proactive about asking questions concerning your use case.

As for where to actually find us, word of mouth through an engineer who's currently busy is a good bet. Codementor is another great one. Whatever you use, make sure you can have direct contact with the engineer as it's he or she who will be creating your vision.