Salon Symphony
Salon Symphony is employee-experience software for salons and spas: team chat, tasks, a policy and training library, surveys, events with RSVPs, time-off requests, and onboarding flows. It was built by another team and shipped in December 2023. By early 2024 the fixes and features its founder wanted could not be built on it at all, and Appluex took the codebase over from February to April 2024.
The app was live in both stores, but the code behind it had stopped moving. It sat on a Flutter version so old that several of the requested features were not supported by the framework itself, and a number of open bugs could not be resolved without them. The first obstacle was not even code. That Flutter version would no longer build on a current machine, so the app could not be compiled at all by whoever was asked to change it. Everything the founder wanted was queued behind that, while paying salons used the product every day.
We started with the toolchain, not the backlog. To compile the app exactly as it shipped, we set up a machine running an operating system old enough for that Flutter version to build on, and used it to fix the urgent problems first, releasing them on the version customers were already running. Only once the live app was stable did we upgrade the codebase to current Flutter, work through the breaking changes across dependencies and the iOS and Android build layers, and then build the features the old version could never have carried. Every release went out through the client's own Apple and Google developer accounts, which they hold and control.
A closer look
The order of operations was the whole engagement. An upgrade-first approach would have been faster to describe and worse to live through: it puts the customer on a rebuilt app before anyone has proven the rebuilt app behaves, and it leaves the bugs they are complaining about today unfixed for however long the migration takes. So we split the work in two. Stabilise on the version that actually shipped, because the business is live. Modernise afterwards, when nothing is on fire.
Stabilising meant solving a tooling problem before a code problem. A Flutter release pins the Dart SDK, the Gradle and Xcode versions it expects, and the plugin versions that were current at the time, and modern operating systems drop support for that stack from underneath it. The practical answer was not clever: we found a computer running an OS old enough that the original toolchain still installed and still built. That machine became the maintenance line for the live app, and the urgent fixes went out from it while the rest of the work was still ahead of us.
The upgrade to current Flutter was then a contained project rather than an emergency. Moving that many versions at once means dependencies that no longer exist at their pinned versions, framework APIs that were renamed or removed along the way, and iOS and Android build configuration written against toolchains that have since changed their requirements. We worked through it with the app already stable in production, which is the only comfortable way to do it, and came out on a codebase where the features the founder had been asking for were simply possible.
The app is published under the client's own developer accounts, not ours. That is the arrangement we argue for everywhere on this site: the company whose product it is should hold the store accounts, the signing keys, and the code, so that changing who works on the app is a decision and not a rescue. It is also why this engagement could start at all.
The founder's review on Clutch reads: "We were impressed with their ability to dive into an existing codebase without missing a beat!" and "Essiel and his team at Appluex were able to pick up the pieces and polish our product beyond expectation." The engagement was scoped and it ended in April 2024. Salon Symphony has kept going since, and the version on the App Store today is a later major release that other work has shaped: what we take credit for is the two months that got the product unstuck. The app is live on both stores and has held a 4.4 rating from 7 App Store ratings since its December 2023 release.
Key features
A full diagnosis of an unmaintained Flutter codebase
A build environment old enough to compile the app exactly as it shipped
Urgent fixes released first, on the version customers were already running
An upgrade to current Flutter, dependencies and platform build layers included
Features the previous version could not support, built after the upgrade
Releases through the client's own App Store and Google Play accounts
Common questions
What did Appluex do for Salon Symphony?
We took over an existing Flutter app built by another team. We fixed the urgent problems on the old version the app had shipped on, then upgraded the codebase to current Flutter so the features the founder wanted became possible. The engagement ran from February to April 2024.
Can Appluex take over an app someone else built?
Yes. Inspecting, correcting, and taking over software built by another team is a service we offer. We start by reading and building the code as it is, so the first deliverable is an honest assessment of what can be fixed in place and what needs an upgrade first.
Why fix bugs on the old version instead of upgrading first?
Because the product was live and paying customers were using it. Upgrading first would have delayed every fix until the migration was finished and put customers on a rebuilt app before it had proven itself. Stabilise first, modernise second.
What happens when an app's framework version is too old to build?
The toolchain is the first problem to solve. An old framework release expects old SDK, Gradle, and Xcode versions that current operating systems no longer support, so the practical answer is to reproduce a build environment old enough to compile the app as it shipped, ship the urgent fixes from there, then upgrade.
Who owns the app store accounts?
The client does. Salon Symphony is published under its own Apple and Google developer accounts, and every release we shipped went out through them. We recommend that arrangement to every client: you should hold your accounts, your signing keys, and your code.
Ready to build your app rescue & modernization product?
Tell us about your idea. We'll help you ship it.
Start a project →