Outsourcing Version 1: Advice from a CTO

No offense to software contractors, but given the choice I usually prefer to build software with hired employees. By signing on as employees, engineers demonstrate belief in the mission and commitment to the long-term success of the company. Often I can further align their interests with the company’s through equity as well as the opportunity to “grow with the company” in responsibility.

On the other hand, I’ve been building software for over 30 years and managing software developers for 25.

If you’re a non- (or not very) technical startup founder and need to build software, your needs may be better met by a software contractor. Compared to a permanent hire, advantages of contracting out your software development include on-demand resources; minimal overhead costs (benefits, equity, etc.); and flexibility in matching the scope of your resources to your project, making it easier to adjust your “team” as your needs change.

These are advantages whether you’re managing your first software project or your tenth.

The truth is, I’ve delivered many software projects staffed partially or entirely by contractors. I’ve sourced contractors through my professional network, Upwork, regular job boards, corporate recruiting departments, Slack channel conversations — you name it. Previously I wrote about taking delivery of your V1 software from a contractor. Here I lay out how I look at the entire software contracting process, starting from the beginning. Taking delivery is the third step: first come selecting, then working with, an outsourced software contractor.

​Selecting an Outsourced Software Contractor

Finding the right contractor is not always easy for me and can be downright daunting if you’ve never done it before. At a high level, here are my decision factors:

Individual vs Firm

This is decision one: hire an individual coder or work with a contracting firm. Again, what works well for me may not be best for you. With less overhead than a firm, individual contractors can often offer their services at lower cost, and you are dealing directly with the individual doing the work. I’m comfortable managing software developers, so that works well for me. But a contracting firm offers advantages over an individual that may make sense for a non-technical executive:

• Most software development projects require diverse skill-sets, such as design, front-end development, or back-end development, that are hard to find with equally high competence in one individual. A firm’s team may include specialists in the skills most valuable for your project.
• If you lack experience in technical project management, or just don’t have the time, a firm can fill that gap for you.
• Many contracting firms combine offshore (read: cheaper) engineers with onshore, English-speaking management.

Experience with your kind of project

To evaluate a contractor’s experience with your kind of software project, you need a concept of what “kinds” of software there are, which may not be obvious if you’re relatively new to software development. Here’s how I break it down, again keeping it high level:

Looks Good vs Works Good
These are not mutually exclusive. But the skills needed to ace a corporate website are far different from those needed to build, say, a FinTech (financial technology) service.

If your software is more like a corporate website, with primarily static content that needs to look good (e.g. “professional”, “eye-catching”), you should be looking for a contractor with design expertise. Your project might benefit from a UI specialist up front.

On other end of this spectrum, when developing an app or website with complex functionality, the most important thing (and hardest to get right) is that the software works. I’m not saying looks don’t matter, but if your FinTech platform is being built a contractor whose primary experience is building beautiful websites, be prepared to receive a beautiful application with bugs, scaling issues, or other functional problems.

Look for a contractor whose experience matches where your project falls on the looks-good/works-good spectrum. If both are equally important in your project, both are equally important in (choosing) your contractor.

Consumer vs Enterprise
Serving different audiences, consumer and enterprise software are generally built with similar technologies requiring similar technical skillsets. Where they differ is in the product context that determines the requirements for the software. Here are my notes on the product context I associate with these types of software, that I look for in a contractor’s experience base:​

• Consumer — Typically an emphasis on landing page, user on-boarding, ease-of-use, visual appeal.
• Enterprise — Often purchased by a small group of people who are not necessarily the end-users. Needs to “check the boxes” of the features important to these decision makers. UI less important. Might need to satisfy industry regulations or operational Service Level Agreements (SLAs).

Once again, look for a contractor with matching experience.

Lifecycle Pricing

When I’m budgeting a software project I think about the entire software lifecycle, my version of which I list below. Whether your software contract covers all of these steps or (most likely) just some of them, you should be thinking about how all of these steps get done, by whom, and how much they will ultimately cost:

1. Design. Software design is a specialty (actually multiple specialties, including graphical design, UI, and User Experience (UX)). Most software developers are not design specialists (even “front end” developers). So you’re likely to need a design specialist early in the process, or to accept a look-and-feel that is whatever you and your contractor come up with (read: amateur).
2. Development. This may be only thing you thought you needed from your software contractor. I hope by the time you finish reading this article you no longer think that. :-)
3. QA. Quality Assurance (testing) is another skillset at which many developers are not expert. Ask your contractor how they test their software; a good answer should include a description of a multi-tier process. What happens [i̶f̶] when you find a bug in the software after you’ve taken delivery?
4. You changed your mind. Every day you learn more about your business, your audience, and your evolving product. It’s not only inevitable that over time you’ll want to refine your original product idea, it’s rational. Can your contracting arrangement accommodate changes? If not, when is your first opportunity to act on your better-informed product ideas, and what’s the process for making those changes?
5. Launch, Monitor, Maintain and 6. Version 1.1, 1.2… While these two phases come after delivery of version 1 (which is why I’m lumping them together), you should be thinking from the start about how to resource follow-on work to manage and update your software. You can use the possibility of follow-on work to motivate high performance in your contractor now.

Check References

When I hire a contractor for the first time, I take one of two tacks:

