DEV Community

Cover image for Dev Log: 2026-06-26 — Config-Driven Billing, an App-Wide Rebrand, and Branded Error Pages
Nasrul Hazim Bin Mohamad
Nasrul Hazim Bin Mohamad

Posted on

Dev Log: 2026-06-26 — Config-Driven Billing, an App-Wide Rebrand, and Branded Error Pages

TL;DR

  • Pushed commercial rules (free seats, bulk seats, tax) out of code and into config + a BillingProvider contract.
  • Did a full app-wide rebrand — favicons, PWA manifest, logo components — the kind of change that's 80 files but one idea.
  • Shipped branded error pages (401–503) and a richer project overview with clickable stats.
  • Theme of the day: centralise the thing that changes, so the next change is an edit, not a hunt.

A wide day across the platform — four threads, none of them huge alone, but each one a small lesson in where a thing should live.

Thread 1 — Billing rules are data, not code

The biggest architectural thread: free-seat defaults, bulk seat purchases, and tax all moved behind a BillingProvider contract with manual and Stripe drivers. The number of free seats is now config (or a live admin setting); tax is the provider's job, delegated to Stripe Tax on the self-serve path. I wrote this one up on its own — the short version: if a value is a business decision, it doesn't belong in an if statement.

Thread 2 — An app-wide rebrand is one idea wearing 80 files

Rebranding touched favicons, Apple touch icons, maskable PWA icons, the web manifest, browserconfig, and the logo Blade components. It looks like a massive diff, but the trick is that the brand lives in one place: a couple of <x-app-logo> components and a manifest. Swap those, regenerate the icon set, and the whole app follows. TL;DR: if a rebrand means editing 80 hand-placed logos, that's the real bug — centralise the mark first, then a rebrand is a single asset swap.

Thread 3 — Error pages deserve the same care as happy paths

Added branded pages for 401 through 503. Default framework error pages are fine functionally but feel like falling off a cliff. A consistent layout with the product mark and a footer keeps users oriented even when something broke. Cheap to do, disproportionately reassuring.

Thread 4 — Make the dashboard clickable

The project overview got enriched: stats are now clickable into the thing they count, recent issues open in a new tab, and the list grew a peek flyout so you can glance at a project without leaving the page. Small UX seams, but they shave clicks off the most-used screen.

The through-line

Three of today's four threads are the same move: find the value (or asset, or layout) that changes often, give it one home, and let everything else read from there. Config for billing numbers, a logo component for the brand, a shared layout for errors. The day's diff was wide, but the principle was narrow.

Top comments (0)