<aside> 📌

We will use a MonoRepository for this project

one product, two tightly related codebases, one team, and shared planning. A Gradle multi-project build is designed for exactly this kind of setup: one root project with subprojects defined in settings.gradle.kts. Spring’s official multi-module guide shows the same general pattern on the backend side, and Android’s docs explicitly recommend multi-module organization for larger apps.

</aside>

A Gradle multi-project build is designed for exactly this kind of setup: one root project with subprojects defined in settings.gradle.kts. Spring’s official multi-module guide shows the same general pattern on the backend side, and Android’s docs explicitly recommend multi-module organization for larger apps.

Use a monorepo with clear top-level boundaries:

repository structure / layout suggestion

• apps/android and apps/backend make ownership obvious
• libs/ is where shared internal modules live
• docs/ keeps architecture, API notes, ADRs, and setup docs out of the code folders
• infra/ is a good place for Docker, deployment, local dev config, DB setup, and scripts

<aside> 📌

Gradle’s multi-project model supports this root/subproject structure cleanly, and version catalogs are the right way to centralize dependency versions in the repo.

</aside>

Split Android and backend into modules early

Do not start with one giant android module and one giant backend module if you already know the project will grow.

For the backend, Spring Boot works well in a multi-module Gradle project, with reusable library modules and an application module.