How AI coding agents made it practical for me to build and own a different stack with TanStack Start and Cloudflare.
The first person who introduced me to Next.js was my friend Haythem Lazaar. We were at university, building Collo, a project management tool for remote teams. It was around the time the pandemic had pushed so many companies into remote work. We put a lot into its design and features, and learned even more while building it.
I was coming from Angular, which I honestly hated working with. Next.js felt refreshing. I still remember Next.js 13 coming out with the App Router. Haythem suggested we stick with Next.js 12 for Collo: he knew it well, and we didn't need to take a chance on a new architecture in the middle of the project. That was my introduction to Next.js, and then to everything around Vercel.
I was hooked.
Why it became my default
What impressed me was how much I could build without spending the first week wiring up infrastructure. I could focus on the product, and deployment felt almost too easy. Later came tools such as the AI SDK, Sandbox, Workflows, and more integrations within reach.
Credit where it's due: the Next.js and Vercel teams made developer experience a reason to choose their tools. For years, whenever I started a React project, I barely thought about the framework. I picked Next.js and built the rest of the stack around it: Vercel, Supabase, Resend, and whatever else the project needed.
I was also following solo builders on X. Some shipped on a VPS, some used SQLite for products where I would have reached for Postgres, and many questioned whether their usual hosted stack was worth the cost as they grew. I didn't agree with every take. A small SQLite database is not a drop-in answer for every application. But it made me ask a better question: had I stopped choosing my stack and started repeating it?
At the same time, AI coding agents were getting good enough to change how I worked. The convenience of my usual stack was hard to give up when replacing any of its defaults meant researching, wiring, and debugging everything alone. Now I could explore a different approach, have an agent help build the missing pieces, inspect the result, and decide whether it actually worked for my project. The setup still mattered, but it no longer stopped me from trying.
I kept seeing TanStack Start and Cloudflare come up. This time, I wanted to see what I could build with them rather than dismissing the idea because my old stack was already comfortable.
The project that changed my mind
I wanted a foundation I could reuse for my own projects and at Tanfust. That's how TanBase Core started.
It's an open-source task board built with TanStack Start on Cloudflare Workers. The board is a real application that exercises the stack: authentication with Better Auth, data in D1 through Drizzle, attachments in R2, a live board with Durable Objects, reminders with Cron Triggers and Queues, and an AI workflow. The repo includes setup instructions and the pieces needed to fork it.
My first wow moment was much simpler than a feature checklist. I finished the Better Auth setup, opened the app, and signed in. I clicked the button and landed on the dashboard in what felt like milliseconds. I tried it again because the difference surprised me.
With my deployed Next.js and Supabase apps, the sign-in-to-dashboard journey had felt noticeably slower. I had grown used to the wait, so I hadn't thought much about it. Then I used this deployed version and realized how much I had been tolerating. If I noticed it immediately as the developer, I started wondering what that delay had felt like to users.
I suspect the architecture helped. Authentication and application logic run in the Worker, and the app talks to D1 through a Cloudflare binding rather than making a separate request to a Supabase API for that path. The repo also places the Worker near the D1 primary. Fewer trips across services made the whole flow feel more direct to me. But I haven't timed equivalent production flows under controlled conditions, so I can't attribute the entire difference to one framework, database, or provider. The moment I can describe honestly is the one I experienced: I clicked Sign in, and the dashboard was just there.
Claude helped me set up Better Auth with TanStack Start and Cloudflare. I gave it project instructions and skills so it could keep the architecture and decisions in context as we worked. I still had to choose the approach and check what it built. That process let me take on setup I previously would have avoided for the sake of shipping quickly. The fast sign-in was the moment that made me stop and question my default stack.
Cloudflare also had answers for more of the services I had previously assembled separately. D1 gave this project a SQLite database, R2 handled files, Durable Objects powered realtime, and Workers, Queues, Cron Triggers, and Workflows covered the application and background work. Better Auth runs in the app. Email delivery is available through Cloudflare's Email Service when configured.
That does not mean every Supabase or Postgres project should move to D1. It means I could build this product with fewer separate accounts and integrations than I expected.
The feeling didn't stop at sign-in. Moving between routes in TanBase Core felt quicker, and I found fetching and caching easier to reason about with TanStack Router and Query. I could see when data was loaded, when a query was still fresh, and when I wanted to invalidate it. I haven't run a controlled comparison of equivalent apps, so this is how these projects felt to build and use, not a claim that TanStack Start always outperforms Next.js.
What I missed from Next.js
Switching also reminded me how much Next.js had been doing for me. Font loading, image optimization, metadata, and Open Graph images had familiar first-party paths. I could reach for next/font or next/image and move on. With TanStack Start, I had to make more decisions myself: which font package to use, how to serve and compress images, how to generate preview images, and how to organize the SEO details for each route.
TanStack Start supports server rendering and SEO metadata. The difference for me was how much of the surrounding setup I needed to choose and assemble. In TanBase Core, I used Fontsource for the font and Takumi for preview images, then handled route metadata, the sitemap, and the robots policy. I had to think through image handling rather than reaching for my usual next/image workflow.
That extra work is real. This is where AI agents changed the equation for me. I could choose Fontsource and Takumi, ask Claude to help implement and document the setup, then review the code and change what I didn't like. I didn't have to accept a bundled choice just because implementing an alternative would take too long. I liked knowing which library handled each piece and being able to replace it when my needs changed. The control felt worth the setup for this project.
The small limits that start shaping a product
I had already run into a scheduling limit before TanBase Core. I was exploring a product idea for scheduling social media posts. Publishing at a time the user chooses is central to that idea, but when I looked into Vercel's cron limits, the free plan couldn't give me the frequency or timing precision I needed. I stopped working on the idea at that point rather than upgrading for an experiment.
Reminders in TanBase Core brought that decision back. The app checks for due tasks every hour, puts reminders on a queue, and sends them from a queue consumer. This is exactly the sort of feature that sounds small until your platform's scheduling limits start deciding how you build it.
Vercel Cron Jobs are available on the free Hobby plan, but each job can run at most once a day, and the invocation can happen at any point within the specified hour. An hourly reminder job needs Pro, where schedules can run as often as once a minute with minute-level precision. So it isn't accurate to say cron itself is Pro-only; the frequency I wanted is.
Cloudflare Cron Triggers support schedules as frequent as every minute, including on Workers Free. The free plan has tighter limits: five triggers per account and 10 milliseconds of CPU time per cron invocation. TanBase Core uses Workers Paid, which starts at $5 a month and has its own usage limits and charges. I'm not claiming a universal cost win. I just liked being able to put the hourly schedule, queue, and Worker code in the same project without changing plans to unlock the schedule.
What I think now
I still respect Next.js and Vercel. Their developer experience is excellent, and some of their defaults are things I now have to build or choose myself. AI agents made that work manageable enough for me to consider other options. They gave me more room to choose and own the setup, so Next.js and Vercel are no longer the automatic answer every time I start a project.
I can't give you a like-for-like bill or a benchmark number for the two stacks yet. What changed my mind was using the deployed apps and feeling the difference in the flows I cared about. TanBase Core runs on Cloudflare Workers Paid, with a $5 monthly starting plan and usage that can add to the bill. The repo explains what it needs and how to deploy it.
The freedom I mean is being able to choose the tools and understand the implementation I ship. TanBase Core uses Cloudflare services, so moving it to another provider would still take work. But I no longer feel that the effort of setting up a different stack makes the decision for me.
I tried another way to build, liked the development experience, and turned what I learned into something other people can use. If you're choosing a stack, try the flows your users will repeat every day, not just the deployment button. If you're building alone, check the limits on the small features your product actually needs. And if you're curious about this particular foundation, explore TanBase Core on GitHub or try the live demo. I'd love to hear what you would keep, remove, or build with it.