Two of the products I sell do something that sounds reckless when you say it out loud: they redesign a piece of someone else’s software. Tendir Pro rebuilds Booknetic’s SaaS tenant directory. Cuspan Pro rebuilds its customer panel. In both cases I’m replacing the interface of a platform I didn’t write and don’t control — and I do it without editing a single line of that platform’s code.
That constraint isn’t a limitation I work around. It’s the whole design.
The temptation, and why I refuse it
When you want to change how a platform looks or behaves, the fast path is obvious: open its files and edit them. Change the template, tweak the query, patch the class. It works immediately, and it’s a trap.
The moment you edit a file that ships with the platform, you’ve signed up to maintain a fork forever. The next update overwrites your change — silently, usually at the worst time — or you pin the platform to an old version and slowly fall behind on security and features. Either way you’ve coupled your product’s survival to never touching the thing underneath. On a platform that ships real updates, that’s a slow-motion outage waiting for a date.
So the first rule I set for both products: never patch core. No edited templates, no monkey-patched classes, no “just this one file.” If I can’t do it through a supported extension point, I find another way — or I don’t do it.
What “overlay” actually means
Both products load as their own separate plugins. They hook into the points the platform already exposes for exactly this, take over the relevant shortcode, and render their own interface in place of the stock one. The customer sees a completely redesigned screen. The platform sees a well-behaved add-on using its front door.
The important part is what happens when the user does something. When a customer reschedules an appointment in Cuspan’s redesigned panel, I don’t reimplement Booknetic’s rescheduling rules — what’s allowed, which statuses can change, how availability is computed. I hand the action straight back to the platform’s own endpoints and let its logic and its permission checks decide. I redesigned the surface; the platform still owns every decision underneath it.
That split is the entire reliability story:
- Because I touch no core files, a platform update can’t silently undo my work.
- Because I delegate the rules instead of copying them, I can’t silently break a rule I don’t own — if the platform changes how rescheduling works, my button rides along instead of drifting out of sync.
- Because I gate the SaaS features behind the platform’s own capabilities system instead of inventing my own, “is this user allowed?” has exactly one answer, and it isn’t mine.
When the stock screen genuinely didn’t expose something I needed — a clean JSON list of appointments split into upcoming and past, say — I didn’t bend an existing endpoint to do double duty. I added my own small endpoint next to the platform’s and left theirs alone. New behavior lives in my code; existing behavior stays exactly where it was.
The cost, paid on purpose
I’ll be honest that the overlay way is slower. Patching a core template would take an afternoon; doing the same thing as a clean overlay that survives updates takes longer, and sometimes it takes real ingenuity to reach something the platform didn’t quite mean to hand out. There were evenings spent making a redesigned screen talk to the platform’s own machinery correctly — lining up session and permission context so a delegated action authenticates the way the platform expects, instead of faking it and hoping.
That extra work is the product. Anyone can make a prettier screen in a screenshot. The thing I’m actually selling is a prettier screen that’s still standing after the next platform update — and the only version of that I’d put my name on is the one that never touched core.
Respect the room
The mental model I keep coming back to: I’m a guest in someone else’s house. I can rearrange the room I’m given, bring my own furniture, make it somewhere people want to be. What I don’t get to do is knock down a load-bearing wall because it’s in my way. The platform defines the rules of the building; my job is to do something beautiful inside them without compromising the structure.
That’s not a compromise I make grudgingly — it’s the reason these products are worth selling at all. A redesign that breaks on the next update isn’t a product; it’s a liability with nice typography. Redesign the surface, respect the core, and you get something you can actually stand behind.