How we set up our team and tools when we start working with a software company

12 min read
April 21, 2021

This article is written for people who manage development teams and would like to know how DECODE collaborates with software companies as an outsourced mobile development company.

Starting a new project can be stressful. Especially if your development team is being outsourced. There are a bunch of questions that need to be answered, there are some problems that need to be solved, and that just adds more pressure to the project.

Thinking about all of this can stress you out before the project has even started.

Even though it’s never a walk in the park, there are some processes and practices that can make starting a project easier, and help lower stress levels on both sides. 

This blog will describe which tools, processes, and practices we use here at DECODE, and how we approach new projects. Let’s get to know our team and tools.

Assembling the Team

Every project calls for a different approach, and we know that. Depending on the project requirements DECODE usually assembles a team of diverse developers to suit the needs.

If there is more than one developer on the team, one of the senior developers will be assigned as a team lead.

The team lead will take on multiple responsibilities, along with working on a project as a developer and developing new features they will also: coordinate events and meetings; communicate with their team and the client; be the contact person for the client. 


The entrepreneur’s guide to boosting mobile app ROI →

Get your free copy and find out how successful entrepreneurs define parameters of success!

Also, since no one likes bugs in their app, we usually assign one or more full-time quality assurance engineers.

When working on bigger projects, if there is a need we divide the team into smaller pods, usually based on platforms. So, for example, we have one team with two pods, and two team leads, one for Android and one for iOS. Each team has its own quality assurance engineer.

We believe that developers work better when they are not switching context daily, so when a person is assigned to a project they will be working on that exclusively. Our clients can count on 100% dedication from our team.


Our Techstack

We at DECODE prefer working with the latest cutting-edge technologies. But, if there is some legacy project that needs an update and uses older technologies, that’s still not going to scare us off. Our iOS engineers are fluent in Swift and Objective-C, Android developers love Kotlin, but they all started with Java.



React Native










When it comes to cross-platform projects, we work both with React Native and Flutter. Here is an overview of our native and hybrid frameworks, libraries & patterns.

frameworks in app development

If you are interested in the differences between native and hybrid frameworks take a look at our blog post. 

Communication within the team and with client

Our primary tool for communication within the company is Slack. At the start, every project gets its own private channel that only team members can view and access.

Aside from Slack, all video calls, presentations, daily sync-ups or other meetings can be held online.

For video meetings we usually use Google Hangouts. Documents and files are shared through Google Drive. 

Don’t get us wrong, we can also be flexible. If for any reason, the client doesn’t want us to use any of those tools to communicate within the company regarding the project, we can switch to whatever suits the client’s needs. We are okay with using Zoom, Microsoft Teams, or any other tool.

Also, if a client doesn’t have any tool that can be used to communicate with us, we will be happy to send out invites to join our Slack channel as a guest so we can have constant communication. 

It is important for us to be in constant communication with our clients, and we encourage them to call us frequently and check on our progress.

One of our company values is TRANSPARENCY. And that goes both ways, internal and external.

We communicate with our clients openly, and we are not afraid to talk about project issues on our end. Having open communication enables us to accept and give feedback, helps us improve ourselves and builds trust with our clients.

Development methodology

All our teams are familiar with SCRUM methodology, and we encourage our clients to use it as well.

Our sprints are usually 2 weeks long, which has proven to be the optimal period for us to deliver the best results. This also gives us sufficient flexibility for changes in the project and its requirements

Agile methodology

Every consecutive sprint is planned before the current one has ended. All features, user stories, feature requests or bug reports are logged into Jira, or any other tool, like Microsoft Azure if a client is already using it, or prefers Asana or Trello.

As long as we have a way to track the status of tasks, features, bugs, and also time, we are happy. 

If the client wants, once during the sprint we hold an App Demo, a meeting where the developer who worked on the new features presents what’s new in the application.

After every sprint (usually the last day of the sprint), we deliver the app to the client with implemented new features and bug fixes, so that they can test it and see it for themselves.

Based on SCRUM methodology, we hold daily stand-up meetings where team members sync with each other, so that everyone knows what is the current status. Who is currently working on what, what has been finished, what still needs to be done, and what are the problems that someone is having trouble with. Everything is discussed openly.

scrum meetings vs working hours

Those meetings are not reserved for our team only. Any party involved with the project can participate, if they are interested.

As already mentioned, we encourage our clients to be constantly involved in the development process, and to maintain continuous communication with the team. That is how we can adjust our process quickly, if needed, and also timely and correctly anticipate and address any problem that may occur during the development process.

Development process and code quality

Whenever we can, we use CI/CD. Continuous integration allows us to run unit tests on every pull request that is created, along with static code analysis.

If all unit tests and static code analysis pass, and after the code is reviewed and approved by another developer that is working on the same project, the pull request is approved and the feature branch can be merged into the develop branch.

Beside the main goal of maintaining the code quality, pull requests are useful to other developers that haven’t worked on that particular feature. That way they can be up to date with the changes in the code that were made by other developers working on the same project. 

Regardless of seniority, every developer should participate in code review. Junior developers can learn, and senior developers will get an overview of changes.

quality assurance process for mobile apps 1

