Sanbi
Overview
Sanbi is a product I'm building to explore how worship leaders can prepare worship sets faster without digging through old message threads and notes.
The first version focuses on the core planning workflow. It helps teams organise sets, keep useful song information together, and build a history they can return to over time.
Role
Product design & full-stack engineering
I'm designing and building Sanbi end to end, from early user interviews and defining the first version through prototyping, full-stack implementation, testing, and iteration.
Built with
- Frontend
- Next.js, React, TypeScript, TanStack Query, Zustand, shadcn/ui, Tailwind CSS, Storybook
- Auth
- Clerk
- Backend & data
- Node.js, tRPC, Drizzle ORM, PostgreSQL
- Testing & QA
- Jest, Playwright, Chromatic
The problem I'm exploring
Planning a worship set often means piecing together information from different places. It is difficult to remember what was played and when, find the right songs from an existing library, and keep details like keys or notes organised.
I interviewed a worship leader to understand his current workflow and what would make planning easier.
The biggest pain point was not creating a set itself. It was referencing and reusing information from previous weeks. Knowing what songs had been played, which keys worked well, and what notes existed for a particular song required manually searching through messages, apps and personal notes.
The goal for Sanbi was to make creating new sets easier while building a useful song library over time.
Defining V0
The original idea for Sanbi covered a lot of possible features, including team collaboration, Spotify integrations and chord sheet tools.
For V0, I focused on the core workflow for an individual worship leader:
- Create and manage sets
- Add and organise songs
- Track song history, keys and notes
- Search and reuse songs when planning future services
I deliberately avoided building one-off integrations too early. Instead of creating specific connections for Spotify, Google Docs or other resources, Sanbi uses a general resource model where users can attach relevant links. This keeps the workflow flexible without locking the product into specific services.
Collaboration and richer team features can come later once the core planning workflow is working well.
Designing and building
Before starting implementation, I prototyped the main flows in Figma and got feedback directly from the user on what worked and what didn’t.
One example was adding a song to a set. The flow needed to capture useful context such as the key, section and notes for a specific service without adding unnecessary friction.
The current V0 supports the main planning workflow across desktop and mobile. Users can create sets, add songs, organise sections, manage keys and capture notes.
Sanbi uses a typed full-stack architecture with Next.js, TypeScript, tRPC, and PostgreSQL. I chose this approach because the product is still changing quickly, and shared types help me move between frontend and backend changes with more confidence. Automated tests cover the workflows that matter most, such as creating sets and managing song information.
Current state
Sanbi is an ongoing project. The screenshots and workflows shown here represent the current V0 implementation and will continue to change as new features are added.
The next focus areas are improving the dashboard experience, refining song and set discovery, and continuing to iterate on the UI based on usage.