Case Study
Hivehub
An open publishing platform where thoughtful writing finds its audience.
The Problem
Medium's paywalled model increasingly buries free content. Hivehub was built as an alternative — a platform where writers publish openly and readers discover through genuine curation, not algorithms optimised for engagement.
Key Technical Decisions
Chose Tiptap over Quill for the editor because Tiptap's extension API let us build a custom slash-command menu for inserting code blocks, images, and dividers — the kind of writing tools technical writers actually need.
Used Firebase Realtime Database (not Firestore) for the feed and follow counts, these are high-read, low-write operations where real-time sync added genuine UX value (follow counts update live).
Used Framer Motion for page transitions and article reveal animations — the reading experience needed to feel deliberate, not snappy.
Challenges & Solutions
Challenge
Tiptap's default output is a JSON document tree, but displaying it required a custom renderer that respected the styling conventions of the platform.
Solution
Built a recursive `TiptapRenderer` component that walked the JSON node tree and mapped each node type to a styled React component.
Challenge
The feed needed to show posts from followed users only, which Firestore's query model doesn't support natively (no JOIN equivalent).
Solution
Stored followed user IDs in an array and used Firestore's `in` operator with batched queries — limited to 10 per batch, merged and sorted client-side.
Outcome
Delivered a fully working publishing platform with rich editing, user feeds, and real-time interactions. The Tiptap renderer in particular became a reusable pattern I've used in later projects.
What I Learned
Firestore's query limitations force you to think carefully about your data model upfront. Denormalising early (storing author info on each post) saved me from painful migrations later.