Kaizen Teams

Dropdown

Table of Contents

Dropdown
Time to read

·

12

Published on

·

August 20, 2020

Last updated on

·

February 16, 2026

Pablo Marcano

Technology

Over-Engineering in React: Lessons & Mistakes to Avoid

Published on

·

February 23, 2026

Last updated on

·

February 16, 2026

Time to read

·

12

Pablo Marcano

React can be so simple and so powerful that it is one of the first choices when it comes to building a web app nowadays. But with great power comes great responsibility. Being so widespread and used, it's easy to find tons of results when looking for solutions that fulfill developer needs, but the most popular solution may not always be the best for every case.

In this article I’m going to cover some common patterns and tools developers tend to blindly stick to without assessing whether they actually apply to their specific use case or not.

Using a Library for State Management

Don’t get me wrong, correct state management is a fundamental part of building a reliable, scalable, and futureproof application. It’s particularly important to take it into account early on in our projects, but you might want to think twice before just starting with a template based off of  [insert popular state management library here]. There are a several reasons why I think this way:

  • It forces you to think and model your application in the library's way of doing things, instead of making choices that could reflect the business reality in a more accurate way. Whether you use redux or mobx (or nothing at all) should depend on if it makes sense for your use case, and not simply on what’s trendier.
Official State Library for React
  • You may be making your app less performant. Bundle sizes and performance on lower end devices are metrics that we as developers tend to gloss over, but can end up making a huge difference on the way your users interact with your product. Also, there’s more library code that when used incorrectly may lead to unwanted re-renders, thus making your app less responsive.
A graphic
  • At the end of the day, it’s something new you need to learn, document, teach, maintain, and upgrade over time. This is the key factor when deciding to use a state management library or not: will it save you enough time and make your life that much easier in the long run that it’s worth teaching it to every new developer that joins the project? Will you have the time to document a specific scenario where you do things differently? Are you willing to upgrade all of your codebase because of a breaking change? If the answer to all of these questions is yes, then go ahead.

Creating Too Many Files/Folders

If you come from a framework like angular, you may be familiar with the idea of creating a couple of files and a folder just to organize your independent UI components. Add modules, routing files, indexes, and services and you’ll end up with a lot of boilerplate to make things work the way you want in any given scenario. Boilerplate is not a bad thing per-se, but with React we’re not required to have this much ceremony in order to build our apps.

A computer screen with lines of code

Now, I’m not saying you should go and delete all of your .js files and bake everything in the same file, but embracing the flexibility the framework gives you will help you create apps that are easier to navigate through, and therefore, are more maintainable. The official React documentation even encourages this approach, and provides us with some guidelines to take into account when laying out our app structure.

Here are some things I do to avoid unnecessary nesting/file creation:

  • Don’t create boundaries where there are none: While it’s pretty common to  consider that everything apps are made of is screens and components, what actually differentiates one from another? What you think of today as a component may become a screen down the road, or vice versa. Whenever your domain makes it clear that some things should belong to a folder, then go for it. Creating an extra file folder before the need comes up just creates extra work. Dan Abramov talks more about this in this article where he clarifies the difference between presentational and container components—but beware! You’ll actually find a disclaimer where he talks about how his views have changed since the writing of that article.
  • Leverage the power of hooks: You may be tempted to create new files as new complex components start forming, and eventually you might want to put together components that share similar logic in a folder. The thing is, you may be able to avoid all of the added complexity of similar-yet-specific components by using hooks to properly reuse your logic.
  • Use Styled Components: Styled Components can help keep all the styling and the logic related to it within the same file most of the time. This depends greatly on each use case, but they’ve gained popularity because of their flexibility and simplicity to setup, read, and maintain across my apps.

Testing the Wrong Places

While a robust testing suite should be a priority whenever you ship a product that will continue being developed in the future, testing the wrong places could be the source of many frustrations and time wastes, especially on the frontend. Let’s first define what these “wrong places” are and aren’t.

Kent Dodds writes in How to know what to test

“When writing code, remember that you already have two users that you need to support: End users, and developer users. Again, if you think about the code rather than the use cases, it becomes dangerously natural to start testing implementation details. When you do that, your code now has a third user.”

In this post we’re talking about how to make the “developer users” happier. If you’re able to write tests that will actually detect bugs in the future, you’ll inevitably be happier. How do you achieve this? By testing your app the way the users would, avoiding high-effort/low-value code chunks, and writing concise and understandable tests.

