Keeping costs down: controlling labor costs
In part 1 of keeping costs down we talked about staying focused in what you build, and being flexible in how you build it. Now we’re going to talk about how, given a fixed quantity of work, you can manage your labor costs. You do this by controlling four primary things:
- Which roles you have on the team at what stages of the project.
- The technology you use to build your app.
- The countries your team members live in.
- And the experience level of the people you hire.
In this video I’ll discuss how to be smart about that, so you’re using your resources efficiently.
Roles
A typical apps team consists of designers, maybe a project manager, testers, and engineers. In a typical app lifecycle, you don’t need all these people all the time. Let’s talk about when each role is needed.
Design
Designers are mostly needed at the start of a project, then their contributions become more scattered as the project matures. So if your team is small and you don’t have much design work beyond your app, this is a good place to make a temporary hire like a contractor rather than going full time. Designers often like doing different projects for different companies because it scratches their creative itch, so this is a group where you can often find quality work just for the time you need it.
Project management
Having a project manager in a dedicated role is optional for a lot of projects, but the work they do is not - you need someone to keep track of what’s left to do and organize its execution, and having someone experienced step in at the right moments is useful and less expensive than if a senior engineer has to fill that role instead.
At my firm we tend to include a project manager at the very start of the project to help with estimation work and planning, then we bring their time down to near zero until we hit about the two thirds mark in the project. The reason for this is that in that 10% done to 70% done phase of the project, there’s usually so much to do that we don’t need a lot of direction or structure to make progress, we just need to put our heads down and work. As the project nears completion, that’s when prioritizing and organizing all the last little pieces of the puzzle becomes really valuable.
Testing
In the app world Quality Assurance, or QA is an important role, and it’s good to start them at about the 60% complete mark onwards. You don’t need them right away because there isn’t much to test at the start and usually they’ll just clog your system with bug reports because it’s so early.
Engineers
And finally, there’s engineering. This is the bulk of your cost and the need for it is consistent. The biggest spikes in engineering hours are typically close to deadlines and shortly after launch, but you should expect a consistent burn rate for as long as you have something that needs building.
So engineers are needed throughout the project, but some charge less than others. What they charge depends on our other three factors - technology, location and experience. Let’s talk about technology choices.
Technologies
There are three primary technical approaches to building your app:
The conventional, native way.
This means engineers who write Swift for iOS, and people who write Kotlin for Android. This gives you the most polished product, it’s the most flexible and future proof approach, but it’s slower early on if you need to get to both platforms right out the gate and the engineers have the highest rates. Because of this a lot of startups build their first version on iOS and do Android later.
Building for web.
This usually means JavaScript and HTML developers. Websites are the most versatile way to deliver value to your users, they work across all devices not just phones, and the developers are the cheapest to hire. They can be accessed without needing to download an app, but access to phone hardware like the camera is harder, you can’t do push notifications, and you’re much more limited in terms of processing capabilities. This means your level of polish is low, and you probably have an intuitive sense of how an app feels vs a website. Apps are just a bit slicker and more polished, you’re more likely to come back to them again and again.
Building with a hybrid framework, like React Native or Flutter.
These can get you a long way quickly early on because most of the functionality can be built once and deployed to iOS and Android at the same time. React Native uses JavaScript, and those developers are cheaper, although Flutter has its own language called Dart and those engineers are harder to find. As your project matures these hybrid frameworks tend to become more onerous and complicated to maintain. I’ve seen several projects in my career that had to be thrown out entirely and restarted because these technologies just have a limit of what they can do. But if your app is well understood, and doesn’t need to be a really polished consumer experience these can be a great way to save money and achieve your goals.
So: web is cheaper than hybrid, hybrid is cheaper than native, there are trade offs with each one.
Domestic vs off shore
Next: where are your engineers?
These days, especially in the post-covid world, remote teams are becoming kind of normal. And this gives founders a good opportunity to find strong people off shore for less money than they’d pay in the US. The trade off you’re usually making here is with the time zone, and with cultural and communication barriers, and those barriers matter more at the product definition and business goals levels, and less at the hard technical level where it’s just simpler to see when something works well or not.
At Zurgerberg we have a mix of people based in the US and based in other countries like the Netherlands and Ukraine, where hourly rates are lower. What I find works well is to have our project management and design be based in the US where our clients are so we can translate the business goals with maximum clarity, and then we usually have a mix of nationalities at a technical level, usually leadership is US based and many of the others are elsewhere. It’s not necessarily important to have leadership be US based, but the strongest technology companies in the world are in the US, so if you’re really looking for top tier talent, in my opinion, here is where you find it. You just have to be ready to pay for it.
One role that is great to have offshore is testing your apps, because it means your team submits their work at the end of the day, it gets tested overnight on an opposite timezone, and you all wake up with the results in the morning. It works great.
OK, we’ve covered how to build the app, where to build it, now finally: how experienced does your team need to be?
This is a whole topic in and of itself but your general take home should be this: the lower the experience level, the cheaper the build, and the higher the risk. If your app is very simple and well defined, won’t change much after the build, and is not a core part of your business, then even the highest levels of risk aren’t that high. You can go with a less experienced team if funds are an issue. If your app is a critical part of your business goals, or the work will be ongoing for a long period, then the risk level matters, and you should seek out a more experienced team.
