I was recently given the challenge of migrating one of my workplace's web applications off of NextJS and explore our platform options.

At Tightknit, we do our best to stay tuned in to the movements that affect the developer community: acquisitions, company mergers, and fat checks supporting open source projects. One such movement causing waves is Cloudflare's explicit support for TanStack to run on their Workers platform. Having long been invested in the Workers ecosystem, it was an obvious combination for us to explore, one that promised to bring competitive advantages to the business.

The first step was to create a proof of concept and, after that, validate the complete solution. The POC itself was quite simple: create a new project and migrate one or two screens. The process was smooth, especially with the support of AI, something we embrace responsibly in our software engineering process. Even within converting just a few files, we began to notice significant differences compared to Next, the most important of which I'll list below.

Clearer Page Lifecycle

In NextJS, the page lifecycle is not obvious and a serious point of struggle for newcomers. The React lifecycle has gone through many iterations to reach the maturity it has today, and yet… you will encounter obscure boundaries, such as where metadata ends and the page begins, or where files and the router fit into the mix. This is a result of Next's evolution over time from frontend framework to full stack platform; it's very difficult to avoid creating these "quirks" along the way.

Enter TanStack. In TanStack, you get much clearer definitions coming straight from the file router, where you can explicitly define things like validations, data loading, what goes in the \<head\>, what the component is, and more — all hierarchically and type-safe.

Why? Because TanStack is not considered a framework, but rather a collection of libraries that help you build React applications. One of these libraries is the TanStack Router, a file-system-based router that makes everyone's lives simpler. For those accustomed to NextJS and its directory-based router, you won't have trouble with the TanStack router. It works basically the same way, with some minor syntax differences, mainly in how files are named and how route variables are retrieved.

Vite: A Very Welcome Addition

Another great advantage TanStack brings is the use of Vite. While not directly related to TanStack, it is the build tool of choice in TanStack Start, which is a package of recommended libraries for a project using TanStack—almost a framework.

Vite, when running in the background with npm run dev, allows changes we make to the file structure to be reflected in TanStack's TypeScript immediately. So, for example, if you add a new route file named about.tsx, that route instantly becomes available to be consumed in the code in a completely type-safe way.

It also brings benefits in the reverse direction. For instance, when you create a route file, it handles the scaffolding, filling it with the basics needed to create a new route.

RPC Calls

The biggest surprise benefit was: the ability to make direct calls using Cloudflare Worker service bindings.

In our web app, most pages are rendered using SSR. With TanStack, our actions or data loading are done through calls to server functions, which in turn call Cloudflare workers using RPC service binding calls.

This configuration brought absurd speed to data loading because the RPC protocol is much leaner than the HTTP protocol, not to mention it doesn't carry all the overhead related to NextJS server actions.

P.S. Did you know Next server actions are executed sequentially?

The Weak Points

But it's not all sunshine and rainbows. We had some losses we had to work around when using TanStack.

The biggest one, without a doubt, was losing the image generation offered by Vercel using vercel/og—for Open Graph images, for example. Our solution was to create a new worker dedicated to image generation at the Edge layer of the application, closest to the user.

This is definitely a workaround—a bit of a hack ("gambiarra")—due to the fact that TanStack doesn't bring any first-party library for image generation. However, the workers-og library works very well on Cloudflare, runs on the Edge, and delivers satisfactory image generation results.

Other smaller, though less relevant, drawbacks included having to learn a completely different cache management system, as well as the debugging tool that loads in localhost applications. It works very well and brings different tools, but the keyboard shortcut naturally conflicts with the macOS screenshot shortcut, forcing us to customize the shortcut for a better experience.

Conclusion

The final result is that we now have a much faster application than before and a stack that is much more integrated into the Cloudflare infrastructure.

I have nothing against Vercel or Next.js. Both brought significant improvements to software engineering and the way we build web applications, delivering the most solid developer experience we've seen in recent years.

We simply reached a point as many do where your application grows and as your traffic scales, and it comes time to evaluate vendor lock-in before finding yourself hostage to a single vendor's ecosystem and pricing model. This migration wasn't just a technical swap, it was a strategic move to ensure our stack supports our growth.

Customer support exists on a spectrum. At one end: transactional experiences built for speed and self-service. At the other: non-transactional experiences rooted in human connection.

The Core Distinction

Transactional experiences prioritize immediate problem resolution. Users need answers now. They don't care whether a person or automated system provides the solution—only that the problem gets solved efficiently.

Non-transactional experiences prioritize human connection as the path to resolution. Users seek guidance, best practices, and relationship-building alongside their answers.

The 90% vs. 100% Framework

This spectrum reveals a strategic tension in customer experience design.

Transactional systems excel at getting customers 90% of the way to resolution. Self-service documentation, AI chatbots, and automated workflows handle the majority of common issues. Speed and scalability matter more than perfect personalization.