Let’s break these down one by one:

  • Testing the way users would use the app: Here I strongly recommend reading Kent Dodds Testing Implementation Details, who elaborates on how testing implementation details can lead to error prone tests that aren’t actually very useful for catching bugs.
  • Avoid high-effort/low-value code chunks: If you’re solely using code coverage as your metric to determine the quality of tests (which has its own problems), you’ll often find there’s some code dependant on a third party library that doesn’t quite work as you expected and drags the coverage down. In this case you’ll have to weigh how critical the feature is to the application vs the amount of time you’ll have to spend coding, maintaining, and replicating the functionality across several sections of your app.
  • Write concise and understandable tests: The more simple, explicit, and understandable a test is can reflect how well a functionality is written. While you should avoid making your implementation more complex just to simplify the tests, if your test can describe what the end goal of a functional piece is, a new maintainer might find it easier to read and make changes to the codebase.

While there are no rules set in stone for writing perfect React code, following these guidelines has saved me time and spared me from bugs and unnecessary meetings in my career. I hope it does the same for you.

Do you have any examples of over-engineering in your favorite framework? How do you usually solve them? Leave it on the comments!

React can be so simple and so powerful that it is one of the first choices when it comes to building a web app nowadays. But with great power comes great responsibility. Being so widespread and used, it's easy to find tons of results when looking for solutions that fulfill developer needs, but the most popular solution may not always be the best for every case.

In this article I’m going to cover some common patterns and tools developers tend to blindly stick to without assessing whether they actually apply to their specific use case or not.

Using a Library for State Management

Don’t get me wrong, correct state management is a fundamental part of building a reliable, scalable, and futureproof application. It’s particularly important to take it into account early on in our projects, but you might want to think twice before just starting with a template based off of  [insert popular state management library here]. There are a several reasons why I think this way:

  • It forces you to think and model your application in the library's way of doing things, instead of making choices that could reflect the business reality in a more accurate way. Whether you use redux or mobx (or nothing at all) should depend on if it makes sense for your use case, and not simply on what’s trendier.
Official State Library for React
  • You may be making your app less performant. Bundle sizes and performance on lower end devices are metrics that we as developers tend to gloss over, but can end up making a huge difference on the way your users interact with your product. Also, there’s more library code that when used incorrectly may lead to unwanted re-renders, thus making your app less responsive.
A graphic
  • At the end of the day, it’s something new you need to learn, document, teach, maintain, and upgrade over time. This is the key factor when deciding to use a state management library or not: will it save you enough time and make your life that much easier in the long run that it’s worth teaching it to every new developer that joins the project? Will you have the time to document a specific scenario where you do things differently? Are you willing to upgrade all of your codebase because of a breaking change? If the answer to all of these questions is yes, then go ahead.

Creating Too Many Files/Folders

If you come from a framework like angular, you may be familiar with the idea of creating a couple of files and a folder just to organize your independent UI components. Add modules, routing files, indexes, and services and you’ll end up with a lot of boilerplate to make things work the way you want in any given scenario. Boilerplate is not a bad thing per-se, but with React we’re not required to have this much ceremony in order to build our apps.

A computer screen with lines of code

Now, I’m not saying you should go and delete all of your .js files and bake everything in the same file, but embracing the flexibility the framework gives you will help you create apps that are easier to navigate through, and therefore, are more maintainable. The official React documentation even encourages this approach, and provides us with some guidelines to take into account when laying out our app structure.

Here are some things I do to avoid unnecessary nesting/file creation:

  • Don’t create boundaries where there are none: While it’s pretty common to  consider that everything apps are made of is screens and components, what actually differentiates one from another? What you think of today as a component may become a screen down the road, or vice versa. Whenever your domain makes it clear that some things should belong to a folder, then go for it. Creating an extra file folder before the need comes up just creates extra work. Dan Abramov talks more about this in this article where he clarifies the difference between presentational and container components—but beware! You’ll actually find a disclaimer where he talks about how his views have changed since the writing of that article.
  • Leverage the power of hooks: You may be tempted to create new files as new complex components start forming, and eventually you might want to put together components that share similar logic in a folder. The thing is, you may be able to avoid all of the added complexity of similar-yet-specific components by using hooks to properly reuse your logic.
  • Use Styled Components: Styled Components can help keep all the styling and the logic related to it within the same file most of the time. This depends greatly on each use case, but they’ve gained popularity because of their flexibility and simplicity to setup, read, and maintain across my apps.

Testing the Wrong Places

