inaka

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

/
Otec

Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace

/
CredoCI

Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

/
See all Inaka's blog posts >>

/
7 Tactics to Build an App Without a Technical Cofounder: Part 3

Inaka Blog wrote this on September 06, 2013 under advice, startup, tips .

In Part 1 and Part 2 of this series, we covered the first three tactics: Know the Tools, Know the Iceberg Model, and Determine the Relationship.

Now it’s time to separate the necessary from the unnecessary, all in search of the best user experience:

Consider the Platform

When deciding which platform (or how many), the key is iterate only on the most profitable platform. By iterating your app on only one platform, you will be able to transfer it to other platforms later as a finished product instead of something that still needs improvement.

Case in point: very early on, MTV released an app for the iPad. Though the iPad audience was limited, this proved to be an advantage as the app was tested and iterated on the iPad before moving to the iPhone and Android. It was only later, once the app was polished, that they spread it to other platforms.

In this way, MTV only went through the iteration process once, and the total cost of development was reduced immensely.

Don’t Take Shortcuts

There are shortcuts, and then there are crippling mistakes. One such crippling mistake is not taking the time to write the right code from the get-go.

Be wary of things like cross-platform frameworks. Though they are touted by some developers, every shortcut has its cost and in this case, it's that apps built on these cross-platform frameworks usually have terrible interfaces.

For example, Fox News launched an html5 app instead of a native app. Now, they’ve had to shell out tons of extra cash to improve the code, work out bugs, and fix browser errors – all of which also results in a poor user experience.

The only time you'd want to use an existing framework is if you are creating a shoddily-made test project. With this in mind – do not use an existing framework unless you want it to run like a shoddily-made test project. If you want a truly compelling product, take the time to launch a native app.

Don’t Over-Design

Remember, the user won’t have as much time with your app as you and the developers do, so its design should be simple and intuitive.

The Inaka-made Whisper app doesn't have a setting panel at all, for example, and it’s been downloaded millions of times. On the other hand, another Inaka client was adamant about implementing dozens of switches on the settings page. They launched and did terribly, and to this day, the settings page still gives them issues.

Users don't necessarily want to use a million settings; they just want to use your app. Have a good concept, and then make it as simple as possible.

Don’t Stop

Even after all the code has been laid, there’s still a lot of buzz to create, a lot of notifications to push, and a lot of reviews to read. A lot of the legwork is yet to come. If you're ruthless about stats and push notifications, your app is more likely to succeed.

The Learn Spanish app, for example, allows users to buy courses within the app. The founder spends a large part of his time focusing on what users are doing and how he can bring them back. How, you ask? He segments his users with an anyalytics tool and focuses on driving traffic to the app and site. (Remember the analytics tools we told you about in Part 1!)

After all, you have your perfect app. Now you just need to get it to the people who will want it most.

And there you have it! You don't need to have a technical cofounder to build an app; you just need to know a bit of the basics:

Know the Tools

Know the Iceberg Model

Determine the Relationship

Consider the Platform

Don’t Take Shortcuts

Don’t Over-Design

Don’t Stop