When you set out to bring a business concept to life, your first technical hiring question is whether to build the minimum viable product (MVP) yourself or hire someone else to do it. The factors to consider in this decision are your skill set, the requirements of an MVP, and your ability to recruit quickly at a reasonable cost. With the advent of strong no-code solutions and the wide availability of high caliber contract labor globally, you have several great options. This paper will help you to determine the best route to take and provide guidance on building the best team for your chosen strategy.

Initial Questions to Answer Before Making Your First Tech Hire

Is technology at the core of your value proposition?

This is the first critical decision point. For example, if you make products that you plan to sell via e-commerce, do not build directly from scratch at this stage unless you have a specific digital offering in mind that is substantially different from anything else currently on the market. This is because for the majority of e-commerce applications, Shopify and Shopify Apps should be sufficient to accomplish most tasks. Likewise, if you’re building a relatively simple app that has basic create-update-delete functionality for structured data, no-code application builders like Bubble and Stacker could be great options to consider.

What does your budget afford?

If you’re starting out on a self-serve platform like Shopify, or a CMS,, it is best not to hire third-party developers on day one unless you’re operating with a sizable budget. You should do the grunt work of setting up your website, loading products, applying basic settings, and generally getting to feel comfortable in control of the dashboard.

Form there, you can let your budget and customer acquisition roadmap determine your priorities. If you currently have a live, active customer pipeline, your time may be best spent on sales. But if you have no budget, you can usually figure out how to get started yourself. If you do have some money to spend, small changes to your CMS may be best carried out by an expert who can do in an hour what you would otherwise take days to accomplish, giving you massive time leverage.

Should I learn to code on my own?

If you have determined that proprietary coding is required in order to deliver the MVP of your product, your options are to learn how to build it yourself or hire an expert.

In the vast majority of situations, learning to code in order to ship your MVP is not preferable and should only be chosen if your idea is not particularly time sensitive. In this situation, you can afford the time to spend cycles on learning before actually shifting your undivided attention to addressing the market.

Note that while following some tutorials, you may find it quite simple to build a basic app. However, you will inevitably get bogged down for long periods of time solving bugs and making changes in your own implementation. Startups have successfully executed this path, but if you go this route, do not set aggressive timelines. Expect the initial product to take at least twice as long, if not three to four times as long as originally planned.

If you have no cash to pay for software development and you don’t have the track record to raise quickly, this approach could make sense. It may take you six months to get a dollar of angel funding, whereas you could get at least an initial version of your product out the door within one or two months.

Another positive to learning to do it yourself, especially if you are non-technical, is that building something and shipping it can help you gain credibility with the technical people that you will be hiring down the line.

If You Choose to Get Help Building Your MVP

If you choose to engage a technical resource to help you build the MVP, at this point in the decision tree you have from two options: attempt to find a technical expert to join your core team or hire contractors to get your work done.

Finding a Core Team Member

The benefit to this approach is that if you recruit successfully, you will find a thought partner who will be the foundation of your technical team, help you alleviate technical hiring pressure for a very long period of time, and help you avoid technical pitfalls — while freeing you up to focus exclusively on sales and marketing

The downside to this approach is that you are working with minimal resources to recruit, and you are likely inexperienced with vetting people who will be of the highest caliber. You’ll find it hard to get top talent without either an excellent track record or strong traction already in place. If you do find a great candidate, you will be expected to compensate them with a substantial amount of equity.

Another reason that full time hiring may be premature at this stage is that you simply don’t know what exactly your team will shape up to need medium-term. You may find yourself pivoting into a different product line or perhaps even a different industry.

For example, if you are a business development expert working in an AI company and you need a technical partner to build a very specific offering that you know a large portion of the market wants, you should certainly search for a cofounder who is a technical AI expert.

On the other hand, if you are building a simple web services app, you might consider waiting to focus on building a full fledged engineering team until further down the line.

Building a Team of Contractors

This route is predictable (you can spin up resources from UpWork or your own network very quickly), and much less costly than hiring a full time engineering team.

Since contractors are paid hourly, your incremental cost of an error (wrong product, wrong assignment, poor hiring decision) is usually minimal and can be quickly rectified.

