How We Built an iOS App, an Android App and a Node.js API in 20 Hours

My typical app development workflow involves brainstorming, idea formation, validation, feature selection, design iteration and eventually, development, a chain of events that usually takes atleast a month.

This time around, we decided to go from idea to app within a day!

In this post, I’d like to describe to you how my team of three built an iPhone and an Android app in 20 hours, both supported by a common Node.js back-end.  Aside from documenting our experiences, I hope this post serves as impetus for those who have been mulling over their app related ideas for long periods of time but have yet to get serious development work under their belts. If you’re not interested in the nitty-gritties, skip ahead to the key takeaways listed at the very end of the page.

Before I get started, I would also like to point out that this is in no way a challenge to articles that have recently been doing the rounds describing the time and cost challenge of building apps. The apps that we built in these 20 hours were rich in features, but their design, security and robustness was far from release quality.

Timeline: The Making of Vigilance

Hours 0 to 2

It was 1.00 PM on a Sunday afternoon when I, @govind201, met with @satyamag, @vinothgopi. Prior to meeting, we had vaguely discussed building an iOS app capable of helping people avoid becoming victims of crime. Having been victims of assault and vandalism ourselves, we wanted to built a warning system to notify people when they accidentally wander into areas of high crime.

Eventually, we decided that “Vigilance” would monitor its user’s location, display its estimation of levels of danger at that location and list the most common crimes in the area. Thus, the user would be able to gauge his or her exposure to everything from car vandalism to physical assault. By means of the heatmap of crime reports provided, augmented with clickable pins, the user would also be able to temper his or her perceptions by manually analysing the reports.

By the end of the first two hours, we’d listed all the features that we wanted and made sure that we were all on the same page.

Hours 2 to 5

Two of us began by searching for raw data to gather off of the web. It took us about an hour to identify a couple of sources of data. These sources included reports of arson, robbery, assault, vandalism and sexual offences. Using Semantics3’s web crawlers, we were able to get hold of the data within a half hour, after which we spent a further half hour cleaning up the data and porting it to SQL. We decided to focus on California at first, since the goal for the day was to get a working product up and running, as opposed to being thorough.

In the meanwhile, @satyamag got underway with getting the basic infrastructure of the iOS app up and I got started on the API.

Hours 5 to 9

The API was to receive latitude and longitude coordinates from the app and return an estimate of the “danger level” at that location, the “confidence” in this estimation and a throttled list of the raw data that underlies these estimations.

It took me a few hours to get a basic server up with Restify and Sequelize, a MySQL ORM. Ensuring that the code retained asynchronous calls took a further couple of hours.

In the meantime, @vinothgopi had implemented an algorithm in JavaScript that took into account location and nature of each of the crimes as well as metadata regarding the data including the date and time at which the crime occurred.

By then, @satyamag had gotten a good chunk of the app up including polling the GPS at regular intervals and design for the page that was to display crime stats and details. The app was able to communicate with a mock static API that we’d set up for test purposes.

Hours 9 to 14

At all times, we were keen on ensuring that we did not fill in gaps with temporary hacks. We could have gotten geosearch in place through an on-the-go Haversian distance function embedded in a SQL query, but clearly, this would not be scalable in the long-run. Hence we looked to Sphinx search and after hours of struggling with Limestone, the only available Node-Sphinx connector, we got Sphinx geosearch to work. (Geo-search supported Limestone code to be up soon, since the current version does not provide adequate support).

In the meanwhile, @vinothgopi worked on merging data from multiple sources together, notably, combining data regarding sexual offences to data concerning general crimes. He then incorporated his aggregation algorithm into the Node server, adjusted JSON responses to meet the app’s requirements and eventually got the API up and running.

By now, @satyamag had completed both the map and the details view of the app and gotten it working with the API. We already had something on hand worth talking about.

Hours 14 to 20

