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 >>

/
20 Questions, or Maybe a Few More

Stephanie Goldner wrote this on November 16, 2016 under android, app, entrepreneur, founders, inaka, ios, mobile, work .

Have you ever played or been asked to play 20 questions? In the game, one person chooses an object which is not revealed to the other players. The point of the game is for the other players to guess the object by asking only 20 very smart questions.

At Inaka this is not a game and, thankfully the input we receive is far more detailed and we have a lot more than 20 guesses to get it right. In case you’re wondering, I’m talking about the estimate process.

Here at Inaka we spend a lot of time with companies learning about their product before lines of code are written and there are several very important reasons why. Here are just a few:

Your investment is our investment

Whether it’s deadlines, budget, quality, or something else, meeting the standards we mutually agree upon is critical to our business's survival. That means we spend a lot of time dissecting risk, understanding the different product’s pieces and how those fit together, identifying the best technological solution for each part, and thinking about the implementation time we calculate for each task. Our goal is ultimately to provide you with a very close to accurate representation of how and how much it will take to build your product, and to respect that for the sake of both of us.

Holes in product definition can be huge cost for you and for the development team if detected later in the development process

In over 6 years of building complex products we’ve learned that taking the time to find missing pieces, potential risks, bad practices, and unnecessary features while in the conceptual stage is one of the biggest cost savings exercises that a development firm can undertake. While development and feature definition can still be done on the fly, you run into fewer surprises having thought through some of the major features initially. Throughout the process, it’s also hugely important for us to have an open dialogue with our clients about questions, details, etc.

You are the product lead in this picture

When we work with a client, we want to make sure that we fully and completely understand their product so that we can build from head to toe exactly what they expect. In order for us to really dive into that and make sure our team will live and breathe your product while we build it, we need your help in getting a 360 degree view of it. This of course will mean you can expect lots of questions from us around things like who the product is for, what is it’s purpose, what do you want the end user experience to be, etc.

While it’s extremely important for Inaka as a company to make sure we’re checking the boxes on all of the above, it’s not just any questions that are important but the right set of questions. We’ve worked with enough clients through enough estimation processes to understand what the greatest risks are, and what questions to ask to minimize those.

That being said, regardless of the development firm you end up working with, if you remember one thing, remember this: If you’re not being asked many questions, either your documentation and wireframes are unparalleled in their exactitude and breadth, or you may be setting yourself up for risky business.