This is a fast and effective way to build your MVP, but only if you apply rigorous management practices and careful accountability to leading your team.

A contractor is inherently with your team for a short period of time, so they do not expect to have creative input into your product, market, or business model. The best contract experts ask for specific assignments and execute them on time and on budget. They are not responsible for setting up your long-term software stack, development cadence, recruiting practices, or code maintainability.

When working with a recruited team of contractors as a non-technical lead you must:

• Take on the responsibility of a product manager.
• Familiarize yourself with basic technical management and work item assignment using a Kanban tool like Jira, Trello, or a Notion Kanban board.
• Review and maintain accountability for deliverables daily.
• Maintain a record (in a spreadsheet, if that’s easier) of everything being worked on, responsible parties, and dates.
• Do not assume that your team members will be with you for the long run. Make sure all decisions and implementation are well documented.
• Consider hiring a senior full stack engineering contractor to serve as your technical lead and set best practices for everyone else who works on your code base.

With all early hires, insist on best practices maintaining a codebase and lightweight documentation 100% of the time. (This is very low effort for any qualified developer and will definitely save you trouble in the long run). Documentation can be as minimal as a 10-line readme, but all code structures should be broadly identified and project setup instructions should be up-to-date and easily manageable by virtually any developer that looks at them.

Sourcing and Recruiting

Recruiting Co-Founders and Full Time Engineers

There’s no perfect place to find the right engineer for your type of business, so the right answer here is more action: search anywhere and everywhere.

The obvious channels are your friends, former coworkers, investors, and advisers. Ability to recruit in a hot market is highly differentiating, so this is a good way to test your potential investors and advisers and their networks.

You should not ignore traditional channels like ZipRecruiter and similar aggregators, though expect to find a high volume of people there who are not comfortable working with startups.

Hacker News does an excellent job making monthly “who’s hiring” posts for both freelancers and permanent employees. Typically, local organizations run job boards that can be quite effective. Location agnostic marketplaces like Remote OK, We Work Remotely and others have steadily gained momentum as well.

LinkedIn remains a channel that requires a high volume of work for a low response rate, but it offers direct access to the talent pool. To reach out to a prospect on LinkedIn, use only highly personalized messages; do not copy-paste.

Twitter is a good place to follow engineers and potentially connect with people who might be like-minded; however, do not focus on pitching to them. Engage with thoughtful concepts and boost their ideas before you make a cold pitch.

Upwork is traditionally a source of contract skilled labor. It can be used as an excellent onboarding ramp where you hire people on a contract basis, evaluate them, and hire them directly long-term if the relationship is mutually beneficial.

Recruiting Contractors

Most software companies should use Upwork for their initial contract hiring outside of their network.

Competing talent marketplaces do exist: Fiverr for creative work, Envato Studio for CMS implementation, and Turing for skilled technical talent. Upwork has the largest talent base, the best vetting systems (if you use them effectively), and the broadest range of skill sets.

Role Selection

Consider the following framework when determining which role to recruit for:

Writing the Job Posting

The key to successfully attracting candidates and filtering well lies in specificity. While some postings focus on originality, specificity will come across as refreshing and original in its own right.

Instead of vague, generic offerings of excitement like “come join us to build the future of real estate,” say: “Help us build a product that will put 2 million people into new homes over the next two years.” The challenge here is to convey your own excitement about the product, a level of domain expertise, and traction all in the first sentence.

Keep your posting fresh because the volume is very high: Make sure to refresh the posting on each respective board as much as it’s allowed. Likewise, respond quickly, as people tend to focus on opportunities in bursts and engage over relatively short periods of time. The sooner you respond, the more likely you are to catch a candidate when they’re open to communicating with you. High responsiveness will also make you stand out to prospective candidates and communicate a level of the executional excellence that is typically a mark of high-performance teams.

Filtering and Vetting Candidates

If you’re hiring the first technical members of the startup, filter for a bias toward execution and avoid specialists of esoteric tech stacks.