In the meanwhile, @satyamag thought up an interesting feature. Since children are prone to wandering off into dangerous territories accidentally, and are not likely to have the presence of mind to monitor the app for information, he added a “child mode”. Essentially, the app would automatically SMS two of the child’s emergency contacts if and when the child is in danger. @satyamag accomplished this by integrating the nifty Hoiio API and before long, he was tweaking the graphics and colours of the app and adding deft final touches.

As @vinothgopi polished the API and tested the algorithm I decided to get underway with an Android app. I had previously built multiple apps that are heavy on geo-location and mapping; thus, using some of my previously written code, I was able to get the basic framework up. Thereon, I engaged in a sprint to replicate what @satyamag had done on iOS. By the end of the 20th hour, the Android app was done, albeit without some of the cool features that @satyamag had integrated.

Key Takeaways

Get your hands dirty! App development can often seem to be a mountainous task at the outset. A great way to get started is to just start writing code.

That said, plan for the long run. Don’t resort to hacks that will have to be redone later. Getting the entire basic skeleton down is imperative. Before the day had started, we didn’t know a whole lot about Node.js APIs, Sphinx search, iOS geolocation, SMS APIs and much more, but we’re now comfortable enough with these ideas to set informed deadlines for the future and make adept feature choices.

Have your basic design plan in mind before you get coding though. Massive design changes are difficult to affect and often render code redundant; but the fact of the matter is that most design considerations that are debated over long periods of time don’t fall into this category.

Jot down a list of “things to do” in the future as you build your app. This includes either additional features or security/design/scalability/cross-device considerations that don’t fall under the category of a minimal working prototype. For instance, I’ve made a note to build 9-patch images for my Android app during my next iteration.

If your app is reliant of pre-generated data, focus on a subset rather than attempting to get all the data ready at once. The toughest dataset to integrate is the first one, closely followed by the second. Beyond that, the difficulty curve plateaus.

Statutory warning: This mode of development may not be applicable to the development of all kinds of apps, particularly those that are graphics intensive, so use your own discretion in identifying parallels between our experience and your needs.

