BublHub v2 — redesign + migration (in progress)
v2 is a rebuild of the foundations. It’s not only a database migration — the UI and data model are being rebuilt so we can ship more capable features on top of a platform that stays maintainable and migration-friendly.
v2 objective
Rebuild the UI around a new brand direction, migrate away from Firebase to reduce vendor lock-in, and redesign the data model so we can add richer platform features — while keeping the system structured so a future move away from Appwrite stays realistic.
UI rebuild + rebrand
The UI is being rebuilt to match the current brand direction and to stay consistent as features grow. v2 moves away from one-off screens and towards reusable patterns and clearer hierarchy.
- New brand direction translated into a consistent UI language
- Cleaner hierarchy and action placement across journeys
- Reusable patterns so features don’t feel bolted-on
Database migration and redesign
The platform direction needs a more expressive data model than a simple ticketing system. v2 migrates from Firebase to Appwrite to reduce lock-in and redesign the database around the real domain.
- Migration from Firebase (v1) to Appwrite to improve control and reduce lock-in
- Reshaped collections and relationships to support a more complex product
- Designed with future migrations in mind, not just the current vendor
Feature build-out (enabled by v2)
The point of the migration and redesign is to unlock new functionality without the platform becoming fragile. v2 is where the foundations are being rebuilt so feature work feels additive, not risky.
- More capable organiser profiles and workflows
- Clearer operational states and requirements
- Foundations for dashboards and comms
- Data model shaped for growth
- Better boundaries for communities and retention
- Platform features that need real relationships
- Reusable UI patterns across screens
- Backend structure that stays debuggable
- Less rework as the scope increases
Why Appwrite over Firebase (for v2)
The switch isn’t about chasing a new tool — it’s about control and portability. Appwrite gives a backend surface area that fits the direction of the product and makes it easier to keep vendor code contained.
- Vendor calls contained behind small adapters
- Domain rules live in services, not platform glue
- Migration becomes swapping infrastructure pieces
- Collections and relationships designed around the domain
- Clear permission boundaries per entity
- Better fit for workflows beyond basic ticketing
- State-first flows for onboarding and purchase
- Idempotency where it matters (payments, onboarding)
- Clearer debug paths as complexity increases
The engineering direction
The goal is to keep product logic stable and keep vendor code contained. That way the product can evolve without becoming tightly coupled to one backend choice.
- Thin endpoints: authenticate, validate, delegate
- Service layer owns business rules and orchestration
- Adapters contain vendor SDK calls (DB, storage, messaging)
- State-first workflows for key journeys
- Idempotency where it matters (payments, onboarding)
- Status surfaces, retries, and debug paths
- Domain logic stays stable in services
- Infrastructure behind minimal interfaces
- Migrate by swapping adapters, not rewriting features
v2 is ongoing work: the UI and data model are being rebuilt so the platform can grow without getting stuck to a single vendor or a fragile foundation.