Building Vibe Village: Sometimes the Best Architecture Is What You Don’t Build
Vibe Village combines AWS serverless architecture with Apple SharePlay to create synchronized social music experiences. This is the story of the architectural decisions behind it, what I chose not to build, what I would do differently, and where the platform goes next.
What happens when a family ritual becomes a software architecture problem?
In late 2024, I was pursuing CTO certification at Cambridge Judge Business School. Midway through the program, I decided that a working application would give me something tangible to test what I was learning.
The idea came to me one weekend while my wife and her family were participating in one of their regular music battles over FaceTime. Two people would choose songs, everyone else would listen, debate, vote, and inevitably argue about which song won.
I remember thinking: this is already an application. Nobody has built the interface yet.
That observation eventually became Vibe Village, an iOS platform designed around shared music experiences, including Music Battles and Listening Sessions.
But building Vibe Village taught me something I did not fully appreciate when I started.
Architecture is not simply the collection of technologies you choose to deploy. Some of the most consequential architectural decisions involve deciding what not to build at all.
Start with the experience, not the infrastructure
One of my earliest architectural questions was how to coordinate a live music experience among geographically distributed participants.
The conventional answer could have led to a substantial backend coordination layer. I could have built services for participant state, playback position, synchronization, session membership, recovery, and real-time event distribution.
Instead, I asked a different question:
What capability already exists that solves this problem better than something I would build myself?
Because Vibe Village is centered on iOS, Apple's FaceTime and SharePlay capabilities provided much of the answer.
SharePlay gives the application a native mechanism for coordinating participants during a shared experience. Vibe Village uses that capability for ephemeral, latency-sensitive coordination such as synchronized playback and interaction flow.
That allowed me to draw an architectural boundary that remains fundamental to the platform:
SharePlay coordinates. AWS persists and operates. AI reasons and enriches.
The backend does not need to become the synchronization engine for every interaction occurring among participants.
That reduced infrastructure complexity, but it also introduced an important tradeoff. SharePlay ties this part of the experience to Apple's ecosystem and imposes constraints that a completely custom coordination platform would not have.
Architecture is rarely about eliminating tradeoffs. It is about choosing the tradeoffs that best fit the problem you actually have.
Once those responsibilities were separated, the architecture became much easier to reason about. SharePlay could coordinate the real-time participant experience, while AWS provided the durable application, compute, data, and operational capabilities around it.
Vibe Village uses a serverless, event-driven AWS architecture, with compute distributed across four U.S. Regions and selected data replicated based on resilience requirements.
Serverless first, unless the requirements dictate otherwise
I have a strong architectural preference for serverless systems. My default is to start by asking how a workload can be built serverlessly, then let the requirements push the architecture elsewhere when they justify it.
That was the approach I took with Vibe Village.
Once real-time participant coordination was separated from durable application state, a serverless AWS architecture was a natural fit. Vibe Village uses an event-driven backend built around services including Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. Amazon CloudWatch and Amazon EventBridge support the monitoring and alerting framework.
The Lambda compute layer is deployed across four U.S. AWS Regions, spanning two East and two West Regions. Selected DynamoDB tables are replicated where the availability requirements justify it.
The word selected matters.
I did not replicate every resource just to describe Vibe Village as multi-region.
Serverless compute makes geographic deployment comparatively economical because deploying Lambda functions into another Region does not mean maintaining another continuously running compute fleet. Data replication requires more careful consideration because replication introduces additional cost, consistency concerns, and operational complexity.
The design principle became:
Distribute where resilience creates value. Keep things regional where it does not.
Why I didn't use AWS Local Zones
During an architecture discussion with another AWS builder, Local Zones came up as a possible way to simplify geographic deployment and bring workloads closer to users.
It was a good question, and I spent time thinking it through.
Ultimately, I realized I was looking at two different architectural problems.
The multi-region footprint primarily addresses resilience and geographic distribution.
Local Zones primarily address proximity for workloads where placing infrastructure closer to users provides meaningful latency benefits.
For Vibe Village, the most latency-sensitive coordination isn't occurring through my AWS backend. SharePlay handles that interaction among participants.
Introducing another deployment topology therefore would have added architectural complexity without addressing a demonstrated bottleneck.
The lesson wasn't that Local Zones were inappropriate technology.
The lesson was simpler:
Don't optimize network geography until network geography becomes a measurable constraint.
Keep generative AI out of the real-time critical path
Calling Vibe Village an AI-enhanced platform creates another architectural question: what happens when the AI is slow?
My answer was that the core shared experience should not care.
Generative AI introduces nondeterministic latency, rate limits, provider dependencies, and failure modes that differ substantially from conventional transactional application services.
I didn't want thirty people sharing a music experience waiting for a foundation model before playback or synchronization could proceed.
Vibe Village therefore uses AI primarily to prepare and enrich the experience rather than control it.
AI can assist with capabilities such as battle curation, adaptive trivia, and dynamic content. Some AI work can be performed before the exact moment at which its output is consumed.
The core synchronization path does not require an LLM response simply to keep participants together.
That produces an intentional degradation model.
When AI is healthy, users receive the shared experience plus AI enrichment.
When an AI capability is degraded, the affected enhancement can degrade without necessarily taking the underlying shared experience with it.
That distinction will become increasingly important as Vibe Village evolves.
What I would do differently
Would I build Vibe Village exactly the same way if I were starting today?
No.
Not because the fundamental architecture was wrong, but because operating and evolving the system exposed boundaries I would define much earlier.
I would establish state authority earlier. In a distributed shared experience, identifying who owns a state transition, how runs are identified, how operations remain idempotent, and what belongs to ephemeral versus durable state becomes increasingly important as features accumulate.
I would treat observability as product architecture from the beginning. Health telemetry, alerting, operational events, and signals representing actual user impact should not be plumbing added after the application becomes complicated. They are part of the system.
I would formalize the multi-region policy sooner. Rather than allowing geographic distribution to evolve organically, I would explicitly define which capabilities must replicate, which can fail over, and which should intentionally remain regional.
I would establish AI boundaries earlier. Model providers should be replaceable. Graceful degradation should be deliberate. Expensive or latency-sensitive inference should be moved away from critical interaction paths whenever possible.
And perhaps most importantly:
I would build less.
Every component introduces another failure mode, another operational concern, another security surface, and another thing someone eventually has to understand.
Complexity should have to earn its place.
From AI features to music intelligence
The next stage of Vibe Village is forcing another architectural evolution.
Today, foundation models can provide impressive general purpose reasoning. But I don't believe the durable intelligence of Vibe Village should live inside any particular model.
The durable asset is the context around the experience: music knowledge, session context, provenance, interaction patterns, and eventually the first party signals generated as people actually experience music together.
That is leading toward capabilities such as Ask Vibe, richer retrieval augmented generation, and a progressively more contextual intelligence layer.
The longer term question becomes particularly interesting when the unit of analysis changes.
Most recommendation systems ask:
What does this individual like?
A shared experience creates a different problem:
What might this particular group enjoy together?
That is not necessarily the average of everyone's individual preferences.
As Vibe Village evolves, I am increasingly interested in intelligence that can reason about the collective experience without reducing a group to an averaged individual.
Foundation models will remain useful components of that architecture. But they should remain replaceable components.
The context, knowledge, provenance, and interaction intelligence should belong to the platform.
The lesson I keep coming back to
When I began building Vibe Village, I expected architecture to be largely about choosing the right technologies.
AWS Lambda or containers?
Regional or multi-region?
Build a synchronization service or use SharePlay?
Generate something at runtime or prepare it beforehand?
Use another model call or retrieve something we already know?
Those decisions matter.
But after building and operating the platform, the question I increasingly ask is different:
Does this complexity actually need to exist?
Sometimes the answer is yes.
Sometimes the right AWS service solves it elegantly.
Sometimes another platform already solves it better.
And sometimes the best architectural decision is the component you decide never to build.
About Vibe Village
Vibe Village is the production application behind the architecture described in this article. Learn more about the product and its experiences at Vibe Village :
https://vibevillage.net
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article