Zero to coder

Kurt McIntire

11.09.2013

2014 Update: Though FixMyCity was shutdown in 2014, this article shares my favorite recommendations for building your first app-based startup and learning how to code.

My co-founder, Matt Holmboe, and I are proud to announce our newest app, FixMyCity, is now available for free on the App Store. This app is the reason we started developing mobile applications, and is something we’re very proud to finally release. In this post, we’ll explore our journey in making this app a reality and look back at our lessons learned.

For those who haven’t heard, FixMyCity let’s citizens submit requests to their cities for non-emergency issues like potholes, blocked storm drains, graffiti, and ADA non-compliances. If you see an annoying piece of graffiti in your neighborhood, you simply pull out FixMyCity, snap a picture, and submit your request in 10 seconds.

This Is Why We Learned to Code

FixMyCity was our first serious idea, but neither of us knew how to code. As trained civil engineers, we both have a passion for cities, how they work, and how to make them work better. Building FixMyCity was a huge challenge, because we were starting from scratch. To help us build our app, we purchased Macs, iPhones, and tutorial books. From there we got to work, learning Objective-C, Xcode, databases and a whole dictionary worth of programming jargon. On the way we figured how to make websites, web back-ends and learned how create graphic artwork using Adobe Photoshop and Illustrator.

Harder Than We Thought

Looking back, we were incredibly naive. We thought that FixMyCity was a simple enough concept that we’d finish it in three months from the start of our journey. I remember getting this far and thinking, “Wow, we’re almost done!”

Almost done? Yeah right!

We couldn’t have been more wrong. FixMyCity is complex. The app has user accounts, passwords, password recoveries, images handling, mapping data, and interacts heavily with a database. All of these features might be par for the course for experienced app developers, but are easily taken for granted by non-programmers. After three months of spinning our wheels, we realized that FixMyCity was too big for our skill sets. We decided to focus on building smaller apps and working though books so we could to ramp up our skills without becoming overwhelmed.

Trying to Turn Things Around

The best move we made was committing to each other that we’d complete one chapter a day of the Big Nerd Ranch Guide for iOS. We set up an online list where we kept track of our progress, which turned out to be surprisingly motivating. If Matt worked a few chapters ahead of me, I’d see it on our list and feel guilty. That weekend, I’d power through additional chapters to make sure we were in the same place. After 30 days and 30 chapters, our confidence was boosted and felt ready to re-tackle FixMyCity.

Wait, We Have to Learn Another Programming Language?

As FixMyCity began to take shape, we realized that it needed to work with a database. Essentially, we needed a place to store information that users posted while using the app. We thought that knowing Objective-C would be enough to handle all of these operations. Again, we were wrong. To build the database with the functionality we needed, we needed to build it using a completely different programming language called PHP. After months of struggling to learn the programming language for iPhones, the prospect of learning another language was out of the question.

Fortunately for us, there are a good number of services available to make the process of building a database easier. For a monthly fee, they allow you to build a fully functional database without having to learn PHP. We evaluated a couple of them and settled on Parse. Within minutes we were creating databases, and after a few weeks, FixMyCity interacted beautifully with a database.

With FixMyCity’s current user base, we don’t pay anything to Parse. However, as our users increase and the data we store in our database increases, we’ll have to start paying monthly to keep Parse. Some criticize us for this decision and say that using a free tool like PHP is the better option. We disagree. Shipping an app is hard. It’s so easy to lose momentum, give up, and never release the app. For us, anything we can do to bring us closer to our release date is a good move.

Taking FMC to the Streets

Once we had a functional prototype of FixMyCity ready to show to cities, we started setting up meetings and phone calls. We spoke to over 30 cities to gather information on what they currently use for managing non-emergency requests. Most cities we spoke with use phone hotlines, paper forms and city employee email addresses. A few of the more progressive cities we spoke to have online forms, and an even small number utilize mobile apps.

We heard from many cities that they like the idea of a mobile app, but were concerned it would be too complicated. They didn’t want to spend more time than they already were handling citizen “complaints”. We realized, to solve this problem, we needed to make FixMyCity easier for citizens and cities to use, while providing maximum value to cities. Using this new knowledge, we iterated, boiling down the feature set to the core essentials and focusing our attention on improving the app usability and functionality.

I wish we had had these conversations earlier in FixMyCity’s development. Our iterations and changes to FixMyCity were time consuming and required us to re-write a lot of code. If we had spoke with our users/customers earlier in the game, we would have saved a ton of time.

Lessons Learned from Building FixMyCity

Looking back, we’ve come a long way. We went from struggling to understand basic code to building a fully functioning custom app we are excited to release to the public. To wrap up our journey, let’s review our lessons learned and take a look at these images of FixMyCity’s main user interface over time .

Learning to build apps is not easy. It’s going to take more than 3 months, and it’s going to take a lot of work.

Set a daily routine for learning. Keep momentum.
Commit to daily progress with a learning partner. Keep momentum.
Outsource whatever you can. You don’t have enough brain power to do everything.
Speak to your potential users as soon as possible. Rewriting code wastes precious time.