If you’re setting down the path of building software internally, your first technical hire will determine your software stack. It is okay to let them drive that decision. However, avoid the hot technology of the day; stay with proven, widely available and commonly used stacks such as MEAN, Django/PostgreSQL, and the like.

Specializing later if you need to is always the wise move. If you specialize too early, you will find it difficult to recruit additional engineers and you will get stuck with problems that few people can help you with. If you haven’t considered every pro and con of the specialized option, you may also find yourself facing a rebuild into a more common platform in the near future.

When selecting candidates, look for ability to start and complete projects autonomously and quickly. This is a critical skill set for startups that, notably, is not nearly as critical in large companies. A resume full of impressive employers like Facebook and Google doesn’t guarantee the skillset of understanding vague requirements, being self-motivated and having a strong ability to prioritize.

Note that engineers who have done contract work are typically more used to this environment and may be more comfortable right off the bat. They do expect clear communication of requirements, clear timelines and should not be left to their own devices in key product decisions. If you’re building a team of contractors, you must take on the role of an effective product manager.

Interviewing Candidates

Traditionally, the stages of engineering interviews are:

1) Informational: The candidate talks to the recruiter and gains clarity on the position.

2) Behavioral: This is a general interview to see if the candidate will personally vibe with the organization.

3) Technical: Here, the focus is on the candidate’s general technical skill set

4) Team: The hiring group and team leader determine if they will want to work with the candidate.

In the early stages, this approach is too heavy and prone to both false positives and false negatives. The following playbook is a simplified version that can work well to filter for the qualities outlined in the above section:

Step 1: Compress the stages into “Experience” and “Skills.”

In the initial “experience” stages you’re looking to filter for someone’s general ability to deliver shippable code in a startup environment. This stage can be executed in a quick call or over email.

Step 2: Ask for specifics about previous projects.

First, ask people to precisely describe one project they recently worked on, telling you what exactly they did and what impact that made. A common question asked in interviews is: “Describe a problem you faced and how you solved it.” A stronger version of that question that avoids canned answers is: “Why were you successful in that project?” You can then dig into more details like: “How did you pick the technical stack? If you didn’t select it, how did you feel about it and how would you change it?”

You’re looking for specifics in the candidate’s answers, like:

