How startups outsource their tech without going broke or getting screwed

What most entrepreneurs don’t have is a technical background. Thus, most entrepreneurs are forced to rely on someone else to build out their tech. Not only that, most entrepreneurs are forced to trust someone else to build out their tech without charging them a fortune for shoddy work and layers of unnecessary billable hours.

Here’s how to make sure that doesn’t happen to you.

Trap #1: Don’t spend money you don’t have

Believe me, I’ve seen dozens of different ways for a $50K tech spend to evolve from “crazy idea” to “just might work,” whether it’s with credit cards, loans, friends and family, or the old standard of giving away 10% of the company to get an MVP built.

In fact, a couple of weeks ago, an entrepreneur asked me to review a proposal for $2.3M worth of tech build — before the entrepreneur’s startup was even incorporated. I was surprised, but not shocked, and a little mad at the tech firm, whom I did not know.

But ultimately, the fault was with the entrepreneur, in the sense that they asked for all the wrong things at the wrong time. When an entrepreneur has money or access to it, or they believe they do, that problem can wind up hurting a lot of people, including the firm that agrees to build the tech.

Trap #2: Don’t spend all the money you DO have

Very few technical firms are sketchy, but most of them will build what you ask them to build. Most. Some are even altruistic. I’m reminded of a conversation I had with one of my tech-firm-founder friends:

“I won’t take $50,000 from a startup if that’s all they have,” she said. “Because I’ll end up building beautiful tech for them and it’ll just sit there and do nothing because they don’t have money to spend on sales, marketing, even changes to the tech when they realize they’ve built something only half of their customers are using.”

Think about all of your funding as a budget. Your tech should never be more than 50% of that budget — and then — that 50% should include your original spend to build, plus the costs of maintaining, supporting, upgrading, even wholesale changes to that build once it comes into contact with your customers.

So your original spend to build should probably be something like 25% of your company budget.

How do you work under that tight constraint?

Trap #3: Don’t build everything at once

Most of the tech proposals I see are out-the-door pricing for the build of an entire product. Then usually the firm either walks away or tacks on a program to support exactly what they built.

This will get your startup to launch, but not much further.

You don’t need a full feature set, but you need to deliver value.

Most entrepreneurs design their product from beta all the way to version two and beyond. Me included. I design all kinds of infrastructure, administration, even reports and bells and whistles. This design is necessary, and the better-built products usually wind up coming from the better-designed products.

But even the best design doesn’t need to be built all at once. Not every feature needs to be live the first time the product gets put in front of the customer.

Without getting too much into Minimum Viable Product theory, what needs to be there is the bare minimum that gets the customer to experience the most value in the shortest time.

That’s usually a subset of the full product. And since almost all technical architecture is open and flexible these days, your technical resource doesn’t need to validate every future feature or process. They just need to know what’s coming and how it’s designed so they don’t wall off that future functionality.

You don’t need scale, but you need options.

Building for a million users when you have no users is like spending a million dollars when you have no revenue.

No matter how many customers you eventually plan to have, you don’t need to accommodate all of them out of the gate. Again, we’re at a place where most technical tools and coding strategies have the flexibility to expand built-in.

So much like open feature design, you need open scale design. In other words, your technical resource should be smart enough and forward-thinking enough to not do anything that would prevent scale down the road.

You don’t need to rebuild any wheels.

The reason why there are multiple no-code options for building apps these days is that a lot of code has been packaged into reusable and universal chunks. A lot of those chunks are offered by third parties, more robustly and inexpensively than anything you and your technical resource can build.

If there is a third party offering for some of your non-critical functionality, use that third party, at least temporarily. Focus your initial build on the technology that is critical for the customer finding value in your product.

Trap #4: Don’t look for a provider, look for a partner

Now that you’ve got your design broken up and prioritized, this is a golden opportunity to vet whatever firm or individual is going to build your tech.

• Do they understand how a startup should operate?
• Do they get that you’re going to spend in small increments, go away and test, and then come back with changes?
• Are they willing to take the risk of inconvenience to their billing cycle for the reward of your success?

You don’t need Agile, but you need to be agile.

The proposal I mentioned earlier was a series of a dozen two-week sprints, back-to-back, each for a different feature of the product. As is the case with Agile development, each two-week sprint would end with a review process that would trigger the next sprint.

This is where I got a little mad. What exactly did that tech firm imagine would happen in those reviews?

Actually, I knew the answer. The review would be a checklist with the entrepreneur to make sure the firm had built exactly what the entrepreneur asked for. This is for the tech firm to justify their next billing cycle.

But it doesn’t matter what the entrepreneur thinks of the tech. What matters is what the entrepreneur’s customers think of the tech. The entrepreneur needs time to validate this.

You need to manage the project.

Never, ever pay for a project manager or any other kind of administrator that comes from the firm itself. The firm’s job is to build what you want and get it done on time. If you don’t trust them to do that, and if you don’t trust yourself to be able to manage that, hire a third party to manage the firm.

Trap #5: Don’t go into the selection process uneducated

If you’re buying a new or used car, you don’t necessarily need to know mechanical and electrical engineering up and down. But you should know what undercoating is and whether or not you need it.

There are a million documents on the web that explain the technology and what it does. Most of them are boring and complicated, but some aren’t.

You should know, at a minimum:

• How cloud availability and SaaS works
• What a tech stack is and what some of the differences are from stack to stack
• The popular coding languages, databases, and backends and a little about why you’d choose what
• How security, privacy, and backups work.

You should always ask other entrepreneurs which firms they have used and why. You should always talk to the clients listed on the websites of the firms you’re considering.

Trap #6: Don’t pay by the hour

If you pay by the hour, you’ll always be questioning the firm’s methods, and whether you’re asking for something simple or complicated. You’ll subconsciously nickel-and-dime your product to death.

Pay by the project, or better yet, pay by functionality. If you’ve designed your product thoroughly, even if it’s just words on paper, they’ll be able to price it out. This means you’ll be able to prioritize functionality for your customers, and you’ll be able to come back and make the inevitable changes to functionality as the product hits the market.

Trap #7: Protect yourself

I get this question a lot — How do you prevent the firm from taking your idea and your tech and doing it themselves. The answer is: You can’t.

Make sure you’ve got an NDA in place with the firm, and make sure you own the source code and that you have unfettered access to it.

A startup succeeds on their execution, not the idea, not the tech, and not the implementation of that tech. If you really think the technical firm can out-execute you on your own idea, or if you think they’ll just sell your tech to someone else, don’t do business with them.

Like I said, there are plenty of good, altruistic tech firms out there.

This article was originally published on Medium by Joe Procopio

Joe Procopio is a multi-exit, multi-failure entrepreneur. He is currently the Chief Product Officer at Spiffy, on-demand vehicle care and maintenance startup. In 2015, he sold Automated Insights to Vista Equity Partners. In 2013, he sold ExitEvent to Capitol Broadcasting. Before that, he built Intrepid Media, the first social network for writers. You can read more and sign up for his newsletter at www.joeprocopio.com