Stalled 2-year project into a working product in 6 months
Role: Technical Lead
Client: The Break
Live site: https://kayaking.thebreak.org.au
Tech Stack:
React Native (mobile app for iOS and Android), Supabase (backend platform), Redis (caching for weather and other dynamic content), Cloudflare Pages (frontend hosting), Open-Meteo (weather data)
Context
The Break is an organisation that provides services to support people's mental health. One of them is guided kayaking trips.
The project was a kayaking application in two parts:
A web app for guides, to organise and manage trips.
A mobile app for customers, to find upcoming trips, opt in or out, get alerts when conditions look unfavourable, and track the progress of their trips.
Until then, The Break used Facebook as its main way of reaching its audience. The goal was to bring that process into a proper web application.
The problem
Planning a trip took guides hours. Before inviting anyone, a guide had to check the kayaking site for weather and hazards, and sometimes that meant going there in person.
The project had stalled. It had been running for two years with very little progress. I joined as a volunteer at its lowest point:
The team was mostly students working on their first professional project. Some were losing motivation, and a few were about to leave.
There were no development processes, no CI pipeline and no proper branch structure. Everyone worked separately, so nothing came together as one application.
Planning had no real structure. The project document was barely used and out of date, and the project manager was non-technical and couldn't give the team technical direction.
The existing product wasn't something we could build on.
The Python Flask server had hand-built authentication that didn't follow OAuth2 properly. Sessions never expired and the APIs were open to IDOR attacks.
The weather module relied on a poorly documented API and had broken when that API changed.
The email module didn't work, and there was no mobile app because the team didn't know where to start.
The web frontend worked, but the design wasn't up to what a professional organisation needs.
What I did
I worked through this in five decisions. Each one is what I chose and why.
Decision 1: Bring everything into one trunk
What I chose: I set up a proper branching structure and merged the fragmented code from separate branches into a single trunk. We followed trunk-based development, and I taught the team how to raise pull requests and use Git properly.
Why: Everyone was working on their own piece because nobody wanted to step on anyone else's toes. Trunk-based development is a straightforward process, which suited a team new to professional work.
Decision 2: Replace the outdated project document with a real backlog
What I chose: I worked with the project manager and the business analyst to build a product backlog and sprint backlogs. I set up a Kanban board, assigned tasks across the team, and worked closely with the project manager to refine the timelines.
Why: The existing project document was out of date and barely used. The team needed a shared, current view of what to work on and when.
Decision 3: Audit what existed, then rebuild from scratch
What I chose: Before anyone started on tasks, I reviewed the existing server and frontend. Then I decided to rebuild everything rather than patch it.
Why: The problems ran through the whole stack: insecure authentication, a broken weather module, a non-working email module and no mobile app. Patching would not have given us something we could trust.
Decision 4: Design first, then choose tools that are easy to maintain
What I chose: I started with architecture diagrams and the database design, then picked mostly out-of-the-box tools:
Supabase as the backend platform
Redis to cache dynamic content such as weather
Cloudflare Pages to host the frontend
Open-Meteo for the weather data
React Native for the mobile app, so one codebase serves both iOS and Android
The database was built around five core models: users, trips, sites, site locations and site conditions. Everything else, such as role-based access control and notifications, was built around those five.
Why: I expected to leave the project eventually, so I chose tools that are easier for The Break to maintain without me. Keeping the core models small kept the design easy to understand and extend.
Decision 5: Turn raw weather data into a risk score
What I chose: The original app showed weather and wind speed for each kayaking site, and it was up to the viewer to decide whether that was safe. I introduced risk levels: a system that combines factors such as wind speed, wind gusts and visibility into a single risk score, so anyone can see at a glance whether a site is safe.
Why: I have no kayaking experience, and raw numbers on their own didn't tell me whether a site was safe. If it wasn't intuitive for me, it wouldn't be for many customers either.
Results
We rebuilt the existing application and added more in 4 months. Users could set up trips against kayaking sites, invite friends and see whether a site was safe.
The CEO of The Break was delighted with the demo and suggested further features: drawing out trails for trips, GPS tracking on the phone during a trip, and an easy way to find kayaking sites with favourable conditions nearby.
We delivered that feedback 2 months later and handed the product over to The Break to maintain full time.
| Measure | Before | After |
|---|---|---|
| Project status | 2 years, very little progress | Working product in 6 months |
| Time commitment | n/a | 1–2 hours a day per developer |
| Platforms | Barely functioning web app, no mobile app | Web app for guides and mobile app for customers (iOS and Android) |
| Judging site safety | Raw weather and wind values | A single risk score at a glance |
| Way of working | No branch structure, no CI pipeline, out-of-date project document | Trunk-based development, Kanban board and sprint backlogs |
What I’d do differently
I'd involve the team more in my initial designs. Because the project had been stalled for two years, I felt I had to take control and decide where people were needed. That worked: we finished a two-year stalled project within 6 months, with each developer spending only 1–2 hours a day on it. But I'd bring the team into the early design decisions, so they help shape them as well as carry them out.