Case study

Xola, a back office management system for tour operators

Multifunctional booking platform

Time to get a new challenges and go to a new hights

Check it on app store

I received a request from Crowdbotics to help build a mobile app. Besides me as a team lead there was 3 additional developers who worked on this project and a project manager who played a big role of coordinating the work, partially taking the roles of quality assurance and scrum master. Later QA team was scaled to 4 people.

Now the app consists roughly of 55k lines of code, amount of screens is getting close to a 100 with near 300 different state on top. The app is being slowly released by Xola team to their beta clients.

Our main objective is improve experience of Xola customers (businesses) by creating mobile version of a platform.

Feature overview

  • Resource management
  • Scheduling
  • Point of sale
  • Booking
  • Reporting
  • Payment


One man's suggestion

Looking back on what we've accomplished, for the new teams and projects I have a few notes that I want to share.

Before diving head first into development of enterprise level product, start first with a series of decomposition meetings where each screen is taken apart by functionality and compare it with the existing web app. Document it and keep the document up to date. Take multiple meetings if necessary. After that the cost of error will only grow.

It is okay to not have the full picture, build the road while walking on it. Keep having scoping and decomposition meetings. Measure your burndown rate as a metric. The tickets will keep coming. By tracking it, among other things, you will make the development predictable.

Split the screens by functional areas, screens itself (if simple) or related features. Take some time and build UI components with reusability in mind, minimize merge conflicts, parallelize developers. When foundation solidified, take approach of gradual refactor, where update existing components along side new features

Adapt a scrum

Have a daily meetings. During the week have a sprint planning and backlog grooming. On the planning meeting estimate the tickets and decide on what will go on the sprint. On the backlog grooming deal with abandoned, duplicated or similar tickets. On scoping meetings discuss features and how the should work. On demo meetings showcase the functional areas and the whole screens. It is a good idea to have retrospective meetings some time after the demo. I would share some Chinese or Green wisdom, remind about discipline and try to raise up morale and culture.


  1. Weekly backlog grooming
  2. Sprint planning
  3. Dailies
  4. Sprint review
  5. Sprint retrospective


  1. Scoping
  2. Decomposition
  3. Development
  4. Testing


Over the course of development there was plenty of cases where one wound want to cut corners and wrap it up quickly or implement the feature partially, or do not cover all the cases, one must not indulge oneself in such thoughts, one must be disciplined.

Reviewing person should show no weakness and do not bend over such cases to continue enabling it, reviewing person must call it out as soon as possible.

Development workflow

Our ticket, aside from cases of back and forth juggling, will look like this:

  1. Ticket created
  2. Scoping, decomposition and estimation
  3. Ticket put into development
  4. Ticket is ready for review
  5. Ticket is reviewed
  6. Build is created for this ticket
  7. Build is sent to QA
  8. Ticket is merged to develop branch


The app has been build on react-native using typescript functional components.

We used useReducer and useState to create the global state of the app. Thanks for typescript, the dispatch action is type safe with proper enums, some sections of the app consist of internal state that has been handled in similar fashion.

Behind the scenes the screen would look like a stateless functional component as one file, the (view) model file and separate styles, along side there is a snapshot of the component and tests for both model and view.

Each commit that pushed to version control will trigger a build for android and iOS that later will be tested by QA team.


  • react
  • react-native
  • typescript


Teams miss-alignment

On working with multiple teams it is essential to keep them on track and aligned. Perhaps each of them have their own agendas. Do not let that disrupt the workflow, and address it immediately, with that leaving just minor damage.

Keep working on communication, even if it is good enough, there is always room for improvement. It can give so much value.

Document the edge cases and make sure regression testing are hitting those. This is one of the most difficult parts.


While building the app we established a solid and predictable process by which we are able to drive development and deliver the app to market. We will continue on improving and growing per users feedback as well as control the bugs and improve codeba