One of my first hands-on projects after joining a speech therapy company in 2018 was... figuring out where we actually worked.
Sounds simple. It was not.
I started with a PDF that said we served 16 school systems. Except it only listed 15.
So I started digging. I compared documents. Asked questions. Cleaned up names. Reconciled duplicates. And then came the edge cases.
Some locations were public schools. Some were private schools. Some might have been charter schools. Some barely existed online. Some were daycares.
Which raised another question: is a daycare a "school" in our system? Or should it be its own category?
Eventually I landed on 17 school systems and 72 individual locations across Tennessee.
Then I geocoded every one. The idea forming in my head was pretty simple: I wanted a map of Tennessee where you could hover over any location and immediately understand what was happening there.
How many therapists were there? How many students were being served? What did staffing look like? What were the KPIs?
But before you can build the cool map, you have to answer the boring questions.
What exactly is a school system? What exactly is a location? Can a private school belong to a system? Where does a daycare fit? What relationships actually exist between all these things?
That experience reinforced one of the strongest principles I have about building software (and that I have been very particular about at Ambiki): Spend more time than you think you need to getting the data model right.
If you correctly model the things that exist in the real world and the relationships between them, a lot of what comes later becomes much easier.
Dashboards become easier. Reporting becomes easier. Filtering becomes easier. New features become easier.
But if you get the underlying model wrong, you spend years working around decisions you made before you fully understood the problem.
The visible part might eventually be a beautiful map.
The real work started with figuring out why a PDF said 16 when I could only count 15.