6 Hours vs 6 Months: How to Build Apps Faster

Ken Yarmosh

Last updated Jul 23, 2019

Compared to their web counterparts, mobile apps often get a bad wrap with how long they take to get into the marketplace. The concern being that spending six or more months building a v1.0 is too long and too expensive, especially while trying to achieve product/market fit. Andrew Chen wrote about his concerns of six month development cycle times back in 2012. I was reminded about that when my former officemate David Smith recently showed how he shipped an app in six hours.

The apps we're hired to do can't be accomplished in six hours, but we're always looking to build apps faster at Savvy Apps because of similar concerns to Andrew's. For example, we recently shipped a podcasting app for The Cato Institute in about three months. The original version of Agenda was done in about a month. Even some of our more complex apps are often done in less than six months. So consider this post a sort of very delayed response to Andrew's post on how to build apps faster.

Get Aggressive with Ship Dates

Set a hard date when your app is going to be shipped to the app store(s). Over-communicate that this date cannot be missed under any circumstance. Then work backwards.

If you and your team understand the importance of this date, you'll be more diligent about understanding the effort involved to complete tasks. Everyone should then be more vocal about features that should be de-scoped or moved into a future release

Use Wireframes to Reduce Development Cycles

It's cheaper and faster to change a mockup than it is to rewrite code. That's why we begin our process with low-fidelity wireframes and iterate through those extensively before writing any significant UI-based code. There's no shortage of tools that can be used, but we still regularly turn to Balsamiq Mockups to help us with low-fidelity wireframes in particular.

While it may seem counterintuitive, this approach actually reduces the total amount of development time. By capturing more feedback upfront, you lessen the likelihood to have to rewrite a function or feature later. Taking even a small amount of time to map out user experience will essentially make each hour of development time more effective

Start with a Single Platform and Form Factor

As I've written about in the past, it's generally still faster to build iOS apps. It's also faster to start with a single form factor, typically the iPhone. To understand how to decide which platform to build for first, check out my extensive post on this topic.

Regardless of those selections though, the other reason it's best to start with a single platform and form factor again has to do with feedback and learning. Any newer app is going to change drastically. Wireframes will reduce but likely not eliminate the need to make any code-level changes. As feedback comes in from beta testing, trying to apply that to multiple platforms and form factors will exponentially increase development cycle times

Account for Wrong Estimates Upfront

Estimates. We love them. We hate them. We mostly hate them. But we need them. There's no timeline without estimates and yet here's something you may have never thought about: users of an app don't care how long it takes to make. They just want an app that does what it's supposed to do without making them think.

What that means is that when you're in beta and a common theme from testers is that they still don't know how to use “feature X,” you can tack on 20-30% more time to the ship date. That might not be a problem except that there are five other features to build in v1.0 and the hardest ones haven't even been started yet (more on that shortly).

The answer to this problem is not to pad estimates. Instead, know that estimates will be wrong. Then, cut features that may have initially been planned for the first release while not changing the v1.0 release date. This approach allows you to hone and polish what are hopefully your key differentiators. Being ruthless about cutting more features before development begins will reduce costly development cycles, especially for a feature that probably won't ship in v1.0 anyway

Attack Challenging Development Tasks Earlier

Identify the most challenging parts of an app, spike on them, then come back to them quickly. There's definitely some rationale behind getting momentum and shoring up the foundation of a codebase. There's less for continuing to punt on tasks because they're going to be harder or more challenging. Pushing those off will more likely result in a ship date being be missed or still met but with a buggier app.

Product managers should be particularly helpful here. If they're regularly interacting with their development team members and have estimates for all development tasks, they then should look to reduce riskier areas of the app by prioritizing these kinds of features earlier on in the process

Use a Backend-as-a-Service Provider

Embrace tools like Parse, Firebase, CloudKit, or Kinvey. Many of our customers are running on the first two. These Backend-as-a-Service providers (BaaS) are built to reduce the costs of backend development and running servers. They automatically scale as your app grows and make it easier to use logins from social networks, have user accounts, support push notifications, and have a solid analytics dashboard (depending on the provider).

Why these providers are so useful is that they let you focus on what's going to differentiate your app. Writing your own push server, for example, won't do that. If you get to the point of having tens or hundreds of millions of users, you'll likely have enough revenue or have raised capital to then invest into your own infrastructure and migrate your data to it

Integrate External Code Libraries

Like BaaS, pulling in code libraries will reduce the amount of code that needs to be written. At Savvy Apps, we have a growing set of our own libraries and code snippets, but we also have a standard set of community libraries we integrate into apps.

We also regularly give ourselves time to experiment with and test different libraries that perform the same function. This ensures that we're using libraries that are well-maintained and keeps us current about our choices. It's also worth noting that obviously only commercially-viable frameworks with the right licenses can be included in any code base

Work with a Proven App Team

This one might seem self-serving, but hang with me... it's not. Whether it's Savvy Apps or some other proven team, using an external resource who has an established process will almost always help get your app to market faster. In fact, I often say that we're paid because we can do quality work faster.

Even if you've raised enough money to build your own team, it will take some time for that team to develop chemistry and create their own process. Comparatively, the Savvy team has crafted hundreds of app experiences with a process that's vetted. You can use a firm like ours to jumpstart or bring a v1.0 app to market faster, then take that over in-house

Regularly Re-evaluate Estimates

Every Friday at Savvy Apps, we ask our development team members to:

  1. Ensure all tasks in their queue have an estimate.
  2. Carefully review the accuracy of estimates for next week and adjust them accordingly.
  3. Scan future tasks and similarly see if they need to be adjusted.

Our approach guarantees that we're never making decisions based on stale data. If we start to see a release slip, we can reprioritize tasks to stay on track. It also gives us all an opportunity to understand what we'll be working on in the coming week, which provides us a head start for Monday morning

Commit to a Minimum of Weekly Builds

Keeping to a regular build schedule is critical to staying honest on the release schedule. In the earlier phases of development, we start with weekly builds and put those builds in the hands of testers as early as 2-4 weeks into the development cycle. As we get closer to the ship date, we typically move to 2-3 builds per week and eventually may even do daily ones.

Actually having people waiting for a build is equally important to committing to weekly builds. Knowing that people will be testing and using the app provides motivation

Concluding Note

The astute reader probably realized that I showed only a handful of ways to actually build apps faster. That's because one of the ways to build apps faster is to not build them slower. If there's better product planning, ship dates won't slip because the scope is tight and schedules can be maintained. That is, most schedules don't start out as six or more months. They get to that point because there wasn't enough upfront or ongoing product management.

Written By:

Ken Yarmosh

Ken Yarmosh is the Founder & CEO of Savvy Apps. He's the creator of more than 20 featured apps, including an Editor's Choice selection and Starbucks Pick of the Week. An O'Reilly author, Ken regularly speaks about application design & development, as well as the future of technology at outlets ranging from Bloomberg TV to Google.