Case studies

Kero Ótica

Software architecture

Demonstrate the ability to lead frontend modernization on a critical production ERP, with emphasis on architectural decision-making, complexity management, and technical communication.

Official site →

Executive summary

Frontend modernization of an optical ERP in production for approximately five years, used by approximately 500 companies.

The system is critical to daily operations, multi-tenant, and covers financial, fiscal, POS, inventory, dashboard, and banking integration modules.

Role: lead research, compare alternatives, define the new frontend architecture, produce technical documentation (RFCs and guidelines), and drive the modernization strategy.

Central decision: adopt React + Next.js as the new frontend foundation and migrate gradually instead of rewriting everything, prioritizing governance, observability, and longevity.

Current state: modernization is still in progress. Intermediate observable results are not yet publicly documented.

Context

ERP specialized for the optical market, in production for approximately five years.

Used by approximately 500 companies and critical to daily optical store operations.

Multi-tenant environment with concurrent users.

Known functional scope: financial, fiscal, POS, inventory, dashboard, and banking integration modules.

Frontend modernization is still in progress.

Problem

The legacy frontend was built with Vue 2, Nuxt 2, and Vuetify 2.

The codebase had high coupling, monolithic components, and weak separation of responsibilities.

Those characteristics made product evolution harder as the domain grew.

There was no explicit complexity management in a system that keeps expanding modules and integrations.

Consequence of inaction: change cost would tend to rise, evolution of critical modules would slow down, and operational risk tied to frontend changes would grow in an already-production system.

Responsibilities

Define the architecture of the new frontend.
Research alternatives and compare frameworks.
Produce technical documentation.
Write RFCs and guidelines.
Support the team's technical decisions.
Lead the modernization strategy.

Restrictions

Operational continuity: the system is in production and critical to daily operations — broad interruption is unacceptable.

Legacy: the Vue 2 / Nuxt 2 / Vuetify 2 base must coexist with evolution until migration progresses.

Multi-tenancy and concurrency: changes must respect concurrent users and isolation between companies.

Sensitive modules: financial, fiscal, POS, inventory, and banking integrations raise the cost of mistakes.

Continuous evolution: the product keeps growing; modernization cannot depend on freezing the business.

Alternatives considered

Alternative 1 — full frontend rewrite: replace the legacy base at once.

Alternative 2 — gradual migration: prepare architecture for incremental evolution and migrate in stages while keeping production running.

Alternative 3 — framework comparison for the new frontend base: performed as part of the technical responsibility.

Full rewrite was discarded in favor of gradual migration because it conflicted with the operational continuity constraint.

Decision made

Choose React + Next.js as the foundation of the new frontend.

Adopt gradual migration instead of a full rewrite.

Prioritize governance, observability, longevity, and incremental evolution while driving modernization.

Engineering Decision

Modernization strategy: gradual migration

Problem

The legacy frontend hindered ERP evolution, but the system is critical in production and cannot be broadly interrupted.

Alternatives

Full frontend rewrite.

Gradual migration with incremental evolution.

Choice

Adopt gradual migration, preparing the architecture for incremental evolution.

Justification

The operational continuity constraint in a multi-tenant environment with sensitive modules makes a full rewrite incompatible with acceptable risk.

Modernization must coexist with continuous product growth.

Trade-offs

Gain: operational continuity and lower risk of broad interruption.

Loss/deferral: immediate elimination of the legacy.

Accepted risk: prolonged coexistence between old and new bases.

Consequences

Architecture and execution become oriented toward incremental stages.

Governance and documentation become necessary to keep coherence throughout migration.

Engineering Decision

New frontend foundation: React + Next.js

Problem

A technological foundation for the new frontend had to be defined to replace, in a planned way, the Vue 2 / Nuxt 2 / Vuetify 2 stack.

Alternatives

Framework comparison was conducted as part of the technical responsibility.

Choice

Adopt React + Next.js as the foundation of the new frontend.

Justification

The choice resulted from research and comparison of alternatives, documented through RFCs and guidelines.

Consequences

The new frontend adopts React + Next.js as its technological foundation.

Gradual migration must coordinate introducing that foundation while coexisting with the legacy.

Architecture

The target architecture was defined to support incremental evolution, enabling frontend modernization without requiring a full production stop.

Choosing React + Next.js establishes the technological foundation of the new frontend; gradual migration defines how that foundation coexists with the Vue 2 / Nuxt 2 / Vuetify 2 legacy over time.

The architectural reasoning prioritizes boundaries that reduce coupling and allow complexity management as modules and integrations keep growing.

Trade-offs

Primary trade-off: speed of replacing the legacy versus operational continuity.

What was gained with gradual migration: preservation of daily operations and reduced risk of broad interruption in a critical system.

What was lost or deferred: immediate elimination of the legacy; modernization happens over time.

Accepted risk: prolonged coexistence between old and new bases while migration advances.

Execution

Lead technical research and comparison of alternatives.