While a robust testing suite should be a priority whenever you ship a product that will continue being developed in the future, testing the wrong places could be the source of many frustrations and time wastes, especially on the frontend. Let’s first define what these “wrong places” are and aren’t.

Kent Dodds writes in How to know what to test

“When writing code, remember that you already have two users that you need to support: End users, and developer users. Again, if you think about the code rather than the use cases, it becomes dangerously natural to start testing implementation details. When you do that, your code now has a third user.”

In this post we’re talking about how to make the “developer users” happier. If you’re able to write tests that will actually detect bugs in the future, you’ll inevitably be happier. How do you achieve this? By testing your app the way the users would, avoiding high-effort/low-value code chunks, and writing concise and understandable tests.

Let’s break these down one by one:

  • Testing the way users would use the app: Here I strongly recommend reading Kent Dodds Testing Implementation Details, who elaborates on how testing implementation details can lead to error prone tests that aren’t actually very useful for catching bugs.
  • Avoid high-effort/low-value code chunks: If you’re solely using code coverage as your metric to determine the quality of tests (which has its own problems), you’ll often find there’s some code dependant on a third party library that doesn’t quite work as you expected and drags the coverage down. In this case you’ll have to weigh how critical the feature is to the application vs the amount of time you’ll have to spend coding, maintaining, and replicating the functionality across several sections of your app.
  • Write concise and understandable tests: The more simple, explicit, and understandable a test is can reflect how well a functionality is written. While you should avoid making your implementation more complex just to simplify the tests, if your test can describe what the end goal of a functional piece is, a new maintainer might find it easier to read and make changes to the codebase.

While there are no rules set in stone for writing perfect React code, following these guidelines has saved me time and spared me from bugs and unnecessary meetings in my career. I hope it does the same for you.

Do you have any examples of over-engineering in your favorite framework? How do you usually solve them? Leave it on the comments!

Related Articles

View all articles

UX Design
AI
Mariana Mignone, UX Designer at Kaizen Softworks

Mariana Mignone

·

May 27, 2026

What AI Can and Can’t Replace in Design Systems

What happens when you build a design system from v0, Figma, and Windsurf, and let AI handle the speed while you keep the judgment.

12 read time

Read more

Just this month, I built a full design system in about 20 hours.

What used to take weeks, sometimes months, is now dramatically faster. So… what actually changed? And more importantly: what didn’t?

Design systems take time. On complex platforms, they can take hundreds of hours.

We were working with a large and complex product where inconsistencies had started to pile up. Different modules had evolved in isolation, teams were making independent decisions, and there were no shared guidelines. The answer was clear: we needed a design system.

AI tools were just starting to emerge back then. They were mostly useful for simple tasks as they tended to hallucinate when things got complex. Developers had started using them earlier than designers, MCP didn't exist yet, and Figma plugins were the best automation we had.

But the context has changed. Fast.

The Manual Era

We did what most teams did. We stopped, and we built it. Manually.

Picture two designers, a mountain of inconsistencies, and no map. We had to cross-reference information manually, digging through the code, detecting what could be merged, agreeing on naming conventions, deciding how to name components. Hours and hours of discussion until we finally landed on a solution.

In the end, we got there. A cleaner system, faster workflows, and for the first time, both teams speaking the same visual language. Hard-won, but it worked.

But now every month a new AI model seems to be released. Design is finally catching up with what developers faced about two years ago. New tools arose, and with that, the scope of our work as designers completely changed.

The Human Factor

For an internal project, I used our Kaizen site as a reference, combined with documentation from industry leaders as a guideline.

I started in v0, which is essentially a chat interface where you can generate UI components through prompts. I fed it the colors, typographies, and a reference image, and from there it was a back-and-forth: the AI generated, I reacted, adjusted, and pushed until the output matched what I had in my head. And just like that, I started prompting my way through a Design System.

Once a component was ready, I used the html.to.design plugin to bring it into Figma (yes, plugins are still alive!). Think of it as a bridge: the plugin exports designs directly from the browser into a Figma file.

Inside Figma, the intervention was more hands-on. First, I checked that everything was visually consistent with what was defined in v0: colors, typography, styles. Then I used Figma's built-in AI to rename all the component layers using BEM convention (something that would have taken a significant amount of time to do so manually).

BEM, which stands for Block Element Modifier, is a widely adopted naming convention in CSS. It structures layer names hierarchically and predictably, for example: button__label--disabled.

Using it keeps the code clean, readable, and consistent, especially when you're working alongside a developer who needs to understand what came out the other side.

