How it started
It began as an ordinary user request. A mom wanted to add the child’s dad and grandma — so they could also work with the child and see what was going on.
The simplest answer was an “invite user” button. But once I started digging, it turned out the problem went deeper, and solving it locally would mean fixing the symptom, not the cause.
What was wrong with the old model
In the old architecture everything was tied to the parent’s account: parent account + child profile, with the expert attached on the side.
In practice, this broke in a simple scenario. To leave the child with grandma for the weekend along with the app, mom had to give grandma her own account — login and password. No separate access, no control over what grandma can and can’t see. All or nothing.
The same limitation capped work with specialists, and even more so with therapy centers. The product was built around one parent’s account — but a child’s real life looks different. There are many adults around them: both parents, relatives, a nanny, a specialist, a center. And they all work with the same child.
How I got to the solution
I often think through analogies with the physical world, and that’s what worked here.
A child has a medical record. It sits in mom’s drawer. You go to the doctor — you hand the record to them. The child goes to grandma for the holidays — the record goes along. One record, many people around it, and each of them works with it in their own way.
I looked at how medical records work in health apps and realized: this model — “record in the center, people around it” — is exactly what FlyMind needed to keep growing.
That’s how the key decision was born: the child profile stops being an appendage of the parent’s account and becomes the center of the whole product.
The decision came from reality, not from my head — first from parents’ requests, then from a request from one of the centers. I connected the dots and proposed flipping the model.
The new architecture
The child profile is the center. Everything lives there: the intake questionnaire, characteristics, goals, observations, trainings, materials, progress, logs, recommendations.
Around the profile are connections: parents, relatives, a nanny, specialists, doctors, centers. Each has their own account. The profile is one, shared.
What this changes in practice: grandma no longer needs mom’s login. She has her own account and connects to the child’s profile as a separate person. All the adults see the same context and can act in a coordinated way.
And this model makes possible what wasn’t possible before:
Flexible access rights (planned). Each connection gets its own scope. Grandma only needs the visual schedule. A nanny doesn’t need to see which protocols were run or which other profiles the child is connected to. A specialist gets full professional access. One profile, different roles.
Data authorship. Who entered which data. This will let a specialist see how the child behaves with different people — and that’s clinical value, not just convenience.
Where design met monetization
The most important part of this case: the architectural decision directly redefined the monetization model.
The subscription used to be tied to the account. I moved it to the child profile.
Now the logic is simple. The main parent pays — for the child profile. Connecting relatives — grandma, a nanny — is free. They’re linked to the profile but don’t pay. Connecting a specialist raises the plan, but the main parent still pays.
And if a center connects to the profile, the center pays. Because in this scenario it’s the center that brings the parent into the product: the parent starts using the app because their center uses it. In terms of monetization, a center is always the higher-value customer, and the model reflects that.
From the outside this change is almost invisible. But under the hood it completely changes how the product can earn and scale — and opens a direct path to working with ABA centers, which now attach to the child profile rather than to a random “parent account + some expert” pairing.
The hardest part
The hardest part wasn’t designing the system — it was defending it to the business.
The business’s first reaction was blunt: if relatives connect for free, we’ll make less money. That’s a fair objection.
I argued from convenience and sensible monetization. We don’t lose money on free connections — we remove the barrier that kept the product from taking root in the family at all. The more adults actually work with the child through the app, the deeper the product is embedded in family life and the higher the retention. Real revenue comes from where it belongs — specialists and centers. The business agreed.
I deliberately left access rights for later: technically it’s the heaviest part, and engineering had higher priorities. The architecture is designed so they can be added later without breaking the model.
What I took away
Sometimes the decisions that change a product aren’t visible from the outside. You can’t show them with a beautiful screen — visually, it looks like nothing happened.
But these are exactly the decisions that change the whole product: how it works inside, how users interact with it, and what growth opportunities it opens.
That’s what happened here. One change to the data model redefined the user experience, monetization, and the strategy for working with centers — while almost nothing changed on screen.