+1 (512) 949-8991
+1 (512) 949-8991

Our work philosophy

Here, you'll find pretty much everything you need to know about the way we do things.
All of us have contributed to this book in one way or another, and we hope that you find it useful and interesting.


The beginning

In the beginning (of any product's development process) there was a brilliant idea, intended to make people's lives easier. That idea, eager to become a successful product, could be implemented in a million ways.
Some of those possible implementations are meant to fail. Others aren't worth the time and money. However, a select few of them will turn out to be the right solutions.

We help our clients implement the right solutions –the ones that maximize both usability and revenue.

We believe the best way to achieve this is through our development process, refined over the years and enhanced by our skilled team, and the set of values to which we are all committed.
Let us tell you about the Moove-it way.



Our cause is to enable innovation in organizations by building software products that truly improve people's lives. We develop usable, reliable and sustainable solutions for both business and social purposes. 

Core values

Quality over quantity
That’s the key to our philosophy. We strive to deliver the best service and highest quality products by constantly reviewing and improving every aspect of our process.

Strong relationships
We build strong relationships based on mutual trust with our clients and encourage close bonds among our team members. 

Heart & Commitment
We work with passion. We are enthusiastic about the work we do and the products we help build.
We respect our clients. We put ourselves in their shoes, always listening intently to understand opinions that diverge from our own, and contribute with new ideas.

Team over individuals
We are team players. We think that the best way to achieve great things is through a sustainable, strong and professional team.
Within each team, every individual’s point of view, expertise and initiative, contribute collaboratively to create something valuable.

Happiness and flourishing
We continuously seek to improve ourselves and develop our potential.
We cultivate and foster the three L’s: listen, listen and listen.
Working hard and having fun while doing so is our key to success.
We flourish because we love what we do!


We are technology partners. We help architect and quickly develop software products and services, delivering meaningful outcomes to both our clients and their audience. We also assist our clients in making smarter choices about what they create and how they create it.

We pursue excellence. We are committed to a high-quality development process that includes thoroughly testing the software we build, performing collaborative code reviews, and continuously evaluating our work processes.

We deliver a cost-effective service. We perform daily and weekly software builds, regularly sync with our clients, and always keep them up-to-date on their project’s progress. These processes help us ensure that our software meets our clients' evolving requirements and enables us to stay within agreed timelines and budgets.

We love challenges and we are keen learners. We know that every project provides us with valuable knowledge, and we always welcome new adventures. That’s made possible by our agilist development process, which allows our clients to explore innovative ideas at low risk. In addition, every member of the crew will always be ready to jump in and offer their advice.

We are professionals and we trust our staff. We have a strong team of people who love working with each other. We manage our teams by respecting everyone’s opinions, constantly keeping an eye on the efficiency of our projects, whilst encouraging self-organization.
Last, but by no means least, we constantly strive to contribute to our community in various ways, including offering educational packages, trainee programs and by making charitable donations.


There are a million ways to implement an idea, but what if the idea itself is based on the wrong assumptions about the target market? Or, what if the idea is valid, but it's not properly communicated to the people in charge of implementing it?
To answer those questions, we start every project with an inception phase. The aim of this is twofold: (1) to challenge the idea against reality, and (2) to mitigate the risk of miscommunication.
We use different tools to achieve these aims, including using product discovery, business model canvases, personas, wireframes and high-fidelity mockups.

Product Discovery

In order to build the right solution, the overall goal has to be clear to everyone involved in the project. Such product vision is the true north of every project.

"The product vision paints a picture of the future that draws people in. It describes who the customers are, what customers need, and how these needs will be met. It captures the essence of the product – the critical information we must know to develop and launch a winning product." From the Scrum Alliance

We help discover the product vision through understanding and challenging the problem itself, the business strategy, the intended target customers, and the product’s value proposition.

Business Model Canvas

We work side by side with our clients to identify the underlying assumptions about the target market. Who are the target customers? What problem is the product idea trying to solve? How it will generate revenue? What’s the biggest technical risk?

Those are just some of the questions we attempt to answer using the business model canvas.

It helps us understand the most important and most risky assumptions, highlighting the business’ weak spots that require immediate attention.


More often than not, the ideal user we have in mind does not match the real life end user. The road to success is paved with product ideas intended for the wrong user population.
We use personas to discover and synthesize a set of profiles describing a particular customer segment. Each profile describes a stereotypical user with a real name, story and personality, representing a set of users who share common characteristics.
Personas help us build features with a particular user in mind and contribute to better communication among the project's stakeholders.


We strongly believe in the wireframe stage of every project.
A wireframe is a visual guide that represents the skeletal framework of the product's user interface. It focuses on highlighting functionality and information architecture, closing the gap between what has to be done and where it should be placed, but not on how it should look from a design perspective.

Wireframes help us display the product's architecture visually, improve communication with our clients, push usability to the forefront and save time on the entire project.

Wireframes are meant to be easily changed. Our UX team uses paper, pencils, erasers and marker pens to draw wireframes. This gives us freedom to explore different solutions.
Once the wireframes have been validated, the product under construction is ready to jump to the next step: the mockup.

High Fidelity Mockups

Validating the user interface (both visuals and interaction) against representative users is crucial at this stage.
High-fidelity mockups help communicate the aesthetics and behavior of the product being built.
They allow stakeholders to interact with the product user interface in order to gather insights about the user experience. The goal is to validate the entire workflow, colors, logo, images and transitions.
We use InVision as a tool to create high-fidelity mockups. It makes both face-to-face and remote user testing easy. 


The success of a software development project depends on two aspects: effective communication and high technical capability.
Effective communication includes having well defined tasks, clear assignment of responsibilities, explicit acceptance criteria, frequent checkpoints, visible progress reports, an effective dialog between stakeholders, and, of course, an occasional beer with our clients.
High technical capability includes mastering the tools and languages involved in the development process, using automated software testing, the ability to discover and resolve technical risks, using good criteria to make estimations, coding fast, using best coding practices, and the ability to learn from failure.
Both aspects contribute to delivering the right product on time, having gone through a smooth development process.
We follow agile development methods because we believe they are a perfect fit for achieving effective communication and developing our technical capabilities.


Each project is unique and some agile methodologies fit better than others, depending on the particular case.
Scrum fits in nicely with most of our developments. For some projects, particularly maintenance projects, we would use Kanban instead.

We put into practice the three components of an agilist empirical process: transparency, inspection and adaptation. Transparency promotes information flow and creates an open work culture. Inspection allows us to review every aspect of the process. Adaptation allows the team and stakeholders to learn from the process and then adapt it, if required.

Product Backlog

User stories describe how the product should behave from the customer’s perspective. Thus, they also tell designers and engineers what to do.

On a regular basis, the client and the team meet to review and reorganize user stories posted in the Product Backlog, and to plan the next iteration. In general, a Product Owner –normally, a member of the client team– is in charge of maintaining the Product Backlog.

Each user story should follow the INVEST model (Independent, Negotiable, Valuable, Estimable, Small and Testable) and must be focused on the value a user gains from using the product.


An iteration planning meeting will bring the whole team and the Product Owner together to plan the next iteration, lasting a period of one or two weeks.

Before the meeting starts, every team member gets familiar with the stories that will most likely be carried out in the next iteration. During the meeting, the Product Owner sets the priorities for the iteration and answers questions from the team.

Once the priorities are set and the stories are well defined, the team estimates the effort required to complete them. We frequently use a technique called Planning Poker to make estimations, based on an exponential scale (1, 2, 3, 5, 8, 13…).
A number that is too high may indicate that the story involves too many activities and deserves a closer look. User stories that are overly complex are split into smaller stories.

In agreement with the Product Owner and based on the team's historical development velocity, the team will commit to complete a certain number of stories during the next iteration.
We are advocates of the “done means done” philosophy: a story is complete, only when the code tests pass and the features work as they're supposed to, meaning they're ready for production.

Daily Standups

On a daily basis, each team gets together for 15 minutes to let every member share three things:

1. What he/she did yesterday
2. What he/she’s going to do today
3. What things are blocking him/her

The daily meeting fosters peer-to-peer sharing of information, preventing miscommunication and detecting problems as early as possible.
We use either Skype or Google Hangouts to communicate with our clients. 


Retrospective meetings, or retros, are a key part of our process that allow us to adapt. During retros, the team openly discusses the practices that are working well versus the ones that need improvement.

At the end of every iteration (commonly, every two weeks), each team meets together to evaluate its performance, defining actions to take in order to improve the overall process.
To make retro meetings as efficient as possible, we organize them into three stages:
1. Reviewing the action plan from the previous retro meeting.
2. Brainstorming and discussion. We drive this section using the start-stop-continue approach.
3. Creating an action plan and assigning responsibilities for each action item.


Version control

Unless a client's development environment prevents us from doing so, we prefer to use and strongly recommend Git as a project’s version control system.

Git beats other version control systems –such as SVN or CVS– in terms of performance, distributed collaboration capabilities, repository size, security and branch handling.
In addition, Git is free, open source and easy to use.

Code Quality

We systematically pair-review our code to make it more readable, better performant, less error-prone, to transfer knowledge, and to share good coding practices among team members. We are also advocates of continuous integration, meaning that, several times a day, we deliver production-ready code.

We use a combination of tools that help us facilitate both code reviews and continuous integration tasks. They allow our developers collaboratively to work on the code and get their code reviewed, as well as to review other people's code. 

Once the tests are passing and the review process has been completed, the code is ready to be merged into the main branch. This process gives us and our clients certainty that:

  • New code won't break previous features.
  • The code serves both as a performant functional set of instructions and a document that can be understood by everyone.
  • Code quality is at its optimum before delivery.

Code Review

We normally use Gerrit as a tool for code review.
The uploaded code, organized into commits, must be verified by other team members, called verifiers, before being merged into the master branch, which is where production-ready code lies.
Verifiers review all the modifications introduced by a commit and make comments about things that can be improved or fixed. Everyone in the company is encouraged to read the comments and contribute new ones.

Then, verifiers punctuate the commit choosing from a list of options:

-2: Cannot be merged. Errors were found or it does not meet required standards.
-1: Needs enhancements or discussion before merging.
+0: Trivial comments.
+1: Ok, but someone else needs to approve.
+2: Code is allowed to be merged.

The developer can then apply any of the requested modifications, update the revision, and the process starts over.
Once the review process has finished, the commit is ready to be merged into a particular destination branch. This happens only if the Continuous Integration server, the tool we describe below, has verified that all the tests pass.

Gerrit can work as an extra repository to manage the code review and the interactions with the Continuous Integration server. Once a commit gets merged into a branch, Gerrit can be configured to automatically push the code to another repository, like Bitbucket or GitHub.

Continuous Integration

In general, we use Jenkins as our Continuous Integration tool. Jenkins continuously builds and tests the code submitted to a project’s repository.

If the code breaks the tests, it cannot be merged with the master branch. We use Jenkins to make sure that failing code never slips into production.


Sales Process

Steps we follow in order to analyze partnership opportunities:

  1. We get in touch with a potential client. Most of our clients are word-of-mouth referrals who contact us via email, or executives who hear about us via the web by googling software development companies.
  2. We schedule a time to talk about the idea or the project the client has in mind. We also talk about Moove-it, our values and processes.
  3. During the meeting, both parties would study the business case, evaluating the opportunity of engaging together.
  4. If we both decide to explore the opportunity further, then we normally set up another meeting, bringing in an engineer, to talk about the project’s scope.
  5. To gain a deeper understanding into the client’s vision and the project requirements, our potential clients generally share supplementary documentation and resources with us.
  6. Studying that information helps us to come up with a ballpark estimate of the time and effort required to implement the idea.
  7. We elaborate the proposal, which includes estimated timeframes, resources and pricing.
  8. The client likes our proposal, approves it and signs an initial business contract with us :)