Beyond naming, I also made sure the layer structure would generate the right properties when building component sets in Figma, so that all the variants would be correctly exposed and usable. My team also pointed out that adding descriptions to components and variants was key as context for any agent using them through an MCP.

The last step was connecting everything to Windsurf via MCP. With a frame selected in Dev Mode, Windsurf could read the Figma file and use the components to build more complex screens.

We worked closely with a developer throughout this phase. Not just for the technical knowledge, but because having someone who reads code fluently meant catching things we wouldn't have spotted otherwise. The design role here was direction and supervision: making sure the AI used the components correctly and didn't invent solutions where context was missing.

Every step of the process had a human decision behind it.

AI-assisted UI design workflow showing v0 component generation, html.to.design export to Figma, BEM layer organization, and Windsurf MCP development handoff.

An Unexpected Discovery

At one point, before we had any of the naming conventions figured out, I selected a frame and asked Windsurf to build a form using the components inside it, styled to match a specific card. The developer next to me was skeptical until he saw the result, and then he was just as surprised as I was.

What we realized is that the MCP wasn't reading layer names to understand context. It was reading everything inside the frame, even the loose text sitting alongside the components. Good naming is still worth doing. But the MCP doesn't need it to understand what it's looking at.

UI component library preview with cards, testimonials, service blocks, statistics, and a contact form for a modern software development website.

Learning to Talk to an AI

The more specific and contained your prompt, the better the outcome. We started with the most atomic component: the button, and worked outward from there. Each approved component became context for the next one, so the system gradually picked up the visual language we were building.

At some point I got ambitious and asked for five cards in a single prompt: blog card, service card, testimonial card, stats card, feature card… structures, states and all. The AI delivered.

Visually, everything looked fine. Then the developer looked at the code and pointed out that all five cards were independent components instead of variants of one. For a design system, that breaks everything.

One correction prompt fixed it. But it was a good reminder: the AI does exactly what you ask, not what you mean. And fixing it after the fact can cost more than getting it right from the start.

Some Things Learned Along the Way

  • Precision is key. Natural language is fine when you're asking for a cooking recipe, but when referring to a component, if you say things like "create" instead of "add", you'll probably end up with a whole new set of components instead of additional variants of an existing one.
  • The "Frame" is the context: MCPs can read everything inside the frame you select. This is a game-changer. It means the "naming conventions" debate might be shifting. If the AI understands the context visually and structurally, will we still spend hours discussing nomenclature in 2027?
  • No matter what happens, you can always roll back in less than 5 minutes and start over.
  • Work closely with a developer: they can help you understand MCPs and clear up any code-related doubts. Once you start to grasp their logic, you'll learn very quickly how to prompt in ways that AI actually understands.
  • There's nothing to lose by asking the AI to follow a specific naming convention for the code. It keeps everything clean and readable, and it takes no extra effort.
  • The AI covers roughly 80% of the work (generation, variations, exploration...), but the remaining 20% is where quality lives, and that part is not delegable. The AI executes. The judgment is still yours. And if you skip the review, you're not saving time: you'll spend it later.
  • Context matters more than tooling. What you don't define, the AI will invent. Small components may be resolved well, but large interfaces require more definition from the start. A well-defined system scales. An undefined one generates inconsistencies faster than you can fix them.
  • Figma is no longer the mandatory starting point. It's useful as a visual reference, a QA space, or a consolidation layer. But the AI doesn't need it. We still do.
  • There's no single right workflow yet. What you do depends on the project. We're in a transition moment where the tools change faster than the standards. The best thing you can do right now is experiment.

What AI Still Can’t Replace

Through all of this, a few things became very clear. These are the parts that didn’t change:

  • Knowing when something looks off. The AI generates, but it doesn't notice when the result doesn't feel right. That eye is yours.
  • Direction and supervision. The AI used the components we gave it, but without someone supervising it, it invents solutions where there is no context to work from.
  • The definition of done is still a human call, whether it's a conversation with a PO, a stakeholder, or just the designer's criteria. There's no prompt for that.
  • The context: knowing why certain decisions matter, what a component should communicate, what the user will actually feel. Business knowledge, stakeholder dynamics, unwritten rules, empathy for the end user. These take years to build and live in the people doing the work, not in the tools they use.

My Two Cents

The tools changed, and that gave me the chills, but throughout this experience I found that the designer's role is more alive than ever.

What once took a team weeks can now be prototyped in hours. That’s not a threat; it’s an invitation to get curious.

