Decision Journal
Good engineering decisions are easier to trust when the rejected options are visible.
flowchart TD A[Decision] --> B[Context] B --> C[Alternatives] C --> D[Tradeoffs] D --> E[Outcome] E --> F[What changed?]
Teams, organizations, roles and user actions were becoming harder to reason about from UI requirements alone.
Add per-screen checks as features were built.
A permission model adds upfront design, but prevents hidden inconsistencies across the product.
RBAC became a product concept that technical and non-technical stakeholders could discuss.
The project needed authentication, fast iteration and managed operational primitives more than custom infrastructure.
Build a traditional backend immediately.
Firebase accelerates early product work, but requires discipline around data modelling and escape paths.
The team could focus budget on product behavior while keeping future Cloud Run boundaries available.
The first version proved the product and revealed the real operating model. Keeping the first architecture would have preserved speed in the short term and debt in the long term.
Patch the existing implementation and defer platform work.
A rebuild slows visible feature work briefly, but creates a cleaner foundation once the domain is understood.
The architecture could support multiple events, permissions and reusable workflows.
The client wanted a non-standard creative direction and each summit needed to feel different without requiring five completely separate design systems.
Use static illustrations, gradients or conventional hero sections.
Shaders required more careful performance handling and responsive testing, but created a stronger identity while staying componentized.
Each summit could have a distinct visual atmosphere while the platform remained technically unified.
DeFi Connect 2025 contained five summit experiences, but the public platform still needed shared agenda, speaker, session and ticketing behavior.
Build five separate websites or five largely independent page trees.
A shared platform required more upfront content modeling and component architecture, but reduced delivery risk and made agenda and speaker integration more consistent.
One unified platform supported five distinct summit identities while sharing Sessionboard integration, layout primitives, agenda rendering and ticketing flows.