Our main source of leads is referrals from current and past clients.

The person responsible for the lead follow-up is a Business Developer, a Principal, or a Managing Director in some cases.


We track and follow-up our leads with Pipedrive.

Team Allocation

We assign our professionals, based on the skill-sets required for each project.

We are happy to introduce the team members to a client, once we are positive they are a good fit for a particular project and client.

Our recruiting process is very thorough to guarantee talented professionals. Consequently, we do not normally have "personal job interviews" with potential clients.
We form teams with a minimum of 2 people in each one. A team member may be involved in more than one project, so they aren't necessarily full-time on any given project. This makes it easier to rotate team members, in case someone gets sick, is on vacation or leaves the company.


We work from our office. We feel that we are a community of people sharing the same values who love hanging out with each other. After office we organize soccer matches, run together, have barbeques, go dancing, or just enjoy a beer together. On average, our team members have been working here for two and a half years. Some people have even been working at Moove-it for more than six years and are still here! That's very unique in the software industry

Some of the benefits of working here include paid Friday tech-lunches, training courses and certifications, a relaxed working environment, cool offices, an open-minded community, chill-out areas, bicycle racks, ping-pong and table football.


We strive for effective communication.

We complement face-to-face communication with video conferences, chat, email, ticketing and project management apps, and an ecosystem of integrated communication and development tools.

