Why We Document Our Mistakes in Public
Building in private makes it easy to hide architectural shortcuts. Sharing devlogs keeps our engineering honest.
When you build software behind closed doors, it’s dangerously easy to rationalize bad engineering:
- “Nobody will notice if cold boot takes 800ms.”
- “We’ll clean up the database migration logic later.”
- “This extra third-party SDK won’t hurt battery life that much.”
Publishing an open engineering journal eliminates that temptation. It forces us to defend our technical trade-offs in broad daylight before shipping to user devices.
The Real Architectural Constraints
Here are the concrete trade-offs shaping Reflective:
1. Flutter vs. Native Swift & Kotlin
Maintaining separate Android and iOS codebases for an independent studio cuts development velocity in half. We chose Flutter for Reflective because custom canvas rendering gives us exact pixel control over serif typesetting, custom line-heights, and page-turning micro-interactions without duplicating every feature twice.
2. Zero-Cloud Database Migrations
When you don’t run a backend server, you can’t run remote schema migrations or patch corrupted rows via SQL scripts on AWS. Every SQLite schema migration must be bulletproof on the client device. If a local database migration fails during an app update, the user loses their personal diary. That constraint forces rigorous migration testing before any release.
3. Public Post-Mortems
When an update degrades frame rendering or an animation stutters on budget hardware, we won’t bury it in vague changelog notes like “bug fixes and performance improvements”. We’ll post what broke, why the profiler missed it, and how we fixed it.