Out of the box, the Frappe/ERPNext portal and website look unmistakably like Frappe: the default navbar, the stock login screen, generic card layouts, and a footer that says "Powered by Frappe." For a business that puts customers, vendors, or members in front of that portal — to view invoices, raise support tickets, submit RFQs, or track orders — the un-branded experience quietly erodes trust. ERPNext natively gives you a website settings page, a splash logo, and a brand color, but the moment you want a custom navbar structure, branded login and signup pages, restyled portal cards, or per-role theming, you fall off the edge of what the UI can do and into hand-editing website_theme, overriding portal templates, and maintaining fragile CSS that breaks on the next bench update.

We build a proper Frappe app — its own module, installed with bench get-app and bench install-app — that turns all of this into structured configuration. At its core is a Portal Theme Settings single DocType (plus child tables for menu items, CSS injection blocks, and per-role overrides) that your admins edit like any other ERPNext form. On save, a hooks.py doc_events handler validates the theme and regenerates the compiled CSS/bundle, so the branded navbar, footer, card styles, and login/signup pages render immediately without a developer touching a template. We wire the theme into Frappe's website rendering through website_context, app_include_css, and portal_menu_items hooks so it applies consistently across www pages, the /app desk portal surfaces, and the logged-in customer portal — not just one of them.

Technically, the app exposes controlled extension points instead of a blank CSS box: named injection slots (global head, portal-only, login-only, print) so custom CSS lands in the right scope and survives upgrades; a whitelisted REST method (frappe.whitelist()) that returns the active theme as JSON for any headless or mobile front-end you run against the Frappe REST API; and a nightly scheduler_events job that can rebuild assets and warm caches. Branding assets (logo, favicon, OG image, web fonts) are stored as File records and referenced by field, so there are no hard-coded paths. Everything respects Frappe permissions and role profiles — you decide which roles may edit the theme, and per-role overrides let a "Vendor" portal look different from a "Customer" portal. Responsive breakpoints and mobile navbar behavior are part of the theme model, so the branded experience holds up on phones, not just desktop.

Because this is build-to-order, we start from your actual brand and portal, not a template gallery. After a short scoping call we confirm exactly which surfaces you need themed (portal, website, login, specific DocType web views), your brand tokens, and any v15/v16 target. We build against a copy of your requirements, ship installable source you own, and hand over a git repository — not a black box. Typical delivery is one working week from confirmed scope, and we install it, run UAT on a staging bench with a rollback plan, and stay on for a post-go-live support window.