The list includes:

  • Google Hangouts and/or Skype for video conferencing
  • Slack or HipChat for chat
  • Trello, Jira or Basecamp for project management
  • Gerrit or GitHub with integrated chat apps
  • Jenkins integrated with chat apps

If a project requires it, we send daily or weekly summaries to our clients to keep them up to date with the progress. In some exceptional cases, part of the team might also travel to a client’s offices to work side by side.

Fridays talks

Every Friday around noon, the entire company will gather together to share lunch and attend a technical talk in our seminar room.

The topics for these talks are defined by the team and then prepared by a single person.

Other than sharing good food, the goal is to keep the team updated in the latest technologies. 


We believe in the benefits of formal and non-formal education. In a constantly-changing world, we foster an environment in which learning is a way of life.

That’s one of the reasons we encourage our team to take training courses and certifications.

Some of the most popular courses and certifications we take include:

As a rule, team members attending a conference are strongly encouraged to share the insights they’ve learned with the rest of the team. This happens in a Friday Talk or by writing a blog post


In the software industry, it’s hard to find talent that can combine hard work with technical expertise, soft skills and a sustainable pace. Moove-it invests in people who demonstrate the potential to develop these qualities. Being an enthusiastic learner and a committed player are key for any applicant.

Our application process comprises three steps:

  1. Tell us about yourself. Drop us a cover letter at jobs@moove-it.com. Include your resume and/or your LinkedIn profile and/or GitHub profile, if you have one.
  2. A relaxed interview. Let’s meet together and see if we are a good fit with each other.
  3. A technical test. This allows us to make an initial assessment of a candidate's problem-solving and technical abilities.

