BB Digital Media

A friend launching a digital media business needed a professional web presence, showcasing her services and content she could manage herself without calling a developer.

• Voice over
• Event coverage
• Audio production
• Social media management
• Drone work
• A section for trusted local partners.

Early discovery surfaced bigger ambitions: QuickBooks integration, Stripe, portal functionality.

We scoped down to one focus: Build the lead generation site first, add features as genuine needs emerge.

The WordPress debate was the first real constraint. She was comfortable with drag-and-drop and questioned whether Sanity Studio was worth learning. The case was made honestly with design flexibility, structured content, edge hosting, near-zero infrastructure cost in mind. She chose the recommended stack.

SPA over MPA was decided early, simpler to reason about, faster to iterate on, room to grow.

Video and audio storage resolved pragmatically:

YouTube and Vimeo URLs as string fields in Sanity. Zero storage cost, better playback, no infrastructure.

The week before the client meeting was spent getting up to speed on Next.js through Sanity's own course material. Finished enough of the course to build confidently without finishing it completely (about 70%).

The standout discovery was React Server Components. Fetching data server-side, passing results as props to React Client Components. A clean separation of data fetching from interactivity that became the backbone of the frontend.

Build order:

1. Sanity schema and TypeScript types
2. GROQ queries validated in Vision before any frontend code
3. Directory structure per section
4. Server Components fetching data, Client Components handling interactivity

Schema and queries using Sanity Studio Vision, confirmed the data contract before a single component was written. The frontend was never built against assumptions.

CI with GitHub Actions surfaced dependency conflicts on the first run. Catching issues in the pipeline rather than in production was a direct demonstration of why CI exists.

Vitest unit tests on the Navbar component caught rendering regressions that would otherwise have gone unnoticed until manual testing or production.

The Chromium bug was the most memorable debugging session. After deploying to Vercel, the Social Media section rendered correctly locally but failed on desktop Chromium browsers.

The cause: Ad blockers treat any element with the ID social-media as an ad and block it from rendering. Renaming to social-media-audit resolved it immediately. Tested in Browser Dev Tools and pushed to production when confirmed.

A polished, responsive portfolio site with Sanity Studio integration. The client manages her own content, and her reaction at the initial presentation exceeded her expectations.

The site is live on Vercel. A link will be added once final sign-off is complete.

BB Digital Media was the project where several things clicked simultaneously:

• Next.js and Sanity stack,
• CI/CD in practice
• Unit testing with real consequences,
• Discipline of building from schema outward rather than UI inward.

React Server Components changed how I think about frontend architecture. The pattern maps naturally to how data flows through an application, and raises a question worth exploring in the IPD Buddy rewrite: how RSCs interact with a Java Spring Boot backend as an intermediary.

CI and testing are not optional. GitHub Actions and Vitest both proved their value on the first run. Version conflicts and rendering regressions are exactly the class of issues that compound silently without automation.

The Chromium bug is a reminder that the browser is part of the environment you're shipping into. Test across browsers before presenting to a client, even when everything looks correct locally (which it did).

Scope discipline starts in the first conversation. Deferring QuickBooks, portal functionality, and Stripe to genuine future needs kept the project focused and deliverable.