Choosing reliability over more features
When recurring failures affected core workflows, I paused expansion, returned to a stable version, and brought in outside expertise to investigate the underlying problems.
Read the case study →The problem
Parents manage information and tasks across home, school, healthcare, and therapy. We envisioned one place to keep important information and coordinate with people helping care for a child. The challenge was deciding what families needed most and delivering it consistently.
Finding and prioritizing needs
I conducted Zoom interviews and individual calls, gathered survey and in-app feedback, and met parents through partner events and free care-binder classes. I looked for recurring needs, weighed essential workflows against requests that could wait, and refined user stories for our 7-person engineering and product team. We worked on experiences such as medication reminders and the Care Circle.
The decision to pause
Testing repeatedly surfaced failures in features that appeared ready. Problems sometimes reappeared or disrupted other parts of the app after release. An intern suggested that we stop building and fix what we had; a customer expressed the same priority. I paused new feature work and returned to an earlier, stable version over a weekend to minimize disruption. Users had to log in again, and we accepted a smaller feature set while addressing reliability.
Resetting the work
I brought in an external development team, Empeek, to review the application and tackle persistent problems. Its scope placed existing logic ahead of new features: medication reminders were inconsistent on subsequent days, notifications arrived silently, notification taps led to a default screen, and task reminders did not continue until completion was confirmed.
The external review exposed gaps in code documentation. Developers had difficulty tracing earlier changes, so I pushed for clearer documentation and more consistent working practices. The scope also flagged inaccurate active-user calculations, reinforcing the need for dependable measurement.
What I learned
Listening to users continues after a feature ships. The most consequential decision was to stop adding to the roadmap when the basic experience was not reliable enough. Usability, testing, maintainability, and credible metrics are all part of the product.