Latest blog entries

Erlang and Elixir Factory Lite B.A.

A brief introduction about what was the Erlang Factory Conference in Buenos Aires for some Inaka team members

Jul 07 2017 : Euen Lopez

The Art of Writing a Blogpost

The Art of Writing a Blogpost

Apr 11 2017 : Matias Vera

SpellingCI: No more spelling mistakes in your markdown flies!

Feb 14 2017 : Felipe Ripoll

Fast reverse geocoding with offline-geocoder

Do you need a blazing fast reverse geocoder? Enter offline-geocoder!

Jan 18 2017 : Roberto Romero

Using Jayme to connect to the new MongooseIM REST services

MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.

Dec 13 2016 : Sergio Abraham

20 Questions, or Maybe a Few More

20 Questions, or Maybe a Few More

Nov 16 2016 : Stephanie Goldner

The Power of Meeting People

Because conferences and meetups are not just about the technical stuff.

Nov 01 2016 : Pablo Villar

Finding the right partner for your app build

Sharing some light on how it is to partner with us.

Oct 27 2016 : Inaka

Just Play my Sound

How to easily play a sound in Android

Oct 25 2016 : Giaquinta Emiliano

Opening our Guidelines to the World

We're publishing our work guidelines for the world to see.

Oct 13 2016 : Brujo Benavides

Using NIFs: the easy way

Using niffy to simplify working with NIFs on Erlang

Oct 05 2016 : Hernan Rivas Acosta

Function Naming In Swift 3

How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.

Sep 16 2016 : Pablo Villar

Jenkins automated tests for Rails

How to automatically trigger rails tests with a Jenkins job

Sep 14 2016 : Demian Sciessere

Erlang REST Server Stack

A description of our usual stack for building REST servers in Erlang

Sep 06 2016 : Brujo Benavides

Replacing JSON when talking to Erlang

Using Erlang's External Term Format

Aug 17 2016 : Hernan Rivas Acosta

Gadget + Lewis = Android Lint CI

Integrating our Android linter with Github's pull requests

Aug 04 2016 : Fernando Ramirez and Euen Lopez

Passwordless login with phoenix

Introducing how to implement passwordless login with phoenix framework

Jul 27 2016 : Thiago Borges

Beam Olympics

Our newest game to test your Beam Skills

Jul 14 2016 : Brujo Benavides


Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace


Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

See all Inaka's blog posts >>

Don't Under-Think It: Making Critical Decisions When Building an iOS Application

Chad DePue wrote this on December 06, 2012 under design, dev, engineering, management, project .

Getting started

When we were approached about building Whisper, my first thought was that this would be a great opportunity to apply a lot of my philosophy of app building. They had an incredibly smart founder, a really good idea, and funding. What they didn't have was a technical team. This is the type of project where our team shines. What follows here is an attempt to generalize some of the decisions we made. One was sufficiently painful enough that I wrote a summary and then decided to make it a second post. The rest are generally applicable to lots of applications and projects.

First Technology Decision - Ruby vs Erlang

Our team has a lot of experience with Ruby, Erlang, Scala, and C#. We only seriously considered Ruby and Erlang for this project. In the end, we went with the Hybrid model - Rails for Admin/Backend, Erlang for API. This turned out to be a great decision, as we're in the top 10% of traffic for all mobile apps with only a handful of servers. Was it a good decision to build a hybrid system with Erlang as the front line? YES. There are lots of good technologies out there, and you don't have to use either of these - but I'm a big fan of using the right tool for the job, and both Rails and Erlang/OTP have their place.

Second Technology Decision - Real-time sockets

We debated adding a special socket for deletes. The reason for this was we wanted to be able to remove inappropriate or hateful content without waiting for a device to refresh. This turned out to be an incredibly powerful channel that we now use for all sorts of things aside from deleting Whispers -- Metadata updates, connected user counts, deciding whether a user is connected and should get a push notification or a more powerful real-time socket update, determining activity, and more. After this experience, and with the ease of creating a socket channel in Erlang, I don't want to build another web application without including this "backchannel". Was it a good decision to implement a real-time channel in addition an HTTP/JSON API? YES.

