When the Rewrite Is the Responsible Move

When we started Cause of a Kind, one of the promises was that we would chase meaningful work, not just clean scopes.

There is nothing wrong with ordinary business software. Plenty of it matters. But the agency was built around the idea that we could bring strong product and engineering judgment to mission-driven organizations, especially the ones doing work that deserved better tools than they usually had access to.

That is why the opportunity to work with Best Education Strategies Technology was too good to pass up.

BEST supports people suffering from traumatic brain injury. That changes the stakes of the software. Accessibility is not a polish pass at the end. It is not just contrast, labels, keyboard support, and ADA compliance. Those things matter, but they are the floor.

For this population, accessibility also means cognitive clarity. The product has to work for people dealing with memory issues, attention challenges, fatigue, confusion, sensory sensitivity, and difficulty processing dense information. A screen that looks clean to a typical product team can still be too demanding. A workflow that feels efficient to a developer can still ask too much of the person using it.

The original project began as a mobile migration. BEST had one iOS app that effectively contained four apps inside it, each serving a different use case. The plan was straightforward: separate those experiences into four React Native applications, bring them to Android, and make them offline-ready.

At the time, that thesis made sense. Native apps felt like the right container. Offline support felt important. Separate applications seemed like a cleaner way to serve distinct workflows.

We rebuilt two of the four that way.

Strategize My Life went fine. Pace My Day was harder.

Pace My Day relied heavily on timers. Timers sound simple until they live inside a mobile operating system that can push an app into the background, pause work, manage battery aggressively, and behave differently across devices. The more we saw real usage, the more the original assumptions started to fray.

Users switched devices. A strategy might begin on a tablet, while a timer started on a phone. People wanted their data to follow them. They wanted the system to feel continuous. That challenged the idea that local-only offline behavior was the most important requirement.

The separated-app model created its own friction too. Separate apps on the same device could not simply share one SQLite database. What looked clean in the app store created awkward boundaries in real life.

So we tried to make the architecture more serious. We designed a backend that could receive and reconcile events from different devices. Event sourcing made sense for the problem. If users were generating activity across phones and tablets, we needed a way to capture what happened and rebuild the truth from those events.

Technically, that was the right kind of thinking. Operationally, the mobile surface kept fighting us.

Some users did not update app versions. TestFlight added confusion. React Native gave us push support, but support across many devices, operating system behaviors, and app versions became difficult to reason about. The hardest part was not writing code. It was debugging what was happening in the hands of a nontechnical population that was already dealing with enough.

Then AI-assisted development changed the economics of the decision.

After years of learning, we asked the question that teams are usually afraid to ask: what if the original thesis is wrong now?

Maybe the product should be one suite again. Maybe it should not be native. Maybe offline was less important than sync, supportability, visibility, and the ability to ship fixes immediately. Maybe the humane product was not the one that lived deepest in the phone. Maybe it was the one we could understand, improve, and keep current for everyone.

We rebuilt BEST App Suite as a Ruby on Rails PWA.

That choice changed the shape of the product. Users could still install it as a tile on their phone like an app. But we no longer had to wait for app store updates, version adoption, or TestFlight confusion. When something needed to change, we could ship it. When something went wrong, we had more visibility. When users moved across devices, the product could rely on a shared server and database instead of pretending every device was an island.

Most importantly, the rewrite let us carry years of user learning into the new architecture. Timers and data could sync across the suite. The apps could share a foundation. The product could support a physician portal where people suffering from traumatic brain injury could share their data and progress with the doctors caring for them.

That is not a small detail. It changes the product from a set of tools into a bridge between a person and their care team.

The old conventional wisdom says you should never rewrite. I understand why. Rewrites often become expensive ways to forget everything the first version taught you.

But AI-assisted development changes the math when the team is disciplined. It does not make rewrites automatically wise. It does make it possible to move faster through the parts you now understand, while spending more attention on the parts that actually matter.

In this case, the rewrite was not an ego decision. It was a product decision. We had years of evidence. We knew the pain points. We knew where native mobile was hurting support. We knew where the separated apps were fighting the user experience. We knew that a shared backend could make the suite more coherent.

So the second version came out better.

It is easy to talk about AI in abstract productivity terms. Faster tickets. Faster code. Faster prototypes. This project is a better example of what that speed is for. It let us revisit a hard product with more knowledge, rebuild it in months, and give users something clearer, more maintainable, and more connected to real care.

That is the part that still feels incredible. Software is often sold as efficiency. Here, the work is more human than that.

Good software meets users where they are. For BEST App Suite, that meant admitting what the first architecture taught us, letting go of the original thesis, and rebuilding the product around the lives of the people it was supposed to help.