Separting Frontend
from data and logic
Arriving at an architecture
A journey towards a three-layer architecture to scale frontend applications: a presentation frontend, a Backend for Frontend (BFF) middleware layer for data transformation and business logic, and a backend core.
Shifting focus
Working with AI
AI tools have shifted my focus from writing code to architecting systems and engineering context. New standards like MCPs and Spec-driven development help AI agents do more.
Style and consistency
Design systems that adapt
The right design system isn't the most sophisticated one—it's the one that matches your current team and app constraints while remaining flexible enough to adapt as you grow.
Photo by Pierre Châtel-Innocenti on Unsplash
Separting Frontend
from data and logic
Landing on an Architecture
As a fullstack developer who's spent considerable time building with React and Next.js on the frontend and Node.js on the backend, I've learned firsthand how quickly frontend applications can become unmaintainable as they scale. My experience building Arti, a niche platform designed for the art community, taught me invaluable lessons about architecture, scalability, and the critical importance of separation of concerns.The Arti project required rapidly iterating on features like location-based features and user preference systems while constantly updating the frontend interface without disrupting existing functionality. What started as a straightforward prototyping exercise soon evolved into a complex web of interconnected logic. As features accumulated, I found myself wrestling with a growing tangle of problems: UI components intertwined with data fetching logic, business rules scattered throughout the codebase, and modifications that threatened to break entirely unrelated parts of the application. These scaling challenges made even simple prototype iterations time-consuming and error-prone.After experimentation with various architectural approaches—monorepos, microservices, and Jamstack configurations—I discovered a solution that elegantly balances both rapid development and sustainable scalability. By adopting a layered architecture pattern with Backend for Frontend (BFF) principles, I was able to completely decouple the user experience layer from data management and business logic. This article shares the architectural decisions, core principles, and practical implementation details that transformed Arti from a fragile prototype into a robust, maintainable platform.
TL;DR: A journey towards a three-layer architecture to scale frontend applications: a presentation frontend, a Backend for Frontend (BFF) middleware layer for data transformation and business logic, and a backend core.
Frontend Scalability Challenges
When you start prototyping, the frontend feels simple—just UI and some data feeds. But then auth, queries, and rules sneak in, and suddenly your React components are doing too much. For Arti, that meant big updates (like adding new tools or user options) risked breaking everything. My goal: Make the UI a light presentation layer that stays quick to tweak, while pushing data and decisions to the backend.When we talk about scalable frontend development, we're addressing multiple interconnected challenges that become increasingly urgent as projects grow. Some common chllanges to scalability:Code Organization and Complexity: When prototyping, the frontend appears deceptively simple—just some UI components and data connections. However, as applications mature, authentication logic, complex queries, and business rules inevitably proliferate. Components begin implementing data fetching alongside presentation, state management logic bleeds into UI concerns, and simple UI updates risk cascading failures throughout the application. For Arti, major updates like adding new tools or user capabilities threatened the entire system's stability.
Performance Bottlenecks: As frontend applications become more complex, inefficient code patterns, excessive re-rendering cycles, and direct database access can dramatically degrade performance and slow load times. These issues become exponentially harder to diagnose and fix when concerns are intermingled.
State Management and Data Flow: Scalable frontend development requires effectively managing how data flows through the application and how state is shared between components. Without proper architecture, you encounter data duplication, inconsistent user experiences, and debugging nightmares that multiply exponentially with codebase size.
Cross-browser Compatibility and Maintenance: As the codebase expands, maintaining consistent behavior across different environments becomes increasingly challenging and requires careful architectural consideration.
Team Collaboration: Larger teams need clear code structure and organization to work efficiently on different components without stepping on each other's toes. Tangled codebases create friction and slow development velocity.
The Layered Stack Architecture
After careful consideration, I settled on a modern Jamstack architecture that cleanly separates concerns and scales beautifully. This approach uses Next.js for the frontend, serverless functions as middleware, and Supabase for backend services. Here's how the layers work together:—Layer 1: Frontend Web Experience LayerNext.js handles rendering and the complete user interface. This layer contains reusable React components—buttons, modals, data grids, art display cards—all pulled from a carefully curated design system library. These components are purely presentational with zero business logic or data-fetching concerns.
The key insight: this layer knows nothing about where data comes from or how business rules operate. Components simply receive data through props and render it. This isolation enabled rapid prototyping; I could experiment with layouts, themes, and user interactions without touching backend systems at all.Benefits:
• UI designers and frontend developers can work independently from backend teams
• Components remain simple, readable, and maintainable as the project grows
• Easy testing of components in isolation using tools like Storybook and Jest
—Layer 2: Intermediate API Layer (Backend for Frontend)This is the critical architectural piece that enables scalability. Serverless functions deployed through Next.js API routes create a boundary layer between the presentation tier and backend systems. This Backend for Frontend (BFF) layer serves multiple crucial functions:
Security and Authentication: Handles secure credential exchange with Supabase for user authentication, session management, and authorization checks before exposing any data to the frontend.
Data Transformation and Aggregation: The BFF bundles and transforms raw backend data into frontend-optimized shapes. For example, instead of the frontend making multiple requests and assembling data, the BFF might combine user location data, preference settings, and real-time collaboration status into a single, clean API response. This shields the frontend from complex queries and business logic.
Access Control and Privacy: Implements business rules about which data users can access. Instead of pushing this logic to the frontend (where it can be circumvented), the BFF enforces permissions and filters data server-side before sending it to clients.
Caching and Performance: Implements intelligent caching strategies, request deduplication, and data batching to optimize performance without burdening frontend code.
Direct Database Protection: The frontend never touches the database directly. All data access flows through the BFF, providing a single point for security audits, performance monitoring, and optimization.Running on Vercel, this layer scales independently and automatically. Early in Arti's development, I mocked this layer with dummy data, enabling feature prototyping at extraordinary speed. I could build location-based feed interfaces, test user interactions, and refine the experience in hours—only later connecting the live Supabase backend.
Benefits:
• Frontend and backend teams can work in parallel with clear contracts
• Easy to modify backend data structures without breaking frontend applications
• Central point for implementing cross-cutting concerns like logging, error handling, and monitoring
• Serverless architecture provides automatic scaling and cost efficiency
—Layer 3: Backend Core LayerSupabase handles the foundation: a PostgreSQL database for persistent storage, built-in authentication services, file upload capabilities for art assets, and real-time database subscriptions for collaborative features. All business logic lives here or in the BFF layer—completely isolated from direct frontend access.This architecture means the backend can evolve independently. Database schema changes, query optimizations, and business rule refinements happen without touching frontend code. The contract between frontend and BFF remains stable even as backend implementation details shift.
What I Learned and Tips for Next Time
Early iterations had too much overlap between layers, dragging down deployment velocity and creating maintenance headaches. What eventually clicked was treating the frontend as purely an "experience" layer—not a compute layer, not a data access layer, just presentation.This mental model fundamentally changes how you design APIs and component interfaces. You stop asking "what data does the UI need?" and start asking "what's the minimal shape of data that cleanly represents this user experience?" This shift toward experience-oriented thinking dramatically improves architecture quality.I'm currently exploring GraphQL as a next evolution. GraphQL's flexible query language could provide even better abstraction between frontend and BFF layers, allowing frontend code to request exactly the data it needs without backend changes.The additional complexity of layered architecture does create some friction during debugging—tracing data flow across multiple layers requires careful instrumentation. However, this cost is trivial compared to the maintainability and scalability gains. Proper monitoring with tools like Sentry transforms debugging from painful to manageable.
The Bigger Picture
Frontend scalability isn't achieved through any single technique but through thoughtful architecture decisions that respect the separation of concerns, enable team collaboration, and keep each layer focused on its specific responsibility. The BFF pattern deserves particular attention as a practice that enables teams to scale both their applications and their engineering organizations.Bottom line: Decouple early with BFF patterns and clear architectural layers. This keeps your projects breathing as they grow. If you're building something that needs to scale, implement this layered approach from the start. The initial investment in architecture pays continuous dividends in reduced complexity, faster iterations, and confident deployments.The goal isn't perfection—it's building systems that your team can confidently modify, extend, and maintain as requirements evolve and scale demands grow.
Photo by Pierre Châtel-Innocenti on Unsplash
shifting focus
Working with AI
As a fullstack developer who's spent years building React/Next.js apps, I always loved the craft of coding from scratch. But after months with GitHub Copilot—especially its agent mode—something fundamental shifted in my daily workflow. It's not about less work; it's about smarter work, pushing me to refine my practice and focus on what truly adds value.
If AI can write increasingly better code, how do we adapt our practice to stay valuable and fulfilled? After working through these shifts in my own practice, I've found that the role isn't disappearing—it's transforming into something more strategic and arguably more interesting.
TL;DR: AI tools have shifted my focus from writing code to architecting systems and engineering context. New standards like MCPs and Spec-driven development help AI assistants do more.
From Developer to Architect
The shift happened gradually, then all at once. Early on with Copilot, I'd let it autocomplete functions and components, saving a few keystrokes here and there. But as I got more comfortable—and as the tool got better—something fundamental changed in how I approached work.My practice has evolved in two critical ways. First, conceptual work took center stage. Instead of grinding out HTML/CSS/JS boilerplate or debugging syntax errors, I now spend my time planning architectures for major features before any code gets written. While AI handles routine coding, I get to focus on architecture, problem framing, and integration—the things that require human judgment and domain expertise.The first main lesson I learned along the way is to never trust AI output fully. After an early async bug that made it to staging, I now review every generated line with the same scrutiny I'd apply to junior developer code.Second, quality infrastructure became non-negotiable. I've made tests, consistent code style, and naming standards the foundations of every project. ESLint and Prettier enforce style automatically, custom Copilot instructions embed our conventions directly into generation, and comprehensive test suites catch what AI misses—and it misses things.This mirrors what Stef van Wijchen articulates in "The Self-Trivialisation of Software Development": "The frontier keeps moving … when lower level tasks become trivial, my development focus is moving to higher level problems." The value of developers increasingly lies in deciding what to build, ensuring it's architecturally sound and correct, guiding AI tools with the right constraints, and understanding the business domain deeply enough to spot what AI can't.The more I use AI in my daily practical work, the more I agree with Rahul Dinkar's article How Senior Frontend Engineers Actually Use AI at Work which highlights that senior frontend engineers effectively use AI for tasks like generating boilerplate, performing mechanical refactors, and scaffolding tests. However, AI consistently falls short in complex areas requiring deeper understanding, such as architectural decisions, performance reasoning, and debugging asynchronous issues. Ultimately, AI serves as "leverage on clarity," and they excel when the solution is well-defined but may amplify confusion when the problem itself is ambiguous.
State of AI Tools
The AI tooling landscape has exploded in the past year, and it's hard to keep up. GitHub Copilot remains my go-to for in-editor assistance after trying others like Cursor and Zed . The agent mode is a game-changer—it can implement entire features from natural language specs, refactor across multiple files, generate tests based on implementation, and suggest architectural improvements.What excites me most is the move toward agentic AI—tools that don't just complete code but actively collaborate on development tasks. I recently used Copilot's agent mode to migrate a legacy authentication system. I provided the high-level requirements, and it generated the migration plan, implementation code, and test suite—then iteratively fixed issues as tests failed.My role as a developer now starts with providing high-level requirements of the new features along with the bigger architectural overview. And in a way not unlike TDD (Test Driven Development), tests become especially important and I find myself paying them more attention to ensure edge cases are covered and validated.Different AI tools are emerging for specific development needs too. Code review assistants that understand project conventions, documentation generators that maintain sync with code, performance analyzers that suggest optimizations, and security scanners with AI-enhanced vulnerability detection.
Emerging Standards
Here's where things get really interesting. As AI tools become more capable, the bottleneck isn't the model—it's context. How do we help AI understand our projects, conventions, and constraints without overwhelming it?
Model Context Protocol (MCP) is emerging as a standard way to expose project context to AI tools. I think of it as an API for the LLM model.I've started experimenting with MCP servers that provide project structure and component relationships, coding conventions and style guides, common patterns and anti-patterns specific to our stack, and testing requirements and quality gates. Tools like Context7 and implementations like DevTools MCP are making this practical.Instead of re-explaining our architecture in every prompt, the AI can query the MCP server for relevant context. In a recent Next.js project, I set up an MCP server that knows our API layer conventions. Now when Copilot generates API routes, it automatically follows our authentication patterns, error handling standards, and response formatting—without me specifying it each time.The DevTools MCP allows AI coding assistants to see and interact with a live Chrome browser. This basically allows the LLM response and code suggestions to see how their changes affect the frontend visually and to see its network calls. In other words, it can debug its own output. In addition, it can help analyze and suggest improvements for the application’s performance, as well as simulate user interaction and run more complicated test scenarios.Beyond MCPs, there's a broader movement toward AI Engineer Optimization (AEO)—optimizing codebases to be more AI-friendly. llms.txt is a simple but powerful proposed standard that helps LLMs dramatically understand and process a webpage’s content better. It's like a robots.txt for AI inference written in Markdown, and its primary function is to direct LLMs to the most important and relevant content on a site.Anthropic's team nailed it in their context engineering guide: "As models become more capable, the challenge isn't just crafting the perfect prompt—it's thoughtfully curating what information enters the model's limited attention budget at each step."This is becoming a skill in itself. I'm now thinking about what context is essential for this task versus what's noise, how to structure information so AI can parse it efficiently, and when to provide examples versus when to rely on conventions.It's a new kind of information architecture, optimized for AI consumption.More recently, I'm excited to follow up on the latest trends in recent AI build tools. Spec-driven development is emerging as a standard for AI agents, with tools like Agent OS providing a structured context system to guide agents toward production-quality code. GitHub's Spec Kit reinforces this approach by treating specifications as executable artifacts that enable reliable, iterative development with AI coding agents. This methodology represents a significant shift in how developers collaborate with AI to build at scale.
The Road Forward
So where does all this lead? Based on my experience and where the tools are heading, I see developers evolving into what I'm calling Solutions Architects.The lines are blurring between traditionally separate roles. AI handles implementation details, so I can focus on product value. Rapid prototyping becomes trivial, enabling more exploration. The gap between idea and demo shrinks dramatically. I imagine developers being increasingly involved in product planning discussions. This would elevate the cooperation level between them and product managers, and the conversation would shift from "Can we build this?" to "Should we build this?"This connects to a broader shift I'm excited about: using AI to run inexpensive experiments at scale. I’ve written more about this in a separate article here. [link]Looking ahead, successful developers will excel at context engineering—making projects AI-friendly through new standards. Quality means designing tests and review processes that catch AI failures. Architecture and integration work involves solving the problems AI can't intuit: How do systems fit together? What are the non-obvious edge cases?My advice if you're navigating this transition:
• Start with solid foundations—tests, style guides, naming conventions. Never fully trust AI output and develop a rigorous review practice.
• Shift your focus toward architecture, problem framing, and product value. Use AI to run cheap experiments and validate ideas quickly.
• Invest in defining your AI assistant’s context. Experiment with emerging standards like MCPs.I see the future of development as being collaborative—human insight guided by AI execution— and it opens up many new possibilities.
Photo by Pierre Châtel-Innocenti on Unsplash
At the edge
of Planning and Building
Why Product Egnineering
I've noticed something fundamental changing in how I work as a developer. It's not just about shipping features faster with AI assistance—though that's part of it. It's about how the entire relationship between product planning and technical implementation is being rewritten. When you can prototype a feature in hours instead of weeks, the whole product development process changes. Suddenly, you're not choosing between careful planning and rapid building—you can do both simultaneously.The question isn't "Should we build this?" but "Let's build three versions and see which works." This raises some interesting points: How do traditional product planning methods hold up when prototyping becomes nearly free? What happens to the PM-developer boundary when developers can turn ideas into demos before the spec is finished? How do we take advantage of cheap experiments to build better products? After working through these shifts in my own practice—moving from traditional agile sprints to more experimental approaches—I have some thoughts on where we're headed.
TL;DR: AI may create a hybrid Product Engineer role that bridges planning and implementation. When experiments are cheap, the optimal strategy shifts from perfecting one idea to rapidly testing multiple approaches and learning from the results.
Product Planning: Traditional vs. Emergent
For years, I've worked in teams following the classic agile ritual: the two-week sprint cycle with backlog grooming, sprint planning, daily standups, sprint review, and retrospective. This works really well when requirements are relatively clear, you're building known features for an established product, the team needs predictability for coordination, and stakeholders want regular visibility into progress.Traditional agile methods work well for clear requirements but struggle with discovery and innovation. Basecamp's Shape Up methodology offers an alternative approach that addresses these challenges. It uses six-week cycles with distinct phases: shaping, execution, and cool-down. This structure separates exploration from execution, uses "appetite" rather than estimates, and empowers teams to solve problems within time constraints rather than following detailed specs.What I love about this is that shaping separates exploration from execution—the discovery work happens upfront with lower commitment. It uses appetite over estimates: "We'll spend six weeks on this" rather than "This will take six weeks." Teams own the scope, not handed detailed specs but trusted to solve the problem within time bounds.
The Hybrid Role: Product Engineer
AI has transformed the distance between idea and working demo. With AI tools, I can now turn a product idea into a working prototype in hours, create multiple feature variations for comparison, and validate assumptions with real code. This has given rise to what I think of as the new Product Engineer role—a hybrid professional who operates at the intersection of product and technical domains.Product Engineers possess product intuition to understand user needs and business value, technical expertise to implement ideas rapidly with AI assistance, an experimentation mindset to validate through prototyping, and communication skills to bridge PM and technical languages. In my current role, this process involves rapid prototyping, demoing working prototypes, and refining the chosen approach, saving significant time while exploring multiple options.This is giving rise to what I think of as Product Engineers—people who operate in both domains. They have product intuition and understand user needs and business value. They have technical chops and can implement ideas rapidly with AI assistance. They have an experimentation mindset and validate through prototyping, not debate.
The Time is Right for Cheap Experiments
This connects to a broader principle I've been thinking about, inspired by Michael Schrage's work on innovation. In his research, particularly in "The Innovator's Hypothesis" and related work, Schrage argues his "5×5" principle: Five teams working on five variations of an idea will outperform one team trying to perfect a single approach.Why? Because we're bad at predicting what will work—even experts guess wrong regularly. Experiments reveal hidden insights because working prototypes expose problems that specs miss. Cheap experiments change everything since when failure is inexpensive, you can try more things.And learning compounds as each experiment improves the next one. The bottleneck in innovation isn't ideas—we have plenty. It's testing ideas fast enough to find what works.Here's what's exciting: AI has made technical experiments dramatically cheaper. In the old world, building a prototype took two to four weeks of developer time, cost per experiment was ten to twenty thousand dollars in loaded cost, so we were conservative about what we tested.
A Possible New Model
So what does this all mean for how we actually build products? I see these themes converging into a new product development model with three phases. Phase one is problem shaping lasting one to two weeks where a Product Engineer and PM explore the problem space, use rapid prototypes to test assumptions, identify two to three viable approaches, and define appetite around time and scope boundaries.Phase two is experimental building lasting four to six weeks where the team implements the best approach from shaping, continues running mini-experiments on details, holds regular demos with real working code, and stays comfortable pivoting based on the team learns.Phase three is cool-down lasting one to two weeks for individual experiments and technical cleanup, retrospective on what we learned, and shaping starts for the next cycle.Key differences from traditional agile: prototyping is explicit, not hidden in "research spikes." Experiments inform commitment, not the reverse. Product Engineers bridge planning and implementation. And speed comes from validating fast, not estimating perfectly.
Photo by Pierre Châtel-Innocenti on Unsplash
style and consistency
Design Systems
that adapt
Since my first experience building and developing webpages and up till now, I've always leaned toward minimalist UI. Simple skeleton-like frameworks like Pure.css or Bulma were my first favorites—they're lightweight and flexible, while Bootstrap felt much more heavy-handed and at times even bloated.My journey with design systems has changed across multiple projects and jobs, starting from working as a freelancer to wrangling legacy messes in enterprise gigs to crafting custom setups in modern teams. Let's chart the highlights here along with how my processes and tools have evolved in time.
TL;DR: The right design system isn't the most sophisticated one—it's the one that matches your current constraints (team size, app complexity, immediate needs) while remaining flexible enough to adapt as you grow. Ship with what your team understands, then evolve from real constraints.
A Visual Language
Beyond code and components, design systems are the visual language that defines your brand in every interaction. Consistency in color palettes, typography, spacing, and interaction patterns creates trust—users begin to recognize and anticipate your app's behavior before they consciously think about it. When every button, card, and animation reinforces the same design language, your product feels intentional, polished, and professionally crafted rather than haphazard.This consistency extends to emotional resonance: a well-designed system conveys your brand's values through every pixel, whether that's playful and approachable or precise and authoritative. Strong design systems don't just reduce dev friction—they're the invisible thread connecting your visual identity across platforms, devices, and time. They're how users know they're experiencing your app, not someone else's.
Wrestling with UI Inconsistencies
In my first few jobs, especially those tied to Java monoliths, UIs were a patchwork—scattered CSS files, framework-locked styles, and no standards, leading to slow loads and accessibility blind spots. One standout was migrating source control from Java's old-school versioning to Git, which highlighted just how much technical debt we carried from inline hacks and unused bloat.Across projects, my north stars stayed the same: Nail security (vetting deps rigorously), ensure responsiveness (mobile-ready from the outset), and build in accessibility (aiming for WCAG basics). After that, it was about fostering consistency to make handoffs smoother and reducing debt so future devs (including me) wouldn't undo progress. Each job became a performance lab too—optimizing bundles was non-negotiable for real-user speed.
Evolution
This progression played out over roles, each building on the last to handle growing complexity:—Early Days with Skinny
In my initial enterprise role, post-Java-to-Git migration, I created Skinny—a minimalist version of eBay's open-source Skin. Skin's decoupled CSS was a game-changer: Framework-agnostic styles for grids, buttons, and forms meant we could apply it broadly without React ties. It prioritized our must-haves—secure (no risky libs), responsive (flexible layouts), and accessible (semantic elements). Quick to prototype with, it slashed load times and started chipping away at legacy debt, letting us version styles cleanly in Git. I hunted for decoupled options early, favoring systems where HTML/CSS could stand alone from JS (that "BYOJ" philosophy—Bring Your Own JavaScript—to mix with any frontend).—Exploring Web Components
Wanting framework flexibility without JavaScript lock-in, I experimented with Lit—a lightweight library for building web components that leverage native web standards. Lit provides a component base class (LitElement) that extends the native HTMLElement with reactive state, scoped styles, and a declarative template system using JavaScript tagged template literals. This approach minimizes boilerplate and enables efficient DOM updates by only changing parts affected by state changes. With a minimal footprint of around 5 KB minified and compressed, Lit's interoperability across any HTML environment—vanilla JavaScript, TypeScript, or larger applications—made it appealing for projects needing framework independence. The library supports both tool-free prototyping and robust production workflows, making it ideal for teams wanting standards-based components without heavyweight frameworks.—The Modern Default: Tailwind and shadcn/ui: More recently, I've watched Tailwind CSS shift the entire conversation. Rather than shipping opinionated components, Tailwind provides utility-first styling that lets you compose designs quickly without context-switching between CSS files and component logic. Paired with shadcn/ui—a collection of unstyled, accessible components built on Radix UI primitives and styled with Tailwind—you get the best of both worlds: composability without lock-in, since shadcn/ui components live in your codebase as copy-pasteable source, not a black-box dependency. This approach fits teams that want design system flexibility without heavyweight frameworks. You own the code, control the styling, and can adjust components to match your exact brand language without forking libraries or fighting abstraction layers. For projects where speed and customization matter equally, this combination has become my default reach—it's opinionated about accessibility and interaction patterns (via Radix), but agnostic about how your UI actually looks.—Building a Design System for Microfrontends
Later, in a scalable product team, off-the-shelf limits hit—we needed tailored components for niche flows (e.g., collaborative tools). So, I co-led building our own design system inspired by Grommet basics with Storybook for interactive docs. Designed for microfrontend architecture, it used shared design tokens (colors, spacing) via a monorepo, ensuring harmony across independent modules without a bloated core. Deployed as an internal repo and later open-sourced, it reduced debt from prior jobs and scaled beautifully acroos multiple teams and products.You can explore the evolving design system here.—A Hybrid Approach
In my current role developing the Arti platform, we settled on Grommet as our foundation because our team already knew React deeply, our product was component-heavy, and the built-in accessibility meant we didn't have to bake that in ourselves. Could we have saved a few kilobytes with a leaner system? Sure. But the math was simple: Grommet meant faster shipping, fewer accessibility bugs caught in review, and a team that didn't need to context-switch between frameworks. We are layering custom components as needed on top—we're only extending it when we genuinely find it lacking.That's the discipline: pick the right foundation for your constraints right now, then have the patience to expand within it and add the necessary tools to it. These extensions aren't added to increase complexity; they're about maintaining what you've chosen. The moment you start bolting on side systems, you've traded technical debt for architectural debt, which is often worse.
Commting to a Solid Foundation
Looking back across these roles, each choice made sense at that moment. The pattern is about matching your design system to where you actually are: your app's complexity, your team's size, and what you're solving for right now. At the same time, you want to work with a design system that is flexible enough to easily adapt to your future needs.The trap is over-engineering it. A small team building a focused product doesn't need a custom system— a simple library like Bulma gets you consistent results, ships fast, and lets you focus on product. An enterprise monolith burning cycles on accessibility bugs? A more advanced framework like Tailwind or Grommet with solid foundations out-of-the-box mean you spend energy on larger features.The experienced move is picking the one that fits your constraints and committing to it. Once you've shipped, you learn what your product actually needs versus what sounded good in theory. That's when thoughtful expansion happens—but only then. Start with a solid foundation your team understands, ship it, and evolve from real constraints, not speculative ones.
Thank you
Adipiscing mi ac commodo aliquet ultricies viverra. Massa placerat duis ultricies lacus sed turpis sit fulminare justo veroeros etiam.