1. Start with an engagement small enough in scope/risk that failure, while disappointing, isn’t devastating. In this scenario I become my own reference for a larger follow-on engagement.
2. Check references. If “failure is not an option”, I consider this essential.

I have found that references for a contractor will often share more information than references for a full-time hire. Maybe the stakes (or liability) seem lower. I try to make reference checks cordial and conversational. I’ve certainly learned things in those conversations I never would have picked up just looking at the contractor’s online profile or portfolio. A couple of tips for checking a contractor’s references:

• Talk to clients with similar kinds of software projects. Similar “kinds” as in looks good vs works good, consumer vs. enterprise (remember? :-).
• Every non-trivial software project has problems. (That’s worth repeating: Every non-trivial software project has problems.) During my conversation with a reference I pretty much say that and ask the reference to describe how the contractor handled the problems that did arise.

Working With Your Contractor

​Before I describe this chart, let me first describe what I left off the chart. I omitted the easiest, least time-consuming, least intimidating mode of working with your software contractor: write a check, cross your fingers, and hope the final delivery’s good. It’s the equivalent of a Hail Mary pass and about as likely to succeed.

WIP: Reviewed

At a bare minimum, for any software project lasting more than a week or two, you should review your work-in-progress (WIP) software regularly during development, wearing your product manager hat. Have your contractor demo whatever they can. This kind of product review doesn’t require any technical knowledge on your part but does accomplish a couple of things:

• It serves as a forcing function to keep your contractor focused on your project.
• It gives you an opportunity to course-correct your contractor to keep both the schedule, and the direction your software is taking, on track.

WIP: Delivered

Better than regular product reviews are regular deliveries of work-in-progress, even if you don’t do anything with them. Here’s what this accomplishes:

• Keeps your contractor honest, Part I: Your contractor doesn’t have to know that your team doesn’t include anybody who knows the difference between JavaScript and a Starbucks latte order. They just know, to anybody who is technical, their progress or lack thereof will be clear from one code delivery to the next.
• Keeps your contractor honest, Part II: If your contractor loses interest, has a major life event, demands more money, or just simply “ghosts” you, would you rather have in your possession something or nothing?
• Taking the first delivery of your software happens once. For the remaining lifetime of your company, software deliveries will be updates to the software you already have. Your real software development process will be a software update process. You want your team (which for now is you and your contractor) to adopt and work the kinks out of your “real” delivery process, the sooner the better.

See below for more about taking delivery of software.

WIP: Audited

Better still than regular deliveries of work-in-progress are audits of work-in-progress: a hands-on examination of the software by an expert. This can include reviewing the software’s organization and readability and examining the technical decisions implicit in it. Findings from such an audit validate your contractor’s work in a more substantial way, giving you reassurance you’re receiving quality work (and an opportunity to provide constructive feedback if not). Another set of eyes on any technical work almost always improves the quality of the final result.

A technical audit of your software is the only step that requires a technical friend, advisor, or consultant (like me) who is not your contractor. Assuming your in-house team is not technical, for this step you will need to find such a resource.

WIP: Piloted

The ideal way to treat your in-progress Version 1 is to launch early versions as a pilot, collect real customer feedback, and use that feedback to inform the product definition of the remaining development.

Practically speaking this may be aspirational (as in not do-able) for some startups. Your product may require complete core functionality for customers to be able to use it. Your contract may not allow for changes to definition without incurring significant expense. But what’s the expense involved in launching a Version 1 that’s too far off the mark? Consider whether there’s a 70% version of your Version 1 that you could put in front of users.

In my opinion the best software contracts include the flexibility to build even Version 1 software in multiple phases, allowing you to pilot intermediate versions and refine product definition based on real user feedback.

Taking Delivery of V1

The first time you hire somebody to develop software for you, delivery of the completed software feels like the finish line. In actuality, there’s only one scenario in which that’s true: when your company goes out of business right after you launch.

Assuming that’s not your goal, Version 1 is the start of what will hopefully be long-term software ownership. That includes adapting the software to your evolving understanding of what your customers want, and simply keeping the software running smoothly through operational glitches, variations in user load, and external changes to infrastructure like your cloud platform. (For instance, Amazon AWS, the most popular cloud services platform, frequently updates their services and unofficially or officially deprecates old ones.)

I recommend you take physical delivery of your software like a long-term owner-operator, even if your initial plan is for your contractor to continue to run it for you. These are the two things you should ensure are included in your contract software delivery:

1. Every software artifact necessary for anybody (not just your contractor) to maintain, build, and deploy your software from scratch. This includes source code and other digital assets. such as images; it might also include third-party software libraries and licenses.
2. Documentation sufficient for any engineer familiar with your software stack (the languages, frameworks, and other technologies employed by your contractor) to build and deploy your specific software application.

I hear some version of “I’m about to take delivery of Version 1, what do I do now” as frequently as any other question I hear from non-technical founders. So I previously posted more about this all-important phase in the software contracting lifecycle.

Don’t wait for delivery of Version 1 to start observing the best practices of successful software companies. Be diligent in your search and selection of a software contractor (even if you’re a small account). Structure your delivery into intermediate steps that you can leverage. Assume you and your software will be around for a long time, and act accordingly.

Originally published at www.greenbarlc.com.