In our mission to continually develop our technical skills at Redpill Linpro, we saw an opportunity to develop an app that would benefit boat owners while also providing our developers with valuable experience. During periods in between consultant assignments, we transform this "standby time" into a productive projects. We committed to using the latest technologies and best practices, while also contributing to the open-source community.

Developing value

Working as a consultant can sometimes mean having time in between assignments. This 'standby mode' can be challenging for both the employee and the employer. At Redpill Linpro, we take care of this time by facilitate self-learning and encourage professional growth, to always provide value to all our employees. Last spring, this resulted in the creation of an app that would be of benefit to boat owners - just in time for the summer holidays. Additionally, we wanted to express our commitment to open-source projects by creating our own in-house prototype of a well-designed, robust, and accessible mobile app, using the latest technologies and best practices.

But how can you go about creating an app when people only have limited time to contribute before starting a new assignment? Well, we figured that doing this as an open-source project, using the same work methods as those used on community version control platforms such as GitLab, would be the ideal way to do it. We would not hold standups or track time, but would rely solely on people's voluntary commitment and their willingness to learn new things.
We created a set of small tasks in GitLab’s task management module, which would serve as the starting point and grow over time. We then assigned these tasks one by one to whoever had the time to do them. 

We chose to create a boating log app because there was no existing digital solution for logging boat trips, presenting a significant market opportunity. Boat owners currently log their trips manually in a logbook. Some of our developers own a sailing boat or a motorboat, providing us with firsthand experience of the needs and requirements for this particular app.

Choosing techstack

The first task was to choose the best frameworks for the backend and frontend. We aimed to provide the app's developers with a thorough understanding of the most sought-after skills in the market while maximizing the learning outcomes from the project. This led us to select Kotlin with Ktor for the backend, running in Docker containers and hosted on an OpenShift community distribution provided by our well-known Redpill Linpro Nordic Cloud. For the user application, we wanted a cross-platform mobile framework, starting with Android but with the option to expand to iOS and web browsers in the future. We chose React Native, one of the most requested skill-set for frontend development today. React Native is easy to set up for new developers and offered quick and easy developing with lots of supported libraries. By using a web development language, developers would face minimal requirements to learn native code for multiple platforms, and the experience gained would be transferable to other fields in the future.

Our goal was to ensure that the tech tools used in the project could be applied to live projects to gain real experience with these tools and broadening our tech stack expertise. For example, we aimed to implement continuous integration with automated tests and automated deployment to speed up delivery times and minimize manual work. One team member was assigned the task of identifying a good set of tests and the tools needed to achieve this.

We ended up using GitLab’s integrated DevOps platform, running a simple container with a Gradle image to build the project and run tests inside this container. For image building, we used a tool called Kaniko, which builds Docker images from other images. For delivery, we utilized GitLab’s integrated container registry and set up an image stream in OpenShift that listens for changes and automatically deploys the newest image.

We employed three branches in our repository: develop, stage and main. All tests are run before each pull/merge request on the develop branch to ensure that no broken code is committed unintentionally. We have established routines for pushing to the stage branch, which triggers deployment to a testing environment before pushing to production. This process helps avoid downtime if broken code somehow passes through the pipeline.

This solution is very elegant once set up correctly, requiring no additional CI/CD software and providing fast release times. Best of all, any contributor can manage it by simply pushing code to a dedicated branch.

Documentation is key

Using a remote process without a dedicated team lead can be challenging, especially if everyone has their own way of writing code, handling secrets (like passwords), writing commit messages, and documenting (or not). As a result, we invested a good amount of time creating a comprehensive Markdown README file outlining our project standards. This was done incrementally, allowing each new contributor to find answers to their questions or challenges. While this might seem time-consuming initially, it ultimately reduces the time needed to onboard new team members and shortens the time required to return to the code after being away from the project.

Another priority was to incorporate feedback functionality to ensure the app performed as well as possible. To achieve this, we used SleekPlan to transfer the most upvoted feature requests to our Kanban board in GitLab, where contributors can pick and choose from them. Some of the tasks for adding new features included switching to Google Maps (for Google Cloud Platform experience), adding monitoring with Grafana, implementing frontend tests with Jest, and incorporating token rotation, hijacking detection, and passwordless login (for enhanced security).

We are so proud to say that the app was released June 6th 2024 and quicky gained over 200 users and was published in Seilmagasinet and Kode24.
You can download the app on Google Play.