Overview
The Problem
In 2009, expressing yourself visually on the web meant wrangling HTML and CSS, hiring a developer, or accepting the rigid templates that blogging platforms imposed. Creative people had big ideas but no blank canvas. MySpace had shown there was hunger for personal expression online — but its approach was chaotic, and everything that followed locked users into increasingly uniform boxes.
We wanted to give anyone — musicians, artists, writers, fans — the ability to create a page that looked exactly the way they imagined it, and to share that with a community that would discover and appreciate it.
What I Built
Drag-and-drop creation tool
The centerpiece of NewHive was a freeform, browser-based design tool I built from scratch. Users could place text, images, video, audio, and embeds anywhere on a canvas. Elements could be layered, resized, and styled without touching code. Getting this to feel fluid and reliable across browsers — before flexbox and CSS grid were viable — required deep investment in the rendering model and event handling.
Social graph and feeds
Creation alone wasn't enough. I designed and implemented the social layer: following, discovery feeds, remix/reblog mechanics, tagging, and comments. The feed system had to stay fast as the corpus grew, which drove careful schema design in MongoDB and query optimization as usage scaled.
Infrastructure and scaling
I built the original infrastructure on AWS and later integrated GCP services. As traffic grew I implemented caching strategies, CDN delivery for user media, and background job processing for things like thumbnail generation and notification delivery. The goal was always to keep the creation experience snappy regardless of load.
Technical team and hiring
As the company grew I hired and managed the engineering team, established code review practices, and kept the architecture coherent as more contributors came on board. I stayed hands-on in the codebase throughout.
The Platform in Action
These videos show NewHive as users experienced it — the creation tool and the community around it.
Challenges
Freeform layout across all screens
Absolute-position freeform layout is hard to reconcile with the diversity of screen sizes. Pages built on a 1280px desktop could look broken on mobile. We invested heavily in responsive rendering, but in hindsight a constrained grid system — with creative freedom within columns rather than across a boundless canvas — would have produced better results with less engineering effort and more consistent user output.
Viral growth vs. retention
NewHive had genuine viral moments: TechCrunch coverage, interactive pieces that spread across Tumblr and Twitter, artists using it for launches. But spikes in traffic don't build a sustainable platform. The deeper technical challenge was building features that kept users coming back — reliable performance, a feed that surfaced content people cared about, and a creation tool that rewarded continued investment. Retention is an engineering problem as much as a product one.
Monolith growth
Like most startups, we started with a single application. As the team and feature set grew, the codebase needed careful tending to avoid becoming a liability. I established patterns for keeping concerns separated and the data model coherent, but managing that evolution while shipping new features was a constant balancing act.
What I Learned
Schema design is load-bearing
The decisions made in the first few months about how to represent users, content, relationships, and events shaped everything that came after. Getting the data model right early — or refactoring it carefully when it was wrong — had outsized impact on what was possible at scale. This has informed how I approach every new system.
Build for the maintainers
Code that ships fast but is hard to reason about accrues debt that eventually slows everything down. NewHive taught me to value clarity, testability, and predictable behavior over cleverness — and to build systems the next engineer (often future me) can understand and extend confidently.
Startup CTO scope is total
As the sole technical cofounder for much of the company's life, I touched everything: architecture, product, hiring, vendor relationships, security, analytics, and customer-facing tooling. That breadth gave me a systems-level view of how engineering decisions ripple into business outcomes — a perspective I bring to every technical role I take on.