Check out our job openings, we are constantly hiring!


We all need regular checkpoints to review what we’ve been doing well and what things we need to improve on. That’s the only way to learn and flourish.

We believe that receiving honest feedback from the people you work with is the best way to grow professionally and personally. Thus, we take it very seriously.

We also know that not everybody feels confortable about giving and receiving feedback so, at Moove-it, we work hard to build a safe zone where people can talk honestly and openly about their success and failure stories with each other.

At the appropriate times, all team members are encouraged to request feedback from other team members, and to provide feedback to others.

In addition, to make sure that everybody gives and receives feedback, every four months there’s a requirement for all team members to give feedback to the people they work directly with.

The goal of each feedback round is to identify skills that could be improved. It is meant to be a positive and useful opportunity, where two team members openly talk about their perceptions of each other's work, and to identify ways to improve. Feedback rounds are composed of:

  • Evaluating important technical and non-technical skills, such as speed of learning, quality of communications and teamwork.
  • Mutual agreement and understanding of the skills to be improved.
  • Short and mid-term objectives to be accomplished through a result-oriented learning path. An example would be exploring training opportunities in a particular area.

Before each feedback meeting, every participant puts together a list by team member evaluating the issues highlighted when assessing each other’s work.

Each team member also fills in a self-assessment sheet. The goal is to help generate a fluid and productive feedback experience. This method has proven to be an effective tool in improving our overall performance at work, in finding better ways to confront problems and, above all, in promoting and encouraging actions which contribute to make our company a unique and evolving place to work. 