Once the feature is merged into the develop branch, CI/CD pipeline can automatically create a new build with new features included and distribute the application to QA engineers for testing. Also, this is a good point to generate code documentation.

Our QA engineers also write automated UI tests that can run each time a new feature is finished, or for example, once a week. Also, every project that we are working on can have Shake integrated for an easier bug reporting process.

Sometimes it takes a lot of time to set up the proper CI/CD process and pipelines, but it usually pays off later during the development process, since a lot of work is automated and doesn’t require the developers’ full attention. 

It also helps to maintain the same code style and code quality when a new team member is added.

Code repository

All code written by our team is accessible to our clients at any time. We usually use our BitBucket as source control, but if that doesn’t suit client’s requirements, we don’t mind using any other source control like GitHub, GitLab or Azure Git repository.

Analytics and Reporting

DECODE has been working on a custom-built bug reporting tool, the previously mentioned Shake.

Shake is usually integrated into the application in the beta development period. Any time that you notice a problem with the application during testing, you just shake your phone and Shake is automatically triggered. It takes a screenshot of the current screen, and allows you to mark a problem with your finger. 

Shake@2x 2

You can also add some notes, repro steps, or any other description that could help the developer resolve the issue. All this is translated into a task management tool, and our developers can see it right away.

Shake can be integrated with any native Android or iOS application with just a few lines of code. It is also possible to integrate it with cross-platform applications written in React Native or Flutter.

We are familiar with other analytic tools as well, like Google Analytics or Mixpanel. Read more about analytic tools in our blog post. 

Our tools at a glance

Integrated Development Environments

IDEs used are:

  • Android Studio
  • XCode (iOS)
  • Microsoft Visual Studio Code (React Native)
  • Eclipse

Productivity / Collaboration

For everyday work tracking and collaboration, both within DECODE internally as well as with our customers, we use the following tools:

  • Jira – all tasks and project documentation are in JIRA and the client has complete
    access to our JIRA project. Through it, the client is able to track our progress in
  • Slack – we try to keep all our informal communication on Slack. We find this easy
    and yet very efficient
  • Confluence – Atlassian’s collaboration platform is our trusted companion
  • MS DevOps / Teams – Microsoft’s development collaboration platforms
  • Trello – we revert to it for simplified task tracking
  • G-Suite – our documentation, e-mail and much more rely on this powerful platform
  • Float – project and resources planning

Software Control (Software Configuration Management)

  • Git – like most of the industry, we adopted git from day one and used it ever since
  • BitBucket – this is our primary service for hosting git repositories. This is also shared
    with the client so that the client is able to have real-time insight into our work
  • GitHub – secondary source code repository
  • GitLab – secondary source code repository
  • SourceTree – our git client of choice


  • Jenkins – Continuous integration server that we use to speed up the process of application deployment (aka delivering a new version of the application to the client and to the application store)
  • BitBucket Pipeline – this is used for integration and deployment automation
  • Fabric/Firebase – we use it for sharing alpha/beta versions of the application with the
  • MS AppCenter



  • Selenium/Appium – automated UI test
  • XCTest – unit tests, performance tests, and UI tests for iOS
  • Espresso and Robotium – used for instrumentation (UI) tests on Android
  • JUnit4, Mockito, Hamcrest, Robolectric – running unit tests on Android
  • Android Monkey – UI robustness testing on Android

Analytics / Reporting

  • In-app analytics services – Google, Mixpanel, Flurry, Firebase:
    each of these services tracks how the users actually use the app. What parts do they visit more often, do they get stuck on some part of the process, and whether they’ve triggered some kind of event, like calling for help, along with the detail of when that happened. These services give us the information we need to know in order to make the app even better with updates, and fix any potential problems in the UX that crop up once the users start using the app
  • Crashlytics:
    the Crashlytics tool is an analytics tool that automatically traces any technical
    problem and crashes within the app. Any problems that the Crashlytics notes in the
    first three weeks from launching the app we will fix completely free of charge
  • ShakeToReport:
    this is our custom-built tool that is integrated into the app during the beta period. When you’re testing the app and run into some kind of problem, you just shake your phone. This module then automatically takes a screenshot of the screen, and you can circle the problem, write notes, add comments, and then submit it. All the information is then translated into a task in our task management tool, so our developers can see it right away and fix it. All the problems you report this way also fall into the three weeks of free bug fixes

UI / UX Design

  • Sketch – alpha and omega of UI design on iOS
  • Zeplin – getting pixel-perfect UI resources is impossible without it
  • Figma – modern and easy-to-use design tool


We are a software agency specialized in developing mobile apps for iOS and Android. But above all, we are a bunch of passionate people driven by technological advances, and solving sophisticated problems.

Our development process is agile and we use Scrum and Kanban methodologies.

Regular code reviews are our fundamental QA measures. Our work includes practices like unit testing and test-driven development. We deliver software with extensive software documentation.

Transparency is high on our list of priorities. And as we said, it goes both ways, inwards and outwards.

I hope this guide helps you to better understand how we work and set up our team and tools. If you have any questions, feel free to contact us at

Written by

Tomislav Tkalcevic

Android Developer

Related articles