Reusing a foundation across two businesses, without turning it into a framework.

Diksha Learning Center is a coaching institute's enrollment platform. Wander Yak is a tourism booking platform. On paper they have nothing to do with each other. Underneath, strip away the specific content, and they need the same shape: a catalog of things to browse — courses versus travel packages — a real payment-backed conversion — enroll versus book — content the client's own non-technical staff can manage without a code deploy, and multiple admin accounts that shouldn't all share one login. That's exactly the admin/CMS/RBAC foundation proven on Wander Yak first, reused deliberately when Diksha needed the same underlying job done for a different business.

Recognizing the same shape under different content

The pattern-matching part is the actual skill here — not "this client also needs a website" but "this client's real problem has the same structural shape as a problem I've already solved correctly." Courses and faculty aren't packages and itineraries, and a coaching institute's staff aren't a tour operator's staff. But the underlying need — a catalog, a payment-backed conversion, self-serve content management, and access control — was already fought for and working. Rebuilding that from zero a second time would mean relearning lessons that were already paid for once, for no benefit to the client.

Where I stopped

The tempting next move is to abstract that shared foundation into one generic "business website framework" that any client could plug content into. I deliberately didn't. It's still two separate codebases that happen to share the same shape, not one framework trying to be everything to everyone. That restraint isn't accidental — it's the same warning that shows up from the opposite direction in the credentialing SaaS's own product-vision thinking: generalizing too early produces something worse at every specific job than two focused builds would be. A framework optimized for "any business" ends up serving no business particularly well.

The actual principle

Reuse the proven decisions — RBAC from day one, CMS-driven content, payment tied directly to the thing being sold — because those are lessons, not code. Don't reuse the code itself past the point where it still fits the specific job. The second build should be faster because you already know which choices hold up in production, not because you forced two different businesses through the same rigid mold.