All in all, I hope this post gives encouragement to some of the less experienced but promising app developers out there. Feel free to get in touch with me via Twitter (@govind201), email ( or comment on this post if you have questions or feedback. I’d love to have a chat about any of the stuff covered here.

Screenshots: iOS

iOS App Screenshot 1   iOS App Screenshot 2

Screenshots: Android

Android App Screenshot 1   Android App Screenshot 2

Govind Chandrasekhar

Govind Chandrasekhar

Govind manages API search and data processing at Semantics3. Previously, he had worked on metrics design and data visualisation at a business intelligence start-up. Govind has also explored software deployment in rural India, researched data-driven measures to ease road traffic and developed Android mobile applications.

More Posts

Follow Me:

  • Funny

    13590km away?

    • Govind Chandrasekhar

       We developed this app in Singapore. But our test dataset was for California …

    • boomfade

      They’re in Singapore (judging by the /contactus page, and googling Starhub says it’s a carrier there).

  • Miguel Ventura

    Sweet post! Nice team you’ve got there, gotta love the agile mindset:) how was the under the hood feature for location monitoring? What I mean is, you say you have a service polling for the gps location, but how does that behave regarding battery consumption? 

    • Satyam Agarwala

      Battery depletion was definitely a concern. Apple allows you to poll location data in two ways. One is when there is a significant change (determined by the system) in the location and the other is to use the standard method which is more frequent. For the second method you can further specify the accuracy to the nearest 10m, 1km etc. Higher the accuracy more is the battery usage.

      For this app we used the second approach with a accuracy of a kilometer polled about every 5 minutes. So yes, our app would be quite battery intensive but regular polling of location data is critical to our app’s functionality (Apple also mentions that if an app uses the standard method they must have a very good reason to do so otherwise it will be rejected).

      We did not figure a solution for that given the time frame we had. Would love to hear suggestions if anyone has any.

      • Miguel Ventura

        I asked this because I had the very same problem and didn’t quite get a smooth solution. On my case,the app would only fire up asynchronously so a push message that awakened the location service was enough to solve the problem. Looking forward for other suggestions too!

        • Sachin Siby

          Yes, polling every 5 minutes would definitely be battery intensive. Why don’t you try putting the app to ‘sleep’ while generating your interrupting time on the fly? On startup, the app finds the coordinates of the closest ‘danger location’. Then, you compute the distance the between your present location and that point (say r). Put the app to sleep until an approximate distance of say r/2 is reached after which the entire process of finding the closest ‘danger location’ is recomputed. This would be more efficient if say you’re in a safe part of town, wouldn’t keep polling every 5 minutes when you’re practically in no safe part of town, right? I’m not sure how this  can be done on the iPhone. Definitely can be implemented on Android using LocationManager and a PendingIntent I guess.

          Btw, I like the idea and loving the agile dev style ;)


          • Granaldo123

            Any plans to release the source? Anyway you can try geoloqi, they have an intelligent polling algorithm for getting location, based on distance from nearest marker and traveling speed.

  • Jimmy

    I played video games for 20 hours. I’d say from the content of the application our weekends produced similar value for the world.

    • Jimmy’s Mom

       LOL, Jimmy’s learning to think he can do stuff, while the guys writing the post actually did learn to do stuff they didn’t know how to do when they started the project.

    • Gus Van Sant

      What games?  Anything you would recommend?

      I’m super jazzed for Halo 4.  You?

  • Pingback: How We Built an iOS App, an Android App and a Node.js API in 20 Hours – AJavascript

  • Pingback: How We Built an iOS App, an Android App and a Node.js API in 20 Hours | Blog – Semantics3 |

  • staticsteven

    This is impressive! Did you run into any problems during development that held you up?

    • Vinoth Gopi

      The biggest hurdle was when Govind tried to get Limestone (Sphinx connector for Node.js) working. It was a pretty good port from PHP but it lacked support for geo searches, which was pretty much what our app depended on. Spent 2 hours trying to get it to work, only to realize it didn’t support it. Then spent 3 hours porting it over.

  • Shanjitsinghjajmann

    Nice idea. :) You guys seem to have put in a lot of effort! :)  

  • John_Doe

    Impressive! And what a great idea for an app as well. With some fine tuning (maybe allowing the user to adjust the level of noise and false positives) this could be one of the more useful apps out there.

  • Josh Levinger

    Impressive hustle, but this is a terrible idea for an app. You really need more than 20 hours to think through the societal implications of telling users (via their smartphone nonetheless) that they are in a “bad area” and that they should “leave now!”

    Your data sources track only certain kinds of crime: noise complaints, property theft, etc, but not white-collar crime or the financial crimes committed against all of us by the economic elite. Instead, you focus on data that, while easy to get, reinforces racial and societal stereotypes and is nothing more than modern redlining.

    It takes more than a rushed night of coding to build an app. Take this one back to the drawing board.

    • David Nix

      Data=Truth. You’re the one applying a racist mindset to the outcome, by assigning such small minded assumptions to this effort.Do “beware of dog” or “shark alert” signs cause more dog bites or shark attacks? Get a grip dude.

      • Josh Levinger

        Data is truth only if you ignore who makes what data available, and within what context. The depiction of all of oakland as a “dangerous area” is problematic, and the authors need to think more about the use of their app by real people in the real world.

        I understand that they’re from Singapore, and that they used a California dataset because it was what was available under their (apparently self-imposed) time pressure. But they totally ignore the local context, and made an app that is less than worthless to real users.

        I’ve seen too many one-off apps that try to “help people” without really considering the utility of technology to solve real-world problems. The more developers can interact with actual communities before they rush into coding, the better.

        • herval

          Having been mugged/robbed more than once in my life, I find the idea amazing and very useful. There’s nothing “problematic” on having your phone alerting you about danger zones in any city. I’m a real person in the real world and would definitely use this.

        • Govind Chandrasekhar

          As mentioned in the post itself, we’ve been “victims of assault and vandalism ourselves”. And among us, we’ve lived in California and Pennsylvania.

      • godofbiscuits

        Data and truth are NOT the same concepts.

    • AverageOne

      yeah, I lived in a fashionable gentrified neighborhood (read: glorified ghetto) for several years, and if I had this app, it would be callin po po 24-7. Great architecture though, and any girl you could get over to the place was guaranteed to put out. good times. 

    • Mikael Lofjärd

      *sarcasm*Nothing would scare me more than walking through the park, late at night, thinking about the horrible tax evasion schemes happening in the bushes.*sarcasm*

    • Nick Nolte

      the idea is not terrible, you twat. envy much?

    • Jody Robert Ford

      It’s not a bad idea for an app. Some crimes represent a clear and present danger to a user while other white-collar crimes would not present a need for immediate user alerts.

      Maybe he should add a category for the proximity of wacko’s from the Anonymous, Anarchy, and Occupy brigades. That would be useful.

  • samwize

    Glad that Hoiio API is used! (im from Hoiio)

  • Pingback: Hoiio supports Hack & Roll 2012 - Hoiio Developer Blog

  • Sascha Depold

    Thanks for using sequelize and mentioning it in the post :)

    • Govind Chandrasekhar

       No problem. Did you develop Sequelize? Thanks for that!

      • Sascha Depold

        yap :)

  • Micah Silverman

    Thanks for this. I just posted a similar story on how I wrote an iPhone app in less than 24 hours thanks to my yearly review:

    • Govind Chandrasekhar

       Great job!

  • Gagganweb

    A automatic keylock is included, with a great screensaver function that allows you to display analog clock or digital clock when the keys are locked. Also possible are shortcuts to STK functions cellphones (but also any program) , which can be defined within the STK settings google gadgets

  • Spam

    Slightly misleading. The real title should be ‘how four of us build an app in 20 hours’ or even better ‘How to build an app in 80 man hours’. Thats two full time weeks of one person working.

  • Guestface

    Ummm, pretty cool but I am not sure you’ve thought through the premise of the app… if  you’re in a dangerous place, do you really want to be holding your $1000 phone with it flashing and singing “rob me”? :P

    • Vineet

      $1000 phone.. is it a gold plated one ?

  • gaggan

    The apps was born out of personal experience. Within a month of moving to Philadelphia, I was assaulted on two occasions, including once on my very first day there. I put that down to my lack of knowledge of the area; I later discovered that a more knowledgable person wouldn’t have accidentally wandered off at that time of evening to that particular area Googletech talks. Turns out, some of my neighbors had had similar experiences in the past in the very same area. I was later warned by local authorities that the area was known for the phenomenon of “gentrification”.

  • Arvind Gupta

    I thought of working on an HelpMe mobile app which create notification to police based on location in the case of any the person is in danger(like female) and also update the status on twitter and facebook. By posting on facebook/twitter people can help incase police are not reachable by forward to local authorities also, It can also act as record in context of evidense in crime. I found you application very creative. I am also thinking of doing in indian context where people has low range and mobile cases which doesn’t have rich functionality of like Andoid/iOS. What do you think of it? Please also guide me from your expiriences on Application. You guys have done a fabulous job. If I can help you guys to also port it to Window7/Winodw 8 mobile devices I will love to do it .

  • Christopher Simon

    Great app! Just curious though, how do you manage to generate sufficient profit while using the Holiio API? If you are being charged per message, I just seems like you will have a net loss in the end, no?

  • Hi

    “Arrests” aren’t crimes :)

  • godofbiscuits

    “plan for the long run”

    no no no no no no no. Build only for what you need for the product. If you’re even a half-way decent engineer, you won’t be writing shitty mangled code to begin with.

    Planning for things that may never happen is a form of technical debt.

  • Maradona Mossiba

    Hello Govind,
    although it’s a three years old post, I really like it and it’s very motivating. This makes programming cool and powerful, by using skills and a bit of logic thinking. I enjoyed reading this post :)