Why We Rebuilt Our Own Website Off Flutter Web

For our first year, thedotapps.in ran on Flutter Web. It looked good, it was fast to build, and it used the same stack we use for client products. It also produced zero organic search leads in eleven months.

The actual problem

Flutter Web renders the entire UI to a <canvas> element using CanvasKit. That's fantastic for an interactive product — pixel-perfect, consistent across platforms, and it feels native. But it means the page has no real DOM text. Search engines and screen readers don't see your headline, your service list, or your case studies. They see whatever static fallback HTML you hand-wrote into index.html — and that fallback is the same on every route, because a single-page app only ships one HTML file.

We had good meta tags, a correct sitemap, JSON-LD structured data, and a hand-rolled per-route title swap in JavaScript. None of it mattered, because the content itself was never actually there for a crawler to read.

What we moved to instead

We rebuilt the marketing site in Next.js with server-rendered and statically generated pages. Every route now ships real, unique HTML: real headings, real paragraphs, real internal links. The animation layer — smooth scrolling and scroll-driven reveals — is handled separately with GSAP and Lenis, so the visual experience doesn't cost us the content.

Flutter is still exactly right for our client work: the products behind a login, the admin panels, the cross-platform apps. It was just never the right tool for a public page whose entire job is to be found.