Your Contract Developers Are (Probably) Hosing You — Part 2, Preparing To Use A Contractor

This is part 2 of a series, “Your Contract Developer Is (Probably) Hosing You”, aimed at helping non-technical founders get their first product built. If you missed the beginning, start here.

Are You Ready?

The first question to ask, before you go looking for a contract developer, is whether you are properly prepared to use their time efficiently. If you aren’t, and you engage them, you’ll blow through your cash very fast and have nothing to show for it.

There is a bit of a fork in the road here. You can go to a full-service agency with only a general idea of what you want build, and some screen sketches on the back of a napkin. This won’t work at all with individual developers or overseas teams-for-hire, but an agency can typically provide UI/UX services to flesh out and prototype your plans before you start to build them. However this is a very expensive path, and I wouldn’t recommend it unless your pockets are deep.

M To The V To The P

As a founder, you’ve probably already heard a lot about getting to your MVP, the minimum viable product that will let you determine if you have product-market fit.

I would bias strongly in favor of waiting to engage engineering until you have a very clear plan of what you want them to build to achieve an MVP. The first step of that is to get brutally clear on what you think your initial product is. You are the one with the dream and the vision, so no one else can do that for you. You should be able to describe it in the proverbial elevator pitch. A sentence or two that summarizes the opportunity and paints a clear picture in anyone’s mind.

The next step is figure out what are the bare minimum features you would need to be able to release that product to an initial audience. To take our “Recommend Lladro figurine gifts based on a user’s tweets” example, it might be something like:

• A webpage with an input box where you can enter a Twitter handle; it should autocomplete to help them find the right person
• An account creation page; we’ll require an account before you get your recommendations so that we have your email address and can market to you.
• A system for scraping the Lladro website to ingest all of the catalog information.
• A machine learning system for reading the user’s tweets and displaying the best 3 figurines. This could use sentiment, style, keywords, similarity to other user’s choices, etc.
• The displayed figurines should include their description, and an affiliate link so we can make money from the sales
• There should be a share button so people can have fun with the recommendation. Like “@michaelnatkin LladroPicker says you’d like the puppy, the crying baby, and the diapered angels!” and include a link back to the results.
• A forum system that allows Lladro enthusiasts to discuss their favorite figurines
• A collection gallery where you can keep photos of your favorite figurines
• An auction system that integrates with the main recommendation page so we can act as a two-way marketplace, and recommend figurines that are for sale and collect a percentage instead of just the affiliate link.
• A computer vision system that can look at a picture of a figurine (either current or antique) and identify exactly what model it is, and what condition it is in and then show the approximate value

This is pretty good! You’ve identified an MVP.

See What I Did There?

Ok, if you think we’ve just identified an MVP, we really need to talk. That list has a whole bunch of features that are way beyond the original “Figurines based on tweets” plan. They might be fantastic features for your next several releases. Or they might be great ideas on their own. Or maybe once you wrote that list, you would decide that you actually want to do the marketplace features first.

Whatever you do, do not run off to a contractor with that whole list! It might seem like I’m exaggerating, but I’ve honestly seen a number of startups that begin with that much complexity. This is called “feature creep” and it is a mortal enemy of your wallet.

The Golden Triangle Of Destiny

Everything about software (like life!) is tradeoffs. And there are many kinds of tradeoffs, but the following one is so fundamental to software engineering that developers take it for granted. Yet it isn’t always obvious to non-engineers. There are three fundamental quantities that are at play on a software project, whether it is a one hour hack or a five year mission to conquer the galaxy:

• Time (equals Your Money!)
• Features
• Quality

If you want more features, it will either take longer (and cost you more money), or they will have to be done at lower quality. If you want to ship high quality software without horribly embarrassing bugs, it will take time and you’ll need to ship fewer features. This law is as immutable as gravitation. If someone tells you different, show them the door.

So, pop quiz, what do we need to do with that feature list above? That’s right, cadet, we need to be disciplined. Now, killing your favorite features is painful. So here’s the trick. Don’t kill them. Prioritize them. Put everything in the right order, then take the ones you don’t need for version 1, write them down somewhere secret, and forget about them for now. Or better yet, when the time comes, discuss them with your developers as future directions so that they can architect in a way that doesn’t preclude them. But DO NOT start building them.

For our example above, I’d probably start with:

• A webpage with an input box where you can enter a twitter handle; it should autocomplete to help them find the right person
• A system for scraping the Llladro website to ingest all of the catalog information.
• A machine learning system for reading their tweets and displaying the best 3 figurines. This could use sentiment, style, keywords, similarity to other user’s choices, etc.
• The displayed figurines should include their description, and an affiliate link so we can make money from the sales
• There should be a share button so people can have fun with the recommendation. Like “@michaelnatkin LladroPicker says you’d like the puppy, the crying baby, and the diapered angels!” and include a link back to the results.

Still Kidding

You can still make a radical and effective simplification here. Get rid of the ingestion system and the fancy machine learning algorithm. Manually enter the top 20 figurines. Let the user still enter a Twitter handle, but ignore the tweets and just randomly offer 3 of the top 20.

Why would I do this? Am I not killing the entire core of the beautiful LladroMatcher idea? Nope. This will be plenty good enough to determine whether the idea has any value at all. In fact, I’ve made it so simple that a single good developer could build it very quickly. I could then take all the money I’ve saved and use it to run social media ads to try and drive people to it, and measure whether I’m getting any visits, clicks, and sales.

If it isn’t converting at all, than most likely this just isn’t a great idea and I should move on. Or, if I want to double down, I can decide what my next experiment or improvement should be and try again.

If it is converting at a rate where I think there is a possibility of a real business here, then by all means I can invest in the machine learning to optimize conversion, along with all of those other features I was dreaming of. In fact, we’ve preserved the optionality of deciding that one of those should come before machine learning.

And one more thing: you’ve gotten a cheap look at the contractor you used! If the project is going well, and you’ve enjoyed working with them, you can give them the next set of features. If it succeeded in spite of them, and it has been frustrating, you can pack up your tent and look for greener pastures.

One More Step

Unless you are going to a full service agency, there is one more thing you need to do before hiring your engineers. You need a UI design. Design is the great non-linear variable in the success of software projects. I’ve seen this throughout my career. If you let an engineer just take your idea and translate it literally into whatever kids of screens, buttons, sliders, text inputs, etc. seem like the most obvious mapping, you will end up with something that looks and works like an engineer designed it — bland and literal. Even if they use a modern UI toolkit that provides decent baseline appearance and interaction, it will probably suck. A good designer will take your concept and both simplify it and make it sing, providing that element of delight that will encourage users to come back and to share it with their community.

For a small scale project, it is probably reasonable to use a freelance UI/UX designer that you can find on, say, Upwork. Look carefully at portfolios and ask questions about their approach. Even if the results they produce are imperfect, it will be better than what you or your engineers will do, and you can always go for a fancier version in v2. Work with that designer and your list of features to nail down a logo (if needed), colors, typography, and the basic screens (both desktop and mobile if appropriate). Iterate until you are satisfied, keeping in mind that this upfront work will save you lots of time and money once coding begins.

With those design deliverables in hand, you are ready to choose an engineering contractor and negotiate with them, which will be the subject of Part 3 — Choosing A Contractor.

Reminder: This is part 2 of a series, “Your Contract Developer Is (Probably) Hosing You”. If you missed the beginning, start here, or continue to part 3.

About Michael: I’m a senior technical leader and startup CTO based in Seattle Washington. I’ve built everything from dinosaurs to sous vide cookers. I’m looking for my next role.