Build a shared architecture layer for multi-brand LIFF services

Context

Each Clinico brand had its own LINE Official Account and LIFF service.

From a product perspective, they offered different business services. In implementation, however, I found that every LIFF repeatedly handled very similar engineering problems:

• Initialization timing
• Login / Authentication
• Token state
• Redirect
• LINE Browser detection
• Error flows
• Page-state transitions

If each brand implemented these independently, they initially appeared to be merely separate projects. After several requirement iterations, however, the same problem would gradually acquire three different solutions.

My Decision & Action

I began separating what services a brand provides from how LIFF itself operates.

The business features that truly differed by brand remained in their respective applications;

initialization, authentication, routing, shared page behavior, and state handling were organized into a shared LIFF architecture layer.

Overridable and extensible interfaces were preserved so each brand could add its special flows without copying the entire infrastructure.

Outcome

All three LINE Official Accounts could be built on the same LIFF process model.

When services were added later, login, token, redirect, and initialization problems did not need to be solved again. Shared behavior required only one implementation, while each brand retained its business differences.

Reflection

This experience led me to distinguish more clearly that:

product differences do not mean the engineering foundation must also diverge.

When a platform’s fundamental behavior is essentially the same, there should be only one source that truly describes how it works.

There can be many brands, but LIFF login, routing, token, and initialization rules do not therefore need many versions.