Keeping costs down: 4 tips for building efficiently

Technology

The cost of building an app is 99% labor. So that means that what you’ll pay is a function of the quantity of labor required to build your app, multiplied by the price of the labor that you need. This gives you two primary controls over price: what are you building, and who will you hire to build it. In part 1 today we’re going to look at how to be efficient with what you build, and in the next video we’ll talk about how to be efficient with who you hire. Let’s start with the what.

Tip 1: Know when to start

One of the simplest ways to spend efficiently is not starting the build until you’re ready. There are usually cheaper ways to validate your ideas than building a whole app. So taking more time to really understand the problem you’re trying to solve, running your proposed solution by people you trust, building prototypes that fake the functionality for people to try out, these are good ways to make sure that when it comes time to build you have a clear idea of where you’re headed.

Tip 2: Stay focused

If you’re trying to keep costs low, it’s important to stay really focused on what you’re trying to achieve, and validate your ideas early.

There are two sides to this discipline - one is that when you’re half way through a project, resist the urge to add to the work. If everything was finished other than your shiny new idea, would you delay the launch? If not, stay focused, do it later.

Tip 3: Don’t reinvent the wheel

In past videos we’ve looked at software projects as a tower of blocks, with each block being something your engineers have to build, aiming towards a target in the sky. But here’s a trick: all over the internet, there are blocks of software that other people have written, that you can use for free. You don’t need to write a payments system, or even a credit card entry form any more. It’s a choice to write a login process these days when big tech companies have ones you can take off the shelf with minimal work involved.

Because there are so many blocks out there in the world, what you spend is more a function of the amount of custom, bespoke engineering work you do, and it is less correlated with the quantity of code or functionality that exists in the app.

What this means is don’t be scared of functionality that feels complex so long as it can be found elsewhere. For example imagine a ride sharing app where a passenger pays a fee and your company takes a cut before paying the driver. These days managing those payments, commissions, and payouts isn’t hard, unless you need to tweak it in some uncommon way. Maybe your ride sharing app is only for cross border ride sharing and needs to support multiple currencies. If there isn’t a multi-currency marketplace service available to you, well now you have to build it, and now you’ve gone from 60-80 hours of time implementing an existing system, to a million dollar project building a marketplace system from scratch. And obviously these inefficiencies exist on much smaller scales too.

So control your costs by using premade blocks where you can, and only build custom functionality when there’s a clear reason why it’s going to elevate your business.

If you’re a non-technical founder, you might be wondering how you can even make those distinctions, and it’s mostly up to your engineers to make the call about the quality of existing third party code and whether it fits your needs. So here’s the trick: keep your needs as high level and general as you can, and when you express what you want from your apps team make sure they know where your priorities lie in terms of cost vs meeting your requirements exactly. And ask them to seek out efficiencies that will reduce the labor involved, even if it means making changes to what is being built. If they think they don’t have any flexibility, and everything has to be built in a very particular way, that’s going to lead to a lot of custom code.

Tip 4: Budget for after launch

One last thing: make sure you reserve some of your budget for post launch. Once people start using the app, they’re going to use it in ways nobody else does, they’re going to discover bugs, and there will be some ongoing development costs that are inevitable. So don’t spend all your production budget just getting to launch, try to have at least 20% of your budget still available to handle post-launch issues.

OK so to summarize:

• Stay focused
• Optimize for minimal custom work
• Budget for after launch

In Keeping Costs Down part 2, we’re going to talk about controls you have over the cost of your team. There are four primary ways to manage that - who works when, the technology choices that inform your engineering hires, the countries where your team members live, and the experience levels of your team. I’ll see you there.