This is the deeper story behind my Family Dashboard project. The case study shows the product at a high level; this note focuses on what it took to make the dashboard useful in daily life for more than 18 months.
The real problem
When we relocated to Switzerland with kids, we had to relearn ordinary routines: school schedules, weather decisions, public transport timing, recycling days, activities, appointments, and everything that happens before leaving home.
The problem was not that information was unavailable. It was scattered across calendars, weather apps, transport apps, school notes, and memory. We needed the right context in the right place at the right moment.
That is why the dashboard lives by the entrance door. It is visible exactly when someone is putting on shoes, checking whether to take an umbrella, or figuring out whether the tram leaves in 3 minutes or 13.
Product decisions that mattered
The dashboard had to be ambient, not another app to manage. It needed to be readable from a few steps away, reliable in the morning, and simple enough for kids to understand.
The strongest decisions were not visual details:
- Put the screen where decisions happen.
- Aggregate data server-side so the interface stays simple.
- Cache or degrade gracefully when external APIs fail.
- Show fewer things, but make them more relevant.
- Design for a cheap always-on device, not a powerful desktop browser.
Why self-host
I initially considered a hosted setup, but local hosting made more sense for this use case.
The dashboard runs on a Raspberry Pi, displayed on a used Kindle Fire HD. That gave me more control over local data, uptime, maintenance, and future smart-home integrations. It also forced a more practical architecture: if something breaks at 7 AM, I need to understand and fix it.
The setup:
- SvelteKit frontend
- Node.js data layer
- Raspberry Pi hosting
- Google Calendar integration
- weather and Swiss transport APIs
- custom 3D-printed wall mount
API aggregation
The first version tried to fetch too much directly from the frontend. That made loading states and errors harder than they needed to be.
The better model was a backend aggregation layer. The server gathers weather, calendar, transport, and routine data, then returns one clean response to the dashboard UI.
That pattern made the product easier to maintain. It also made failures easier to handle. When an external API changes or fails, the interface can show cached data, stale-data indicators, or partial content instead of simply going blank.
Designing for daily reliability
An always-on household product changes the design priorities. It is not enough for the interface to look right in a demo. It has to stay useful after weeks of automatic refreshes, API changes, Wi-Fi issues, and hardware limits.
The Kindle Fire constraint was especially useful. Weather animations had to be efficient enough not to slow the device down over time. The final approach uses a limited set of animation elements that can be reused instead of constantly creating expensive effects.
The lesson was clear: constraints made the product better. A cheap display forced better performance, simpler states, and a more disciplined interface.
Family user testing
The dashboard is used by people with different priorities. I care about transport timing and work events. My wife cares about school routines and family logistics. Our kids need visual cues they can understand without reading every label.
Internationalization was also more than translation. Supporting English and Russian meant dealing with different wording, typography, and assumptions about what information matters first.
This is where the project became more than a technical exercise. It forced real product judgment: what should be visible, what should be hidden, what should be local, and what should be understandable at a glance.
What changed at home
After 18+ months, the dashboard became part of our household routine.
It helped reduce morning stress, gave our kids more independence, and made our transition to Swiss life smoother. The product works because it is built around a real recurring decision point, not because it has many features.
The most useful part is still simple: shared context, always visible, exactly where we need it.
What I would do earlier next time
I would add basic health checks from day one. When a family depends on something every morning, you need to know when data is stale or a service is down before someone asks why the screen is wrong.
I would also formalize API adapters earlier. External services change. A small adapter layer is cheaper than letting each UI component learn every provider’s quirks.
Why this matters for product work
Family Dashboard is a personal project, but it proves the same pattern I care about in professional work: a useful product starts with system understanding.
The system here included family routines, transport timing, weather, school schedules, hardware limits, APIs, languages, and the physical location of the screen. The interface only worked after those constraints were understood.
That is the same shape of problem I enjoy most: turn a messy technical and human system into something people can trust and use.
