Every project I start usually begins with a nagging bit of curiosity. For Vectra, it was a simple "why?": Why does modern web analytics still feel so unnecessarily complicated?
While tools like GA4 are undeniably powerful, they often feel miles away from the actual developer experience. They’re abstracted, rigid, and honestly—a pain to control. I found myself craving something smaller, faster, and more transparent. I didn’t want just another analytics tool; I wanted something that actually felt aligned with how we build products today.
What began as a weekend project slowly turned into a mission: taking a loose idea and shaping it into an end-to-end product.
Solving the Problem, Not the Stack
In the early days, I forced myself to stay obsessed with the problem rather than the implementation. I wasn't trying to build a feature-for-feature clone of what’s already out there. Instead, I wanted to see what a lightweight, session-based platform would look like if it were built from the ground up with simplicity and performance as the only real non-negotiables.
That mindset ended up guiding every decision I made, from the core system design down to the tiniest UI trade-offs.
Thinking in Systems
As the project expanded, I stopped thinking about "features" and started thinking about "systems." Vectra ultimately took the shape of a clean, event-driven architecture; a lightweight tracking SDK, an ingestion layer, structured storage in PostgreSQL, an aggregation engine, and a dashboard to provide clarity.
By designing it holistically, I avoided that classic side-project trap: building a bunch of disconnected parts that break the moment you try to scale. Instead, every layer grew alongside the others.
Where the Real Work Happened
The most interesting part of this process wasn’t writing "Version 1.0", it was the refining that happened afterward.
One of the first real hurdles was SPA tracking. Traditional pageview logic falls apart pretty fast in modern frameworks. I had to rethink how tracking should behave in dynamic environments; making route-based navigation feel "native" wasn't just a feature; it was what made the product feel viable.
Another turning point was the multi-tenant architecture. I went down a few rabbit holes before settling on a shared PostgreSQL model with Row Level Security. It hit that "Goldilocks" zone of being scalable without adding a mountain of infrastructure complexity. Those are the moments that truly shaped the project.
Shifting from Code to Product
As Vectra matured, my focus shifted from solving technical puzzles to making actual product decisions.
I had to start thinking intentionally about defaults and constraints. How do I show metrics so they feel meaningful without cluttering the interface? How do I make settings feel predictable? Even the "boring" stuff; like consolidating account settings or simplifying exports; started to matter more as the system grew. That transition from building features to shaping an experience was probably the most rewarding part of the whole journey.
Performance as a Design Choice
Analytics systems get messy fast as data piles up. I found that staying close to the database layer kept things fast and, more importantly, understandable. Writing raw SQL for aggregations and carefully shaping queries made a massive difference in performance.
It reinforced a lesson I seem to learn over and over: simple systems scale more gracefully than clever ones.
The Takeaway
Building Vectra taught me more about how ideas evolve than any other project. It reminded me to:
- Design systems, not just features.
- Prioritize clarity over being "clever."
- Remember that "product thinking" happens in the small decisions, not just the big milestones.
Ultimately, the most valuable part wasn't the launch; it was finally understanding exactly why every single piece of the system exists.
Where It Stands Today
Today, Vectra handles session-based analytics, custom events, and real-time metrics across multi-project dashboards. But beyond the feature list, I’m most proud of the clarity behind it. What started as a small "what if" became a full product; not because of a rigid roadmap, but through steady iteration and a constant effort to keep things simple.
