Web Application · Case study
Colors of GloryOne private room for every song, and a front door that asks for nothing but a phone number.
- Client
- Colors of Glory
- Industry
- Web Application
- Market
- Alberta, Canada · web application
- Launched
- 2026
- Published
- Live site
- colorsofglory.app
- Status
- A login-gated application; only the public sign-in and plans screens were captured. Interior features are described from the implementation.
Overview
Colors of Glory is a web application for Christian songwriters that gives each song a private room: lyrics, voice memos, chords, notes, collaborators, versions and credits kept together in one place. Local Cochrane Web Design built the application's front end — the song rooms, the capture flow, the practice mode, the invitations, the onboarding and the billing screens — over roughly 1,100 commits in the summer of 2026, on a Supabase backend with phone and email one-time-code sign-in and Stripe billing.
Unlike every other study in this portfolio, the product lives behind a sign-in, so its public face is deliberately tiny: a wordmark, the word 'Welcome', a phone-number field, and the sentence 'We'll send a secure one-time code. No password needed.' That restraint is the design. A songwriter is invited into a room by a collaborator, taps a link, confirms a code, and is inside — no marketing page, no account form, no password to invent. What this study can show is that front door, the plans screen the app renders, and the shape of the product as the implementation defines it: thirteen room views per song, a capture-first entry for the moment a melody arrives, and a collaboration model built around invitations rather than discovery.
The live site
Built to be judged in the only place that counts.
Details from the live interface — real pixels, not mockups.
The client
Worship songs are written in fragments — a hummed line in a car, a lyric in a notes app, a chord chart in a photo — and finished by several people who each hold a different fragment. The product's premise, stated in its own description, is to keep all of that 'connected' per song.
The application was built by the studio as front-end lead alongside a backend-and-billing partner, under a written standard the repository records as 'Church Center simplicity × Fantasy.co visual craft'. The Foothills Local Guide, a sister publication, lists Colors of Glory as an independent business — a client product, not a studio-owned one.
The challenge
A collaboration app's hardest screen is the first one. Songwriters are invited by friends, often on a phone, often mid-rehearsal; a sign-up form with a password and a profile is where most invitations die.
The second difficulty was scope. A song room has to hold text, audio, chords and people without becoming a file manager, and the app had to handle recording, uploading and transcribing voice memos on a phone without losing the take.
Strategic objectives
What the build had to accomplish.
Reduce the front door to a phone number or an email and a one-time code — no passwords, no profile before the first song.
Organise everything about a song into one room with named views, so a collaborator always knows where a fragment lives.
Make capture the fastest action in the app: record or hum first, sort it into a song afterwards.
Let collaboration run on invitations, with roles, credits and a visible activity trail.
Keep billing honest and server-truthful: plan names and prices read from the backend, a founder code that applies a stated discount, and storage add-ons the user chooses.
The insights that shaped the work
For an invited user, the best sign-up is the one they do not notice. A code sent to the phone in their hand is the entire account.
A song is not a file. It is a set of related fragments and the people who made them; the room is the unit, not the document.
The plans screen tells the truth about what is safe: 'Everything you have made is safe.' comes before any price.
Chapter
A front door with one field
Insight
The person arriving is a songwriter a friend invited. Anything the screen asks beyond proving they are that person is friction the invitation did not need.
Decision
The public entry is a single screen: the wordmark, 'Welcome', 'Enter your phone number to continue.', a country code preset to +1, one field, and a 'Continue' button — with 'We'll send a secure one-time code. No password needed.', a note that numbers outside the US and Canada should use email instead, and the assurance 'Your number is used to verify access, not shown inside song rooms.' Email, password and OAuth paths exist in the implementation for those who need them, behind 'Use email instead'. Invitation links carry their own short corridor — welcome, verify, name, team — so an invited collaborator lands in the song they were invited to.
Effect
Joining takes a phone number and a six-digit code. The invitation a songwriter received is the account; the app asks for a name only once they are inside.
Chapter
The room is the unit
Insight
Collaborators lose fragments across apps because nothing ties a voice memo to the lyric it belongs to.
Decision
Every song is a room with thirteen named views in the implementation — the room itself, brainstorm, capture, lyrics, chords, a sheet view, a canvas of cards, practice, voice memos, notes, activity, credits, versions, memory and people — each a route of its own so a collaborator can be sent straight to the chords or the latest take. Voice memos are uploaded through signed URLs, finalised, and transcribed by a background worker so a hummed idea becomes searchable text; takes can be swiped through in practice mode with a metronome and scrolling chords; versions keep history; the activity feed and credits record who did what. Scripture lookup is built in for writers working from a passage.
Effect
A fragment, once captured, has a home and a trail. A worship leader can open one room before rehearsal and find the lyric, the chart, the last take and who changed what, without a single message asking where something is.
Chapter
Billing that reads its prices from the truth
Insight
Subscription screens drift from the backend, and a wrong price on a screen is a broken promise to a church musician paying personally.
Decision
Plan identities — free, starter, pro and a founder tier — are defined once, and the plan names, prices and feature copy the app shows are read from backend tables rather than typed into the interface; the repository calls this 'server-truth pricing'. Checkout runs through Stripe with a customer portal and a cancellation path, founder and referral codes apply a stated discount, and storage can be extended in 25 GB and 100 GB add-ons. The plans screen leads with reassurance before price: 'Everything you have made is safe.' and 'More room keeps the next one safe too.' An admin console covers founders, codes, payouts, finance, webhooks, fraud flags and an audit trail.
Effect
The price a user sees is the price the backend charges, and the first thing the upgrade screen says is that nothing they made is at risk. The business side has the ledger it needs without the interface ever inventing a number.
Recognize your own business in this problem? The same system builds yours.
The mobile experience
Songwriting happens on phones, so the application is built phone-first: the sign-in is one field above the keyboard, song rooms stack their views behind a bottom navigation, capture opens the microphone in a tap and keeps the take if the connection drops, and practice mode is designed for a phone on a music stand — chords scrolling, a metronome, the next take a swipe away. The repository's mobile audit and its render tests exist because the phone is the primary device, not a reduced version of the desktop.
Colour & type
The palette below is sampled from the live Colors of Glory site — the exact tones the brand is built on.
#2B2419
#8A6F3C
#C9A86A
#E3DECF
#F6F4EB
#FBFAF6
Search & discoverability
This is an authenticated application, and its public surface is sized accordingly. The entry page carries a title, a description and a social card that state exactly what the product is — one private room per song, with lyrics, voice memos, chords, notes, collaborators and credits — and the robots file keeps the song, settings, invite and authentication routes out of the index. The sitemap lists only the entry and the sign-in page. No structured data, prerendering or search positioning is claimed, because a product reached by invitation does not need to be discovered by a crawler; it needs to load fast for the person holding the invitation.
Technology & ownership
The front end is a React application with route modules for songs, authentication, invitations, onboarding, settings and administration, built on a Supabase backend of 42 tables and 50 edge functions covering voice-memo upload and transcription, invitations and referrals, billing and payouts, fraud checks and audit logging. Sign-in uses one-time codes by phone or email with a bot challenge; payments use Stripe checkout, a customer portal and webhooks; the build enforces a bundle budget and runs a quality gate script before release. Every interior fact here is implementation evidence, not an observed screen.
Immediate outcomes at launch
The public entry is one field: a phone number (or an email) and a one-time code, with no password and no profile before the first song.
Each song is a private room with thirteen named views — lyrics, chords, voice memos, notes, versions, credits, people, practice and more — each addressable by its own route.
Voice memos are uploaded, finalised and transcribed by a background worker; practice mode plays takes with chords and a metronome.
Collaboration runs on invitations with roles, credits and an activity trail; a referral landing and founder codes are built in.
Plan names and prices are read from the backend, checkout and the customer portal run through Stripe, and the upgrade screen leads with 'Everything you have made is safe.'
Common questions
What owners ask before commissioning a build like this one.
What should the sign-in screen of an invitation-based app look like?
One field. Colors of Glory's public entry asks for a phone number, sends a one-time code, and says 'No password needed.' — with email as the alternative and a note that the number is never shown inside song rooms. An invited collaborator lands in the song they were invited to after confirming the code.
How does Colors of Glory organise a song?
As a private room with named views. Each song has its own routes for lyrics, chords, a sheet view, a canvas, voice memos, notes, versions, credits, people, activity and practice, so a collaborator can be sent straight to the latest take or the chart. Voice memos are transcribed in the background so a hummed idea becomes searchable.
Why can't this case study show the app's interior screens?
Because they belong to its users. The application is login-gated and this study did not sign in; every interior feature described here is implementation evidence from the studio's repository and the deployed bundle — routes, tables and functions — not an observed screen. The public sign-in and the in-app plans screen are the only captures.
How should a subscription app show its prices?
From the backend, not the interface. Colors of Glory reads plan names, prices and feature copy from server tables, runs checkout and the customer portal through Stripe, applies founder and referral codes as stated discounts, and opens its upgrade screen with 'Everything you have made is safe.' before any price.
What results does this case study claim?
None that were not observed. No user counts, songs written, revenue or subscription figures appear here, because none were observable, and the plans screen's prices failed to render during review so none are quoted. What is documented is the build as the implementation defines it, verified against the live entry screen and the studio's repository on 21 October 2026.
Where it stands
Colors of Glory is the one study here whose best screens cannot be shown, because they belong to the people writing in them. What can be shown is the door — one field, one code — and the shape behind it: a room for every song, a place for every fragment, and a bill that tells the truth. For an app built for worship writers, that is the right kind of invisible.
- Application Front End
- Onboarding & Invitations
- Billing Screens
- Mobile-First Design
More case studies
The same system, a different market.
Your project
Your business may have outgrown its website.
Colors of Glory needed more than a redesign — it needed its real-world strengths made visible online. If that sounds familiar, tell us about your business. A written, itemised proposal comes back within one business day.
Free · No obligation · Written quote within 24 hours
Building Websites That Work as Hard as You Do