Date: 2026-06-04
Status: Draft for review (loose plan, derived from working conversation)
Authors: Danny, Nicole
This is a layered document. Section 1 is written to stand alone as a leadership-facing proposal. Sections 2–8 are the working roadmap for the two people driving the initiative.
We are in the AI / agentic era. Our thought leadership, our messaging, and the futuristic solutions we talk about are not matched by our visual output. We have never done a true platform redesign since the DialogTech acquisition -- Titan was an architectural shift, not a redesign. The question is no longer whether we modernize, but whether we can afford to wait 18 months to bring the platform's look-and-feel into the AI era. We do not believe we can.
The bet: build an AI-driven "machine" that deconstructs legacy web UIs and reconstructs them in modern Titan -- and, as a deliberate byproduct, unlocks non-developers (e.g. product and UX partners) to improve the workflows we already know need love, using Figma Make / Claude / Cursor.
What success feels like: pride and confidence in what we ship and show to people.
The ask:
- A focused jumpstart -- a dedicated week (onsite or remote, TBD) to stand the machine up and agree on the run plan before we run.
- No new engineering headcount yet.
- Internal tools explicitly out of scope.
- A "one-to-one" transition per app: when an app is migrated, the work is integrated and embedded with the team that owns it at that moment -- not thrown over a wall.
This initiative is really two lanes converging on one end-to-end SDLC.
The design and engineering teams each own a distinct lane in the product delivery pipeline. Design and UX are responsible for the Idea → Design phase, covering the codified design system, the why behind every decision, AI-readable sources, and Figma Make output. Engineering owns the Design → Code → Production phase, driving operational SDLC automation, developer workflow, and getting code into production.
The overlap is the design system / token library. That is the shared seam. The combined goal is a working end-to-end SDLC: idea → paper → code → production, increasingly automated.
A near-term need on the design side: a repository of design decisions (the why), not just the how. Storybook captures how a component is built; we need ZeroHeight (or equivalent) to capture why it's built that way and when to choose one option over another. That missing "why" is what lets AI tools generate designs that actually reflect our system.
This is the crux. Nothing moves cleanly without it.
- One token library, portable across component libraries. The same token library must drive (a) the existing Titan component library and (b) the new bridge / hybrid component library for web. Both libraries draw from the same tokens, so output stays consistent regardless of which library is hoisting a given component.
- A "modern version of legacy" hybrid style guide. Easy to visualize in parts, harder in others. We need to define what facelifted-legacy actually looks like.
- End-users never see the seam. Two buttons look identical; only we know one is the hybrid bridge version and one is native Titan.
- Tokens are comparatively cheap to change (a hex code on a token), but defining the portable library that survives across both component libraries is the real, time-consuming work -- and it takes more time than people realize. This needs to start sooner rather than later because it gates the output of every later phase.
The core deliverable: a repeatable, AI-driven pipeline that turns a legacy web view into a modern Titan view.
Components:
- The audit (see §5) -- figure out what the pieces are and what's actually legacy.
- The bridge component library -- the hybrid set that lets legacy structure render with modern styling. Much of building this library can likely be AI-automated.
- A skill system living between Titan and Web -- an expert agent at deconstructing legacy interfaces and translating them into modern interfaces. This is the reusable "machine" we carry from one app to the next.
- A self-testing loop -- emerging Claude Code capabilities where the agent renders its own browser, compares the new UI against the old UI, and clicks through to validate. Getting this set up reliably is a key early task.
The clean-slice principle (hard constraint):
- Separate the front-end from the back-end. No database, transport, or backend changes.
- This is the only way to hit a reasonable timeframe; coupling FE/BE work makes it murky and slow.
- We accept that we are moving a large amount of historical technical debt from one repo to another -- we are not fixing it. The debt gets rewritten across languages (JS / jQuery / Backdraft / underscore → TypeScript / React), which is itself hard even with AI because the legacy source is often poorly written.
- Once an app's debt has moved into Titan, the owning team is then enabled to clean it up.
The unlock (why leadership cares): once an app is in modern Titan (and assuming the repo-connected version of Figma Make), non-developers can use Figma Make / Cursor / Claude to ideate and improve workflows directly -- the same way reporting work is being done today. That is a large part of what "AI enablement" means on the product + UX front, and a core reason the BHAG exists.
We pick targets from a scored matrix rather than gut feel.
Matrix -- one row per legacy app, scored on:
| Dimension | What it captures |
|---|---|
| Dependencies | How much else depends on it |
| Activity | How actively it's used / changed |
| Blocking risk | Risk of blocking other work |
| Complexity | APIs, CSS, libraries involved; how old the code is (age dictates how it was built) |
Critical distinction -- the two forks in Titan:
- Modern apps live in one fork.
- Legacy-look apps live in another fork inside Titan -- they can be changed as easily as modern apps but still carry the legacy look/feel. (Known examples include bulk number management, customer requests, deliveries, global settings, legacy tags, partner platforms, primary header + navigation, temporary access interstitial, user management UI.)
- True legacy web apps live entirely outside Titan and must first be extracted from that repo. These are the real migration targets for the machine.
Note: header + primary nav are high-visibility but already in Titan -- a re-skin there is simple and fast, but it does not exercise the extraction muscle the machine needs. It's a quick win, not a pilot.
Two-track targets:
- Pilot (validate the machine): a genuinely-legacy, low-activity web app -- chosen deliberately to be low-stakes so we can learn the process, measure the automation ceiling, and answer the "who untangles the last 30% and how long does it take" question before touching anything critical. Candidate pool comes from the true-legacy-web list (backdraft projects, utilities such as call extensions, virtual lines, ring pools, custom data views, change history, expression builder, etc. -- to be filtered by the matrix).
- North star (the proof): Campaigns -- the dream-list #1, sitting at the heart of the system, long known to need love. Too central and too risky to go first; framed as the eventual proof the machine builds toward, not the pilot.
(Signals is already Titanized. Invoca Tag is actively being modernized. Integrations was removed. These are out of scope.)
-
The "last 30%": AI can plausibly handle 65–75% of a migration, but the final ~30% per app, per view, is the hard part and risks leaving apps in a half-migrated state. The pilot should measure this empirically and define what kind of person untangles the remainder and how long it takes.
-
Clean-slice feasibility: Many legacy UIs (likely including IVR) have business logic tightly coupled to the front-end, making clean FE/BE separation impossible everywhere. Confirm feasibility per app as a gate before that app proceeds (§7).
-
Cross-language debt translation: Rewriting poorly-written JS/jQuery/Backdraft into TS/React is error-prone even with AI assistance. The pilot will surface the real difficulty and inform effort estimates.
-
Scope creep / wrong first target: Going after Campaigns first would overwhelm an unproven machine. The two-track framing (§5) holds the line.
-
Token library timeline: Foundation work takes longer than expected and gates everything downstream. Start the portable token library work now, in parallel with the audit.
Phases overlap where they can. Gates are exit criteria, not just checkpoints.
Phase 0 -- Foundation & audit (in parallel)
- Stand up the portable token library + hybrid "modern legacy" style guide.
- Build the scored prioritization matrix; classify every app as modern / legacy-in-Titan / true-legacy-web.
- Stand up the self-testing browser-comparison loop reliably.
- Gate: a pilot target selected from true-legacy-web; clean-slice feasibility confirmed for it.
Phase 1 -- Build the machine on the pilot
- Build the bridge component library (AI-automated where possible).
- Build the deconstruct-and-translate skill system between Titan and Web.
- Migrate the low-stakes pilot end-to-end; measure automation %, the last-30% effort, and per-app time.
- Gate: pilot reaches a "pride and confidence" state; we can name the manual role + time cost.
Phase 2 -- Repeat & accelerate
- Run the next targets down the prioritized matrix; refine the machine each pass so each app is faster than the last.
- One-to-one transition: each migrated app is embedded with its owning team; that team picks up cleanup and AI-enabled workflow improvement (Figma Make / Cursor / Claude).
- Gate per app: clean-slice confirmed before it proceeds.
Phase 3 -- North star
- Tackle Campaigns once the machine is proven and accelerated.
- Collaboration model: onsite jumpstart week vs. dedicated remote week. Onsite reduces distraction and improves collaboration; remote is viable. Decide early, then regroup.
- Timing: June is tricky -- [[Danny Peck|Danny]] is off next week, [[Nicole Conary|Nicole]] off after. Use this week (incl. tomorrow) to collaborate while both are available.
- Engineer's handoff: write up (a) the list of needs to make this successful -- still being built; the "hybrid style guide for a modern version of legacy" is one named need -- and (b) the true-legacy-web app list, for the design lead to filter and carry into the proposal.
- Design lead's handoff: look through the platform / true-legacy list, propose low-stakes pilot candidates, and produce the visualization of the end-to-end SDLC (only one diagram exists so far).
- Define the end state literally: what does a "codified design system" look like from a designer's view vs. a developer's view? One interface or two? Start-with-the-end-in-mind, then work backward.
- Naming / slogan: the phrase that communicates "getting out of legacy" + "AI enablement for non-developers" -- TBD.
- Internal tools: out of scope.
- Transitions must be one-to-one and embedded with the owning team at migration time.
- No backend / DB / transport changes (clean-slice).
- No new engineering headcount yet (revisit later).