We use the following technologies as our core stack, and we are constantly exploring new ones.

Programming Languages

Web products: Ruby + JavaScript

We use Ruby as the server-side programming language for most of our web products.

Ruby helps us focus on simplicity and productivity, while the code remains elegant and easy to read.

We use Ruby on Rails in mid to large enterprise applications, and in applications that require us to get the product to market immediately.

For lightweight applications on the server side, like single page apps, minimum viable products or small-sized web apps, we would use Sinatra.

Some projects require an intensive use of JavaScript on the client side. Depending on the project, we may choose one Javascript framework or another, or one particular productivity library or the other. We have experience developing first-citizen single page applications using React, Angular, Ember, jQuery and other Javascript frameworks.

Mobile apps

When it comes to creating mobile apps for iPhone, iPad or Android, we prefer native over mobile-web solutions. There are a lot of reasons for this and we are always open to receiving client opinions but, at the end of the day, it’s a matter of user experience: users are more familiar with the native flow than the hybrid one. In hybrid, it’s more difficult to reproduce the native feel.

For iPhone and iPad we use Objective-C or Swift, and for Android we use Java, combined with different frameworks, to craft the mobile solution our clients need.


We strive to combine the best skills and technologies to come up with the perfect solutions for our customers. Finding the right amount of each technology is the key to success.

Having a strong Java EE background, that has evolved right from when we founded the company, our experts are used to designing, developing and maintaining Java-based middleware solutions for corporate and global environments.

Naturally, we also use Java for creating stunning Android apps.


Built on top of the Java Virtual Machine (JVM), JRuby allows us to write Ruby code that natively interacts with Java objects and classes.

This feature can be very beneficial for projects that require high portability and interoperability with Java.

Also, in certain cases, performance is actually improved when using JVM rather than MRI.


Rails & Sinatra are our favorite frameworks for server-side web development. On the client side, we usually work with React, Angular, Ember, jQuery and other Javascript frameworks.

As mentioned before, we also work to create mobile products using iOS and Android SDKs, as well as our own reusable components.


  • MySQL
  • Postgres
  • DB2
  • Redis
  • MongoDB

Integrating tools

  • Spring integration
  • Apache Camel
  • ActiveMQ

Test strategy 

How can dev teams make sure that the features and fixes added in the current iteration don’t break the work we've already completed? There are two ways to expand functionality without sacrificing quality: (1) having a QA dept, that is big enough to tackle different projects at a time and quickly respond to the development pace, and (2) test automation.

We prioritize the second option. Automated testing helps us save time, keeping project goals within budget. We use a variety of libraries and tools to write automated tests, including:

  • RSpec, Minitest, Cucumber, Capybara, Selenium in Ruby on Rails projects.
  • Karma (formerly Testacular) with Jasmine or Mocha in AngularJS applications.
  • Mockito, JUnit or Gradle in Java applications.
  • XCTest, Specta, Kiwi, KIF in iOS applications.
  • Robolectric in Android applications.

Each team decides what the best testing strategy is for the particular project under development. In general, we follow a BDD approach. For small projects, requiring a minimum viable prototype to quickly validate a market, we wait a short while before writing tests.

Whatever the chosen strategy, we make sure that we have healthy test coverage, as early as possible.


We strive to give some love back to our community. 


We've been sponsoring the main tech conferences for the last few years (RailsConf 2016 Kansas City, RubyConf San Antonio 2015, Keep Ruby Weird 2015RubyConf Uruguay, Tech Meetup UY, LSM Montevideo).

Most of our team enjoy attending these events, and occasionally present talks. 


We usually host and sponsor the Ruby and JS Meetups in our office. 

Open source

We are working hard to invest more and more time towards OSS.

Check out our GitHub page to see our latest contributions. 

A great deal of inspiration for this document comes from thoughtbot's playbook.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial 3.0 Unported License.