Iowa Caucus App Failure and Lessons Learned

February 04, 2020

Tags: App Development, Best Practices, Business, Lessons Learned, Mobile Development

Earlier this week Iowa held the first primary in the 2020 US presidential election. What was supposed to be an organized process that reported results within a few hours ended with trickling reports of delays caused by mysterious ”coding issues” in an app designed to tally votes.

As the reporting further developed story, an interesting narrative emerged that I think provides some good lessons on app development. If you‘re thinking about building an app or are interested in the intersection of politics and technology, let this be a cautionary tale.

Budget Properly

One of the most eye-opening parts of the story—and the thing that jumped out at me first—has been the budget of the project, both in terms of finances and time. The New York Times reported that the Iowa Democratic Party paid the vendor $63,183 for the entire project and gave them ”less than two months” to roll it out. Neither of those numbers is right-sized.

Let‘s talk about finances first. ”How much does an app cost to build?” is a question I spend a lot of time with (and one that probably deserves an entire post unto itself). It goes without saying, but every project is different. We work a lot in healthcare which has different requirements than, say, a consumer-facing startup.

But given what we know about the scope of the project, the amount budgeted for the app wasn‘t nearly enough. We‘re talking about an app on both iOS and Android, with a server backend (for user accounts, data collection, and more), plus some integration into a centralized data warehouse. That budget should have been double, probably closer to $150–180,000.

As with anything in life, you get what you pay for. In this case, I would‘ve guessed the team had to cut a lot of corners, and indeed that seems like what they did, relying on more inexperienced talent to pull off a complex project, and foregoing standard testing and launch procedures.

In terms of the timeline, consider that you want at least a two week buffer to submit for review to the App Store and at least two weeks of concentrated testing (more on this later). Usually projects have a ramp up period for planning, so let‘s count another two weeks. That‘s already six of the eight weeks the team spent, leaving only two weeks for production work. That‘s barely enough time to get the coding environment, servers, etc set up! Likely, the team needed four months to properly build, test, and launch this app.

The result of not budgeting properly was a messy and chaotic rollout of a flawed product. Good apps aren‘t shipped on rushed schedules and shoestring budgets. The team never really had a chance of success, and that failure happened on day one.

Hire the Right Team

The New York Times reported that the vendor hired to produce the app had extensive connections to the national Democratic party. It‘s not clear how the company was selected, but I‘m guessing those connections had something to do with it.

In reality, this was a procurement failure, as the vendor lacked any relevant experience. According to a quote given to Bloomberg, the CEO said the company ”hadn‘t previously done election-related work”. The Times also reported that their engineers ”were relatively inexperienced”.

When hiring a team to build your app, you want both high-quality, experienced engineers as well as experience relevant to your needs. Industry-specific experience is always a plus as well.

Testing, Testing, Testing

Even with the right team and the right resources, rolling out a brand new system can go horribly awry without proper planning and testing. Modern-day apps are complex systems, and one seemingly small error can cascade and bring everything crashing down. By all reports, this is exactly what happened in Iowa.

The New York Times reported that not all of the caucus leaders had the app downloaded, probably because, according to Bloomberg, they were required to side-load the app—i.e., download it from somewhere other than the official App Stores. Side-loading is a convoluted process that most laypeople are unfamiliar with. Couple that with potentially flaky cellular service (we‘re talking about rural Iowa here) or unreliable Wi-Fi (municipal and community buildings aren‘t exactly known for great internet access) and you have disaster brewing.

Allow me to make an educated guess here: this app installation strategy was likely the byproduct of the team not having enough time to finish the build and submit the app to the App Stores before the caucus. It's also possible, given the team’s lack of prior experience, they just didn't know how to do that.

The result was a systemic failure: the backup hotline ended up taking the brunt of the traffic for reporting results, which it just wasn‘t designed to handle.

The upshot here is that you can easily avoid this type of catastrophic failure through careful planning. An app should be tested continuously, at every stage, both by the development team and by other stakeholders. Before it‘s submitted to an App Store, it should be beta tested under real-world physical conditions. Further, it should be finished at least two weeks before the due date to account for review time.

All of this encapsulates industry best practices. If you‘re planning to build an app, make sure you ask your product team about testing protocols and ensure they include a buffer before your delivery date for App Store review.

Don‘t Build an App

My first reaction when I heard there were issues with an app reporting results from the caucuses was: why is this an app? This might seem counter-intuitive as someone running an app development company, but I spend a fair amount of my time convincing people they actually don‘t need an app.

Why? First and foremost, I see us as consultants. We advise our clients on a whole host of issues outside of the technical components of building and launching an app—from designing the product to achieve desired outcomes, to optimizing revenue models, to organizing for fundraising.

So, in my capacity as a consultant, if you don‘t need an app, I‘ll tell you so. These days, a lot of concepts can be tested in the MVP stage without hiring a full product team. Which, if you can avoid it, you should since it‘s a significant investment, both in terms of time and money.

In this case, what was needed could‘ve been wired up with a lot of ”no code” products. You can collect the information in a Google Form (free!) or something like Airtable, then calculate in a Google Sheets or Airtable, and orchestrate with Zapier to send the results to whatever central database they need to be in.

If you don‘t have the time or budget to build an app properly, then don‘t. You‘ll just end up costing yourself both. Not sure if an app is right for you? Reach out and ask—we‘ll give you a straightforward answer.

Lessons Learned

If you‘re planning to build an app, here are the key lessons you can takeaway from the Iowa caucus failure:

  • Listen to your product team to make sure your budget, both in time and money, is right-sized.
  • Don‘t hire a team based on connections. Look for comparable experience and check resumes. Ask for and reach out to references.
  • Ask about testing protocols and make sure they match industry best practices. Ensure a buffer for App Store review.
  • Only build an app if you actually need to. Look into other alternatives.

If you‘re unsure about any of this, reach out to our expert product development team and we‘ll help you navigate the process!

Logan Leger

Founder & CEO

Founder. Engineer and entrepreneur. Husband and father. Writes in Ruby, Elixir, JavaScript, and Swift. he/him

let's talk.

Together we can make something great.

contact us about new work



Social Media