Skip to content

What Deploying TimeSense Taught Me

· 1 min read · 0 views

An architecture diagram can make every boundary look clean.

Deployment reveals where the real boundaries are.

With TimeSense, production work exposed issues that were easy to miss in isolation: Firebase configuration across three clients, native Apple signing, background worker behavior, OAuth token refresh, database migration ordering, widget process boundaries and environment-specific SDK compatibility.

None of those problems invalidated the architecture. They clarified it.

For example, the iOS widget could not simply reuse an in-memory authentication token from the main app because it runs as a separate extension process. The solution was a small shared snapshot—not a second authentication system inside the widget.

That is the difference between conceptual architecture and operational architecture.

The tradeoff of shipping early is encountering imperfect assumptions sooner.

The benefit is that the system improves based on reality rather than prolonged speculation.

Build the diagram. Then put the system under load, permissions, devices and real users.

What deploying TimeSense taught me: a clean architecture diagram compared with production reality, including authentication, background workers, widgets and extensions, migrations, OAuth refresh, and mobile constraints, followed by a cycle of ship, learn, improve, and repeat.


Originally posted on LinkedIn.