Non-transactional experiences aim for the full 100%. Human expertise fills gaps that automation misses. Community members share nuanced context. Support teams provide customized guidance. The final 10% requires understanding that only human connection delivers.

When Each Approach Wins

Choose transactional when:

• Users face repetitive, well-defined problems
• Speed to resolution drives satisfaction
• Scale demands automation
• Solutions exist in documented form

Choose non-transactional when:

• Problems require contextual understanding
• Best practices evolve through discussion
• Relationship-building creates long-term value
• Complex scenarios need human judgment

The Balanced Approach

The most effective support strategies don't pick sides. They recognize when automation serves users best and when human connection becomes essential.

Start with transactional systems that efficiently handle common scenarios. Layer in non-transactional touchpoints where expertise and relationships matter most. Design clear escalation paths between the two.

This balanced model maximizes efficiency while preserving the human elements that drive deeper engagement and lasting customer success.

Dark mode has gone from "nice to have" to a baseline expectation. For communities that live in Tightknit all day, the ability to reduce glare at night, improve focus, and keep brand identity intact matters.

Over the past week, we shipped the first phase of dark mode across the web app and companion sites. This post breaks down what changed, why we changed it, how Orchid Security's Dark Matter theme shaped the work, and what's next.

The Orchid Security story: Dark Matter, real constraints

Orchid Security wanted a truly dark brand aesthetic—"Dark Matter"—for their companion site. Early tests surfaced real problems: harsh white outlines, unreadable button text in menus, and components that ignored branding because they rendered outside the app tree.

We turned that feedback into a focused implementation plan:

• Introduce a theme_mode on branding sets (light or dark) so dark themes don't fight light‑biased defaults.
• Move branding from scattered styles to root‑level CSS variables so Radix portals and overlays inherit the correct colors.
• Activate shadcn/Tailwind dark styles via a .dark class on the branding root, then derive tokens for borders, surfaces, and text to eliminate "white halo" artifacts.

After an overnight push to wire these pieces together, we got to a "90% there" dark experience for Orchid—good enough to unblock their launch—while tracking the last 10% of visual nits for cleanup.

What changed (for everyone)

• Per‑brand theme mode in branding sets
  • We added theme_mode and automatically infer the right mode from your background color's luminance so sites "just look right" when you choose a dark background.
• Root‑level CSS variables instead of inline overrides
  • Branding now compiles into CSS variables at the root and a tk-branding scope, so everything—including portals and overlay components—gets the correct colors.
• Tailwind + shadcn dark support, activated the right way
  • We toggle .dark on the tk-branding root, then use color‑mix‑based tokens for borders, surfaces, and text to avoid hard‑coded light‑mode artifacts.
• Safer defaults for existing customers
  • Light‑mode tokens were tuned so changes are barely noticeable, minimizing regressions while unlocking dark mode for those who want it.

Why this approach

• Portals and overlays must inherit branding
  • Root variables ensure modals, popovers, and other out‑of‑tree elements pick up brand colors consistently—no more menu dialogs stuck in light mode.
• Accessibility by design
  • We're validating contrast and structure with Playwright + axe‑core to reduce color‑contrast issues as we extend dark mode coverage.
• Predictable theming model
  • A single source of truth (CSS variables) with a simple mode switch (.dark) is more maintainable than per‑component overrides.

What's improved already

• Real usage, real feedback
  • Orchid's Dark Matter testing revealed outlines, dropdowns, skeletons, and dialogs that needed dark tokens. Those are now addressed or tracked with clear owners.
• 90% coverage today
  • Initial rollout covers core surfaces and shadcn components. Remaining rough edges include stray borders and a few default tokens that still assume light backgrounds.

What's next

• Finish the last 10%
  • Remove remaining white outlines and extend token coverage across all components and states.
• Better logo and media handling
  • Ensure logos with baked white backgrounds and media in cards render correctly on dark surfaces.
• Broader automated checks
  • Expand automated a11y checks to specifically test color contrast across both modes in common flows.

For developers: the gist

• Mode detection
  • theme_mode derives from branding color luminance and is stored with the branding set.
• Activation
  • We scope styles under body.tk-branding and toggle .dark to switch to dark variables. Tokens use color‑mix for borders and surfaces to maintain subtle depth in both modes.
• Why variables
  • Root variables guarantee consistent theming for portals and embedded UIs—no more one‑off overrides that miss overlays or menus.

Rollout status

• Enabled and merged; light‑mode customers should see negligible visual changes. Dark‑mode branding sets look great overall; we're closing remaining visual gaps before calling it "done."

Thank you

Huge thanks to Stephen and Danny for the late‑night push and reviews. Customer feedback from Orchid's team was essential in shaping this rollout.