I'm still figuring a lot of this out, and I suspect most of us are. There's no right workflow yet, and honestly, that's fine. We are in a transition where tools change faster than standards. The best thing you can do is experiment. Don't wait for a "definitive" workflow, it might be obsolete by next month.

Go ahead, try prompting your way through a component. You might be surprised how fast the system starts to take shape.

‍

AI
Technology
Sebastian Gutierrez, Backend Developer at Kaizen Softworks

Sebastian Gutierrez

·

May 15, 2026

Can AI Safely Apply Changes Across Microservices?

AI can update microservices safely, but only when it understands the system’s architecture, ownership, and service relationships.

12 read time

Read more

Applying changes across microservices is difficult because business logic is distributed across multiple services, each with its own data, contracts, and responsibilities.

In our experiment at Kaizen Softworks, we tested whether an AI system could safely apply coordinated changes across a microservices architecture using only minimal input.

Short answer: Yes, but only when the AI has enough architectural context.

Why are coordinated changes in microservices so hard?

In distributed systems, a single business change rarely affects just one service.

It often requires:

  • Updating multiple microservices
  • Modifying message contracts
  • Keeping DTOs (Data Transfer Objects) consistent
  • Respecting domain boundaries defined by Domain-Driven Design (DDD)

Key entities in this system:

  • Microservice: An independently deployable service responsible for a specific domain
  • Aggregate (DDD): A cluster of domain objects treated as a single unit
  • DTO (Data Transfer Object): A structured format used to transfer data between services
  • Message/Event: A communication mechanism between services

The complexity is not in the code, it’s in the relationships between components.

‍

The experiment: Can AI reason across services with minimal input?

We designed a controlled experiment to test whether an AI model could apply system-wide changes with limited information.

Input given to the AI:

  • Message definitions (events between services)
  • DTOs (data contracts)

Tasks the AI had to perform:

  1. Identify affected aggregates
  2. Determine service ownership
  3. Apply coordinated changes across services
  4. Maintain consistency in messages and DTOs

In other words, the AI had to behave like a software architect, not just a code generator.

What was the biggest obstacle?

The biggest challenge was not technical, it was contextual.

Before and after diagram showing how ambiguous microservice names prevent AI from understanding service ownership, while aggregate-to-service mapping helps AI apply safe coordinated changes.

Problem: unclear service naming

Instead of descriptive names like:

  • order-service
  • billing-service

Our services were named:

  • john
  • sally
  • roger

This removed any semantic clues about responsibility.

Result: The AI could not infer which service owned which domain logic.

‍

The missing piece: aggregate ownership mapping

To solve this, we introduced a simple but powerful structure:

Aggregate → Service mapping

  • Order → john
  • Shipment → sally
  • Invoice → roger

This created a clear relationship between domain concepts and system components.

Once ownership was explicit, the architecture became understandable.

How we used AI to generate architectural context

Instead of building this mapping manually, we used AI to analyze the codebase and extract:

  • Where each aggregate was defined
  • Which microservice implemented it
  • The relationship between domain and infrastructure

The result was a machine-readable architecture map.

In practice, we used AI to generate the context that AI itself needed.

Results: Can AI safely apply distributed changes?

With the architecture map in place, the AI was able to:

  • Trace message flows across services
  • Identify affected aggregates
  • Locate the correct microservices
  • Apply coordinated updates
  • Maintain consistency between DTOs and messages

While not perfect, the system worked reliably as a proof of concept.

What is the real limitation of AI in microservices?

The main limitation of AI is not code generation, it’s architectural understanding.

Without knowing:

  • Which components exist
  • How they relate
  • Who owns what

AI cannot safely modify a distributed system.

AI performance depends more on context quality than model capability.

When can AI safely modify microservices?

AI works well when:

  • Aggregate ownership is clearly defined
  • Message contracts are explicit
  • Architecture is structured and consistent

AI struggles when:

  • Naming is ambiguous
  • Relationships are implicit
  • Context is incomplete

Simple rule: If the architecture is clear, AI can reason. If not, it guesses.

Final thoughts

This experiment revealed something important:

AI doesn’t fail because it can’t write code.
It fails because it can’t see the system.

As teams move toward AI-assisted development, the focus will likely shift from:

Writing better code to Designing better systems for machines to understand

At Kaizen Softworks, we see this as a foundational shift.

Because when AI can understand architecture, it doesn’t just generate code, it helps evolve systems.

‍

© 2026 Copyright All Rights Reserved