The latest articles on DEV Community by Phillipe Silva (@fromkitchentocode). https://dev.to/fromkitchentocode https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4015724%2F80370980-9435-49a6-bfa7-7219578a3d90.png https://dev.to/fromkitchentocode en Phillipe Silva Sun, 05 Jul 2026 03:36:16 +0000 https://dev.to/fromkitchentocode/how-i-turned-my-saass-client-portal-into-a-white-label-kit-other-devs-can-resell-bfo https://dev.to/fromkitchentocode/how-i-turned-my-saass-client-portal-into-a-white-label-kit-other-devs-can-resell-bfo <p>Running a healthcare SaaS (CareRoots) meant building a client-facing portal — a place where each clinic could log in, see their own patients/orders, and get notified when something needed attention. Straightforward enough.</p> <p>The catch: the portal's "admin" side had <strong>zero independent identity</strong>. It fully piggybacked on the main app's own session. Which was fine, right up until I decided to pull it out into a standalone white-label kit other developers could install for their own clients — and realized the admin panel couldn't exist without the rest of CareRoots running underneath it.</p> <h2> What had to be built from scratch </h2> <p>Turning a tightly-coupled internal feature into something that stands on its own meant building, essentially from zero:</p> <ul> <li>A real admin login system — its own session, its own cookie, its own config file, fails closed if unconfigured</li> <li>A portal-local Cloudflare analytics library (previously reached across into the parent app's own integration)</li> <li>Its own SMTP mailer (same story — used to reach into the site root)</li> <li>Its own push-notification helper, so a client with a new order gets a real browser push, installable as an app via "Add to Home Screen," no App Store review needed</li> </ul> <p>None of this is exotic engineering. It's just the unglamorous work every "extract this into a product" project runs into: the thing that worked because it was <em>one system</em> has to be re-taught how to be <em>two systems that don't trust each other by default</em>.</p> <h2> 3 real bugs the extraction surfaced </h2> <p>Worth sharing because none of them were "hard" bugs — they were the kind that hide in code that's never been forced to run standalone before:</p> <ol> <li><p><strong>The auto-slug generator lowercased <em>after</em> stripping non-alphanumerics, not before.</strong> So <code>"Test Client"</code> became <code>"est-lient"</code> instead of <code>"test-client"</code> — the uppercase <code>T</code> and <code>C</code> got treated as different characters than their lowercase selves during the strip step, and vanished. Any business name with capital letters got mangled.</p></li> <li><p><strong>A failed reply-email was computed but never rendered anywhere.</strong> The code correctly detected that sending failed — it just never told the user. A client hitting "reply" during an outage would see... nothing. No error, no success message. Looked like the button did nothing.</p></li> <li><p><strong>A login page called a helper function (<code>e()</code>, an HTML-escaping shortcut) without requiring the file that defines it.</strong> This one's on me — introduced during the extraction itself, not a pre-existing bug. Caught it because the page threw a fatal error the first time it actually ran standalone, isolated from the rest of the app where that helper happened to already be loaded by something else.</p></li> </ol> <h2> The white-label problem nobody warns you about </h2> <p>Here's the one that isn't a "bug" exactly: the kit's shipped defaults were, at first, literally CareRoots' own brand colors and fonts. Made sense — I copy-pasted the real thing to start from. But shipping a <em>white-label</em> product with your <em>other</em> product's exact visual identity baked in as the default undercuts both: it dilutes the original brand, and it tells the kit's actual buyer "here's someone else's colors, good luck making this look like yours."</p> <p>Redesigned it to a distinct palette (charcoal + ochre/amber, Sora + Work Sans) that's recognizably its own thing — not a reskin excuse, an actual identity.</p> <h2> What it does today </h2> <ul> <li>Your own admin panel, session fully separate from every client's login</li> <li>Each client gets their own portal: orders inbox, reply-by-email</li> <li>Real push notifications via the Web Push API — installable, no App Store</li> <li>Per-client Cloudflare traffic analytics (degrades gracefully if a client has no zone configured)</li> <li>Document storage with tiered limits and virus scanning</li> <li>Bilingual EN/PT client-facing UI</li> <li>Plain PHP, no build tools, no framework, runs on SQLite — any standard PHP host</li> </ul> <p>First 5 buyers get it for <strong>$79</strong> (then $249), one-time payment, 30-day money-back guarantee.</p> <p>👉 <a href="https://fromkitchentocode.com/go.php?to=chk-devto" rel="noopener noreferrer">https://fromkitchentocode.com/go.php?to=chk-devto</a></p> <p>Happy to go deeper on the session-isolation approach, the push/PWA setup, or anything else in the comments.</p> php webdev saas showdev