Every value in the ShoreAgents database looked like this: real_estate_property_management. Every label on the website needed to look like this: "Real Estate Property Management."
The gap between those two representations nearly broke the entire frontend.
<a href="/tales/build-the-army-wrote-birth-certificates" class="internal-link">The Normalisation Crusade</a>
Day 1 of the rebuild, I made a decision: every value in the database would be lowercase_snake_case. No exceptions. No camelCase. No "Virtual Assistant" in one row and "virtual-assistant" in another.
This meant normalising: - 31 industry values across 771 articles - 15 business function values - Every tag, category, and filter option
I wrote Supabase REST API PATCH scripts that ran through every record and standardised everything. The database became clean, consistent, and queryable.
The website looked like garbage.
The Display Problem
Tag pills showing real_estate. Category headers reading customer_service. Breadcrumbs with virtual_assistant_for_accounting. URL slugs bleeding into the UI.
The icon maps broke too — they'd been keyed to the old mixed-case values. Updated every icon map to use lowercase keys.
The Solution
`typescript
export function formatLabel(value: string): string {
const specialCases: Record`
One function. Applied everywhere. real_estate → "Real Estate". saas_customer_success → "SaaS Customer Success". hr_outsourcing → "HR Outsourcing".
The special cases map handles acronyms that shouldn't be title-cased. Without it, you'd get "Saas" and "Hr" and "Seo" — technically capitalised, visually wrong.
Where It Lives
formatLabel() went into a shared utility file and got imported across every page that displays database values: resource listings, category filters, tag pills, breadcrumbs, article headers, the blog page's 18 category filter pills.
The footer got the same treatment — © 2025 became a dynamic year. The SYS_V2.0.38 version string got removed entirely.
The Lesson
Database normalisation and display formatting are two separate problems. Solve them separately. Store everything in a machine-friendly format (lowercase_snake_case). Transform to human-friendly at the display layer. Never mix the two.
One utility function. Applied in 15 minutes. Fixed every label on the entire site. The database stays clean. The users see proper English. Everyone's happy. 👑
Frequently Asked Questions
What was the main problem with the database values initially?
Every value in the ShoreAgents database was in snake_case, like real_estate_property_management. However, every label displayed on the website needed to be in a human-readable format, such as "Real Estate Property Management." This gap between the database format and the required display format caused significant issues for the frontend.
How did the author address the inconsistency in database values?
The author decided that every value in the database would be lowercase_snake_case without exception. This involved normalising 31 industry values, 15 business function values, and every tag, category, and filter option using Supabase REST API PATCH scripts. This made the database clean, consistent, and queryable.
What specific issues did the display problem cause on the website?
The website displayed database values directly, leading to tag pills showing real_estate, category headers reading customer_service, and breadcrumbs with virtual_assistant_for_accounting. Additionally, icon maps broke because they were keyed to the old mixed-case values, requiring updates to use lowercase keys.
The Takeaway
Database normalisation and display formatting are distinct problems that should be solved separately. Store all data in a machine-friendly format, such as lowercase_snake_case, and then transform it to a human-friendly format at the display layer. A single utility function can effectively bridge this gap, ensuring a clean database and a user-friendly interface.