• Which components did they build?
• Whom did they work with and how did they interface with those people (e.g. “I took raw PSD’s from designers and turned them into JSX templates.”)
• What timeframes did they operate in? (“We built it in a few months” versus “It took us a month to get the data schema from the clients, we turned around a basic Django app in a week, and then spent two more weeks to build the UX for a big client. I would have shipped straight to clients at that point because we would have gotten feedback faster and avoided a schema rebuild later.”
• Look for adaptable people who use nuanced comparatives and show an ability to compromise pragmatically to ship. “Vue is more elegant than React, but in our use case, performance was identical and we wanted to keep shipping views daily” is a good, balanced answer. “Vue is so good I would never use React again” is not.
  

Step 3: Assess skill fit.

At the bottom of the funnel, you should now have a small group of good candidates. Next, you will be looking to gauge the person’s ability to be immediately and continuously productive and, most importantly, ship work.

The single best way to do this is to work with someone directly on a small fixed-scope task (which must be paid for). You will need to design a task that:

• Closely mimics the ultimate work you want the hire to do
• Creates an opportunity for the person to pay attention to detail
• Is limited in time
• Leaves some things unanswered

The best candidates will ask a few questions, state some assumptions, complete the work quickly, and create a deliverable that satisfied the assignment.

Let’s go through an example: “Build a basic to-do list in Django where incomplete tasks are red and complete tasks are green.”

Key features of this assignment are:

• It’s product-oriented but rather open-ended.
• It can be done in a very short period of time, when well constrained.
• It creates opportunities to build from scratch or derive from popular templates.
• It can be done in multiple tech stacks.
• It creates options to focus on front-end or back-end.

Let’s dissect this. A basic “toy” to-do list should take a competent Django engineer a few hours to deploy. If they can’t, they won’t be a good candidate early on.

However, doing so will require them to proactively limit the scope of the task, identify the unknowns, state assumptions, and clarify. Which approach they take to do it will be hugely informative. Some people will choose to build first and ask questions later. Others will ask endless questions to uncover a painstakingly detailed spec. Some will focus on strong UX, while others will focus on solid backend schemas. This method of interviewing will give you an excellent look at the person's style, pace, communication, and other professional inclinations.

Compensation

Effective compensation plans take into account where you are as a company and the risk a person takes on with the job. You will find that the deeper one’s expertise, the more uniform the price is for their time globally.

Compensation for Contractors

Contract workers will expect to be paid in cash and will rarely accept equity, unless they know you very well and have extremely strong confidence in your business.

Here is a basic range of hourly prices for contract software development on Upwork as of early 2021:

$10/hour (East Asia/Southeast Asia) - Entry level software developer who is able to build a complete app, albeit not following best practices, and spends time at a low efficiency OR mid-level implementation engineer who can customize WordPress/Shopify themes with reasonable fidelity. Sufficient communication in English without technical subtlety.

$25/hour (East Asia/Eastern Europe/Southeast Asia/Africa) - Strong full stack engineer who can easily build basic apps or set up Wordpress/Shopify websites. Sufficient technical communication in English.

$50/hour (East Asia/Eastern Europe/Southeast Asia/Africa) - Senior-level full engineer who can build complex full stack applications and mobile applications while following best practices. Full professional English proficiency.

$120/hour (Globally) - Top 5-10% of engineering talent. Can lead development efforts with multiple engineers following industry-leading best practices, perform complex DevOps, and act in customer-facing capacity if needed, using strong verbal English.

$250/hour (Globally) - Top 1% technical experts in specific fields like AI, ML, and the like.

Compensation for Full Time Employees or Co-founders

Full time compensation data for the US and other major markets is widely available on AngelList. The bigger challenge is setting a competitive cash equity ratio. While there is no substitute for research specific to your field, this “rule of thumb” formula can help:

If a senior engineering leader joins your company as a co-founder with no cash compensation (prior to any funding) and stays with the company for a long period of growth (always with proper vesting), you can expect to give up approximately 20% of your company.

At the next stage, with pre-seed funding, you could offer a “stipend” of $48K per year with 10% equity.

From there, for each subsequent stage of your company’s development, you can roughly multiply the cash component by 1.5 and divide the equity component by 2.5 to get the bounds of a reasonable offer.

Again, these numbers are meant only as a sanity check that you’re in the right ballpark. (So for example, at Series B, you can expect to pay $162K and offer up to 0.64% equity for a senior engineering manager).

Sourcing and Recruiting

Distributed versus Local Teams

Reductively, the only definite reason to have a co-located team is if you need the physical space (e.g. a hardware lab).

There is a strong argument that collaboration in a physical space can foster innovation. This could be particularly important if you don’t know what the scalable version of your product will look like and you’re still aggressively experimenting. However, most software teams can employ communication best practices to be highly effective asynchronously. Distributed teams offer broad access to global talent and the ultimate team-building flexibility that can unblock productivity.

How Much Technical Debt to Take On

Technical debt can be loosely defined as the total amount of development time invested into new development efforts that you know should have been spent on things like improvement, maintenance, or scalability. (Think of it as adding a new wing to a store, while the old wing has a leaking roof and failing shelves. It may be justifiable with sales, but at some point the bill definitely comes due… unless you abandon the entire location).

The question is: Build for good or build to rebuild? How much technical debt should you take on early? The appropriate answer can depend on whether your market hypothesis is tested. Can you test it quickly by taking on a lot of technical debt?

If you can, take on 100% technical debt and don’t worry about it. Focus on testing fast. If your outcome is positive, you will be able to rebuild just as quickly. Remember that you cannot have any more technical debt than your total development time invested. So if you keep your iterations small, debt works in your favor. (Conversely, if you go deep in the red knowing it’s the wrong route, it really compounds).

Otherwise, if your hypothesis is proven and you see challenges ahead in your current setup, it’s usually well worth it to spend at least 10% of your time on paying off debt and setting up for scalability.

If you find this helpful, or have your own ideas you'd like to share, tweet us @MikeRaybman @HustleFundVC