The Future of Web Development is Modular, Not AI

In the age of ChatGPT and Copilot, it's easy to assume the future of web development will be entirely AI-generated. Prompts in, production apps out. But in practice, AI tools mostly automate boilerplate and syntax suggestions. They still rely on human architecture, judgment, and iteration to make the right choices and ship production-ready code.

If you want to ship faster today, the answer isn't smarter prompts. It's better building blocks.

The Case for Modularity#

Rebuilding the same features in every project is the real drain. Auth systems, blogs, dashboards, feedback forms, newsletter signups, admin panels , we all build them again and again. Sometimes we scaffold from a starter repo. Sometimes we copy from our last project. But most of the time, we're writing glue code and boilerplate that doesn't need to exist.

The shift we need isn't AI generation. It's modular, full-stack features that are portable, typed, and drop-in.

What Modularity Looks Like#

Modular web development isn’t a new idea , component libraries brought it to the UI layer. But we're finally seeing the concept expand to the full stack:

• better-auth: An open-source auth system that works across React frameworks and adapters. Drop in an auth provider, session handling, and access control logic without rewriting it for every project. One of the key enablers of its portability is its abstraction over the data layer, powered by Kysely, a type-safe SQL query builder that makes database interactions composable and framework-agnostic.
• better-auth-ui: A companion UI library to better-auth that provides prebuilt, accessible auth components designed to plug into any React framework. It embraces override patterns and smart defaults so you can use it out-of-the-box or bring your own design system.
• zenstack: Extends Prisma to add access policies, metadata, and end-to-end type safety. It turns your schema into a source of truth and lets you compose secure, modular backend logic with minimal code. ZenStack v3 is also migrating to Kysely to unlock greater portability across runtimes and frameworks.
• fumadocs: A modular documentation engine built on MDX and Tailwind. It lets you plug in search, navigation, theming, and versioning instead of rebuilding a docs site from scratch.
• tRPC: Enables fully type-safe client-to-server communication without REST or GraphQL overhead. It adapts to any backend , Express, Next.js, Remix , and brings predictable type inference all the way from database to UI. tRPC proves that it's possible to design a library that works across any backend by decoupling transport, embracing runtime-agnostic abstractions, and maintaining tight type safety from end to end.
• shadcn/ui: Revolutionized the frontend component ecosystem by blending design freedom with developer autonomy. With the introduction of the shadcn registry, anyone can now distribute, remix, and version their own components , not just install them. It bridges the gap between design systems and developer ergonomics, setting a new standard for what a modular UI system can be.
• TanStack Query: One of the most mature and thoughtful state synchronization libraries in the React ecosystem. It enables rock-solid data fetching, caching, and background synchronization across both CSR and SSR contexts. With powerful primitives like query invalidation, stale time, and hydration strategies, it gives developers fine-grained control over how and when data flows. It acts as the connective tissue between UI and data, without requiring you to write reducers, effects, or custom hooks. By abstracting away fetch orchestration and cache management, TanStack Query helps keep modules clean, composable, and runtime-aware.

All of these tools share the same philosophy: stop rewriting infrastructure and start assembling with intent. That means fewer internal rewrites, less duplication of effort, and more trust in small, stable units of functionality that can be composed like LEGO , horizontally across the stack. It’s not just about speed , it’s about enabling teams to think at the level of features, not glue code. By sharing abstractions around transport (tRPC), data (Kysely), and presentation (shadcn), we start to see a web where each layer speaks a common modular language.

The Anatomy of a Great Module#

So what makes a module worth reusing?

Let’s look at the standout examples mentioned earlier , better-auth, zenstack, shadcn/ui, tRPC, fumadocs, and TanStack Query , and extract the shared DNA that makes them great.

Truly modular systems aren’t just packaged code , they’re carefully designed to adapt and scale. Here’s what separates good modules from great ones:

• Typed and predictable interfaces: They expose clearly defined contracts so you can reason about them without digging into internals.
• Overridable components and logic: Whether it’s a UI form or an API handler, you can replace or extend just the part you care about.
• Storage and transport flexibility: They don’t lock you into a database or network layer. Tools like better-auth use clever data layer abstractions over your database , you bring your schema, they handle the glue.
• Framework-awareness without coupling: A good module works across Next.js, Remix, TanStack Router , respecting framework conventions but never depending too tightly on them.
• Stateless where it matters: Modules that avoid global state and side effects can live anywhere , from your dev server to the edge.
• Design-token aware and themeable: shadcn/ui demonstrates how UI systems can be modular without being rigid , letting teams inject their branding while maintaining access to rich primitives.
• Composable: Fumadocs turns docs into composable building blocks with navigation, theming, and structure , much like app shells.
• Runtime-adaptive logic: tRPC and TanStack Query demonstrate thoughtful approaches to runtime flexibility. While configuration and optimization may vary across these contexts, the core logic remains portable and framework-friendly without requiring deep rewrites.
• Isomorphic execution: great modules run consistently in both server and client environments, exposing a single interface while adapting behavior based on where they execute. This allows features like auth, routing, and data fetching to behave uniformly across SSR and CSR without separate code paths.