Third Technology Decision - NoSQL vs SQL

For this application, we decided to use Riak, NoSQL database that has become more popular in the past year, because we expected a lot of users and a lot of Whispers. We decided that the additional up-front cost of Map/Reduces would be OK because we could really scale to dozens of Riak servers and Terabytes of Whisper data. This was not the case, and we'll cover what happened with Riak in a second post like I mentioned in the introduction. Was it a good decision to use Riak? Cue the ominous music and stay tuned...

Fourth Technology Decision - Security

We spent a lot of time thinking about device security and ways to prevent spam, jailbroken devices, fake users, and more. Should we build "banned users" into the app? Should we build filters for text content? Should we have multiple classes of users - trusted and untrusted? After months of operation, I can say:

  • Extra time up-front to ensure algorithmic rigor always pays off. Defenses we thought would be useful, such as authenticating all requests, requiring SSL, and others we can't mention here -- though they took a bit more time at the start -- have been incredibly useful.
  • Extra time on ontology is NOT worth it. By that, I mean classes of users, admin levels, etc. Until you SEE how people will use an app, behavior is incredibly hard to predict; and some of our up-front user segregation machinations were useless.

Fifth Technology Decision - Dials and Knobs

I have a forthcoming post about software designs, and what separates successful projects from unsuccessful ones. One of the major ways I can tell a team is professional and serious about building a successful app is when they don't come in with a lot of settings. A technology project's odds of success are inversely proportional to the number of customizable settings in the first version of that product.

In fact, I'm going to pause for effect here.

A technology project's odds of success are inversely proportional to the number of customizable settings in the first version of that product.

Whisper resisted for weeks the idea of adding even a settings page. We finally HAD to add one as Apple asked us to allow username customization, so we did so. Contrast this to many of the proposals I get each week with 20 to 25 ways to configure e-mail alerts and push notifications. Quite honestly, no iPhone carrying human has the emotional and mental bandwidth to think deeply about your alert preferences, and that is one of the reasons I'm not cynical about humanity's prospects. Do we need a lot of customizable settings for the first version of our app? The answer is always NO.

And Finally, The Most Important Decision - How much do I trust this team?

The client team in LA had wireframes and ideas for the app along with a great designer. But how much did they trust us? Do we focus on a perfect specification and an iron-clad contract down to the last penny and week? That puts a huge burden on up-front requirements gathering. And it focuses our relationship on a piece of paper. My favorite lawyer often says in the course of drafting bizdev agreements between large entities, "This piece of paper is worth nothing if the two parties in this room aren't committed to the relationship." A good contract is important, that's not up for debate. We work hard to make clear, concise contracts. But we work harder to be committed to the relationship. A scope of work is similar. We work HARD to build accurate estimates around projects, but we always remember that we're not locking ourselves into a fixed vision of an app before we've seen it in our hands.

In this case, we decided to build a scope of work from the wireframes as a target for our development effort. This is most useful because it gives us a sense of what the app is going to take to get it done. Then we basically throw it away after putting every task in that document into Pivotal Tracker. Pivotal becomes our Truth.

Fast forward to a few weeks later, after we had a prototype in-hand -- we threw out two MAJOR components we thought were critical to the first version. We didn't spend two seconds thinking about renegotiating a contract -- we just kept iterating.

Was an initial estimate enough to make a go/no-go decision? Yes. Did we know within 10% what our costs will be? No. In fact, we didn't know what the winning product was until we had built it. But was it a good decision to trust each other without knowing exactly where we were headed? As Whisper is currently the fastest growing social media app in the app store, I'd say YES.

Contact Us

Follow Chad On Twitter