Produce technical documentation, RFCs, and guidelines to align decisions.

Define and communicate a modernization strategy oriented to incremental evolution.

Continuously support the team's technical decisions during execution.

Main challenges

High coupling in the legacy frontend.

Monolithic components.

Weak separation of responsibilities.

Difficulty evolving the product safely.

Previous lack of explicit complexity management.

Need to modernize without interrupting a critical production ERP.

Result

Current state: modernization is still in progress and must not be treated as complete.

Impact

The modernized system has potential operational impact on an ERP used by approximately 500 companies.

Limitations

Internal architecture, module, and operation details can only be published at a generalized level due to confidentiality.

Final results cannot be presented as complete while modernization is still in progress.

Part of the framework alternatives and quantitative success criteria are not yet publicly documented.

Engineering principles extracted from the case

In critical production systems, modernization strategy must be conditioned by operational continuity — evidenced by choosing gradual migration over rewrite.

Governance, observability, and longevity can be explicit architecture criteria, not only desirable attributes after the fact.

Technical documentation (RFCs and guidelines) is part of driving the decision, not an appendix to implementation.

Stakeholders

Users from optical-market companies, impacted by the ERP's daily operation.

Technical team responsible for the ERP, with whom modernization decisions must be aligned.

Areas involved in evolving financial, fiscal, POS, inventory, dashboard, and banking integration modules.

Related cases

Pupilens

Mobile performance

Mobile application for optical lens demonstration during sales in optical stores.

Mobile performanceComplex visual manipulation

See details →Official site

Executive summary

Frontend modernization of an optical ERP in production for approximately five years, used by approximately 500 companies.

The system is critical to daily operations, multi-tenant, and covers financial, fiscal, POS, inventory, dashboard, and banking integration modules.

Role: lead research, compare alternatives, define the new frontend architecture, produce technical documentation (RFCs and guidelines), and drive the modernization strategy.

Central decision: adopt React + Next.js as the new frontend foundation and migrate gradually instead of rewriting everything, prioritizing governance, observability, and longevity.

Current state: modernization is still in progress. Intermediate observable results are not yet publicly documented.

Context

ERP specialized for the optical market, in production for approximately five years.

Used by approximately 500 companies and critical to daily optical store operations.

Multi-tenant environment with concurrent users.

Known functional scope: financial, fiscal, POS, inventory, dashboard, and banking integration modules.

Frontend modernization is still in progress.

Problem

The legacy frontend was built with Vue 2, Nuxt 2, and Vuetify 2.

The codebase had high coupling, monolithic components, and weak separation of responsibilities.

Those characteristics made product evolution harder as the domain grew.

There was no explicit complexity management in a system that keeps expanding modules and integrations.

Consequence of inaction: change cost would tend to rise, evolution of critical modules would slow down, and operational risk tied to frontend changes would grow in an already-production system.

Restrictions

Operational continuity: the system is in production and critical to daily operations — broad interruption is unacceptable.

Legacy: the Vue 2 / Nuxt 2 / Vuetify 2 base must coexist with evolution until migration progresses.

Multi-tenancy and concurrency: changes must respect concurrent users and isolation between companies.

Sensitive modules: financial, fiscal, POS, inventory, and banking integrations raise the cost of mistakes.

Continuous evolution: the product keeps growing; modernization cannot depend on freezing the business.

Alternatives considered

Alternative 1 — full frontend rewrite: replace the legacy base at once.

Alternative 2 — gradual migration: prepare architecture for incremental evolution and migrate in stages while keeping production running.

Alternative 3 — framework comparison for the new frontend base: performed as part of the technical responsibility.

Full rewrite was discarded in favor of gradual migration because it conflicted with the operational continuity constraint.

Architecture

The target architecture was defined to support incremental evolution, enabling frontend modernization without requiring a full production stop.

Choosing React + Next.js establishes the technological foundation of the new frontend; gradual migration defines how that foundation coexists with the Vue 2 / Nuxt 2 / Vuetify 2 legacy over time.

The architectural reasoning prioritizes boundaries that reduce coupling and allow complexity management as modules and integrations keep growing.

Trade-offs

Primary trade-off: speed of replacing the legacy versus operational continuity.

What was gained with gradual migration: preservation of daily operations and reduced risk of broad interruption in a critical system.

What was lost or deferred: immediate elimination of the legacy; modernization happens over time.

Accepted risk: prolonged coexistence between old and new bases while migration advances.

Limitations

Internal architecture, module, and operation details can only be published at a generalized level due to confidentiality.

Final results cannot be presented as complete while modernization is still in progress.

Part of the framework alternatives and quantitative success criteria are not yet publicly documented.

Engineering principles extracted from the case

In critical production systems, modernization strategy must be conditioned by operational continuity — evidenced by choosing gradual migration over rewrite.

Governance, observability, and longevity can be explicit architecture criteria, not only desirable attributes after the fact.

Technical documentation (RFCs and guidelines) is part of driving the decision, not an appendix to implementation.