When a module is designed this way, it becomes a quiet but powerful part of your system. It integrates cleanly without demanding your attention, yet handles complexity that would otherwise take days to recreate. This quality is not accidental. It reflects shared design values , clear type boundaries, framework-agnostic abstractions, and override patterns. These values allow features to scale across the entire stack, not just within isolated layers. Good modules are not isolated blocks , they are slices that cut across data, API, and UI in a cohesive unit. That is the shape of modern modularity: architecture that fades into the background while making everything else more composable, portable, and maintainable.

Modularity vs. Low-Code vs. AI#

To be clear: modularity is not low-code. It’s also not AI scaffolding. These approaches might appear similar on the surface, but they operate from fundamentally different assumptions about scale, reuse, and control.

• Low-code tools abstract everything , often too much. They work until they don’t, then leave you stranded when customization is needed.
• AI generation creates code that looks right but might not be idiomatic, composable, or maintainable. You still have to integrate it.
• Modular systems offer reusable, inspectable, versionable building blocks. They’re code-first, opinionated (when helpful), and respectful of your architecture.

Modular libraries live in your node_modules, not in a cloud IDE. They integrate with your system rather than isolating you from it. They work because they respect how real teams build software , across layers, over time, and with the need for control and flexibility. Unlike low-code tools, which often impose rigid abstraction layers, or AI tooling, which generates scaffolding but not architecture, modularity offers tools that align with your stack’s patterns.

This is where ideas like runtime awareness, typed interfaces, override patterns, and horizontal slice architecture come into play. Modularity scales not because it hides complexity, but because it organizes it. These systems let developers focus on product decisions instead of plumbing. They encode architecture without freezing it.

In this sense, modularity is the practical response to the promise of AI. Rather than replacing developers, it amplifies them by giving them powerful, reusable primitives that ship fully formed functionality with open hooks. You still need to decide what to build , but now, you can do so with confidence and speed.

Looking Forward: What a Modular Ecosystem Unlocks#

What happens when modularity isn't just a tool, but a shared standard across the ecosystem?

We move from reusable components to interoperable ecosystems.

Imagine a world where libraries are not siloed projects, but cooperative units in a common language , each plugin typed, portable, and runtime-agnostic. Where you can wire up better-auth with ZenStack, add fully functional auth routes and sign in, sign out, and sign up pages, and drop in a modular blog that only admins can edit , all without touching glue code. This is modularity as feature composition, not just scaffolding. Each unit is independently versionable, testable, and composable across your stack.

This future unlocks:

• Composable features across teams and companies: Imagine grabbing a Stripe checkout plugin built by one team, integrating it into your project in minutes, and still being able to override validation and UI as needed.
• Ecosystem-level velocity: As libraries begin aligning on conventions , typed interfaces, data layer abstraction, portable request handlers , the entire dev stack becomes swappable and programmable.
• Marketplace of modules: Instead of npm packages that give you a function, you get entire features , admin panels, analytics dashboards, onboarding flows , all versioned, audited, and typed.
• Better tooling and DX: Imagine your devtools recognizing plugins and visualizing their boundaries, migrations, and even performance characteristics across your app.
• Infrastructure fluidity: With tools like Kysely or tRPC, backend logic becomes portable between serverful and serverless environments. Modules stop assuming where they will run.

This is already happening , just unevenly. Tools like shadcn/ui on the frontend and ZenStack and better-auth on the backend are converging around a shared belief: features should be portable, inspectable, and ownable. One example of this philosophy in action is Better Stack (@btst) , a full-stack plugin system for React apps designed to bundle backend routes, database schemas, API logic, and frontend pages in a single installable unit.

Better Stack enables this modularity with just a few lines of code. For instance, wiring up full-stack features with their backend logic and frontend routing looks like this:

// backend routes
const stack = betterStack({
  basePath: "/api/data",
  plugins: {
    blogPlugin(),
    aiChatPlugin(),
    newsletterPlugin(),
    roadmapPlugin(),
  },
  adapter: prismaAdapter()
});

And on the client:

// frontend routing, meta tags, and sitemap entries
const client = createStackClient({
  plugins: {
    blogPlugin(),
    aiChatPlugin(),
    newsletterPlugin(),
    roadmapPlugin(),
  }
});

This is not just boilerplate automation. It is feature composition at its best, where modular systems deliver real product value with minimal setup. With proper typing, extensibility, and runtime awareness, Better Stack turns full-stack capabilities into portable modules that align with the principles outlined throughout this post.

It is not only about reuse. It is about building systems that empower teams to move faster, more confidently, and with less friction.

We have had component ecosystems for years. Now is the time for feature ecosystems, where modular functionality is as plug-and-play as design components.

Final Thoughts#

We do not need to wait for AI to write production apps. We need to standardize how common features are built, shared, and reused. The real breakthrough is not more autocomplete. It is treating features like components , not just UI components, but full-stack, typed, integrated modules that span database, server, and client.

Imagine building a product where adding a feature means dropping in a real, production-grade system with data models, endpoints, and UI, all wired up. This is the promise of modularity, and the ecosystem is already evolving to make it real today.

Build with better blocks.