From Hype & Vibe to Product Reality

It's a perfect degree Celsius lovely evening, and I am writing this in a room while enjoying the pleasure of a lush green sight and the coldness of the thin fresh breeze of a high forest. The first implementation was fully handwritten based on real-life experience. And yeah, AI helped clean the grammar and summarize it later, cause why not?

A year into my software engineering career, I found myself in the middle of a major B2B platform rewrite. It was a business-critical application with complex domain rules, multi-region support, multiple payment processors, payment configurations, strict access control, tight security, and multi-tenancy, all under a team working with heavy delivery pressure.

I am writing this as a point of reflection for my future self, and to share what I learned about architecture, tradeoffs, leadership, AI-assisted delivery, and engineering quality while still being early in my career. Product and organization details are intentionally anonymized.

For context, this was a complex B2B platform built to serve business owners and employees managing fast daily operations: catalog items, orders, service areas, payment devices, receipts, financial systems with banks and payouts, real-time business intelligence charts, taxes, invoicing, legal documents, and AI integration on the horizon.

Some aspects:

The original application was built during the early days of the organization. Bootstrapped with create-react-app and powered by Redux for both client and server state management, with React Router, MUI, and Jest, it reflected the common React stack choices of that era. It had also evolved through version upgrades over time, including React Router updates and a later CRA-to-Vite migration.

As the first implementation, it served a simpler set of business requirements: single-region support and a single payment-provider scope. It helped the company move fast, prototype quickly, and support a growing client base.

Over time, as the organization scaled, the application had to support the multi-region, multi-provider platform described above. But it had to do that on top of a foundation that was never designed for that level of complexity. Legacy MUI with runtime CSS generation spoke for its time, and the Redux-heavy patterns did not age well compared with newer frontend tooling. The application eventually suffered from large bundle sizes, performance bottlenecks, and years of compounded technical debt from rapid delivery cycles.

By 2025, it was time to invest in a healthy revamp.

During this period, more frontend applications in the organization were moving toward Next.js. For this B2B platform, the adoption of Next.js was driven more by organizational momentum and framework hype than by a strict alignment with product requirements. Next.js had become the default standard, so it became the framework of choice for the revamp without enough visible requirement analysis, implication review, or tradeoff discussion.

The squad leading the initial revamp handed the project over to my squad of four developers. At that stage, the application was around 85% dev-complete for a scope covering one major payment provider, roughly 30% of the entire platform scope. Our task was to finish the remaining 15% and deploy the new platform to production alongside the legacy application.

Onboarding onto the project surfaced immediate DX friction. I had to get a POSIX dev environment running by installing Ubuntu 20 LTS on WSL2 because I could not get the project working properly on Windows. I kept hitting a Next.js cookie error, later debugged to a node sub-dependency of a package that broke due to Windows file naming conventions. The trigger was painfully small: my project folder path contained whitespace in the name of a parent folder. WSL2 did not solve the problem either, because the project somehow triggered sustained 600 MB/s+ file reading operations on my NVMe drive with no end. That was the first frustration before I even saw the application up and running.

Every developer dealt with their own set of problems, not just development-wise but also UX-wise. I believe poor DX often directly transfers into poor UX, and we experienced a lot of that.

The core issue was not simply "Next.js is bad." That would be too easy, and not true. The issue was the default-driven choice.

Despite the ability to build a CSR or hybrid application with Next.js, the project defaulted to a server-heavy model. The framework's conventions became louder than the product's actual needs. This was a fully authenticated B2B operations platform consuming existing REST APIs through a BFF. There was no meaningful SEO surface. The product needed fast client-side interactions, predictable auth handling, direct API visibility, and stable tenant context.

The misalignment got worse when weak architectural decisions were accelerated by AI-heavy implementation. AI tools were very effective at scaffolding Next.js, shadcn, and Tailwind components quickly. But without strong human guidance, the focus shifted from "implement what is correct" to "build what works." AI solutions worked for the smaller context an LLM could hold, not for the larger context the application needed to survive. This was the Claude Sonnet 3.5 era, and AI tools were not as capable as the front-runners are today.

What the implementation inherited:

When the final phase reached production, the concerns stopped being theoretical.

The production reality:

Complaining was not a strategy. The delivery had been rushed, the planning had not been deep enough, and the result was an over-engineered product where maintainability was suffering. I still do not think that was purely an individual-dev failure. It was a planning, architecture, and incentive failure too.

With the team, seniors, product owners, and leads all recognizing the friction, I advocated strongly for an architectural reset. My message was roughly this: if we wanted the future development flow to be straightforward and wanted to eliminate the performance, debugging, and production-confidence issues we were seeing, we had two serious options. Either we had to change the Next.js architecture heavily enough to remove the server-heavy assumptions, or we had to rebuild the frontend boundary cleanly with plain React again.

That opened the door. Leadership gave the green light to assemble the senior engineering group and define a path forward.

The resulting deep-dive sessions allowed us to evaluate the application against the company's tech standards and the product's real needs. The decision, backed by senior engineers and approved by the leads, was to rebuild the frontend boundary cleanly.

I had strong opinions and a lot of influence on that direction, but the final choices stayed with the leads. Senior engineers backed the reasoning, lead engineers kept oversight.

I was assigned to handle:

The first responsible question was not "React or Next.js?" It was: can we keep the existing Next.js codebase and remove only the parts that are hurting us?

Technically, yes. Next.js can support client-heavy and hybrid approaches. But that was not the debate. The question was whether that path would solve our product problem with less risk than rebuilding the frontend boundary cleanly.

The answer was no.

Moving pages toward client-side rendering would have removed some SSR waiting time, but it would not have removed the shape of the codebase we inherited. The application was already deeply coupled to App Router conventions, server components, route handlers, middleware, cookies, server-side auth assumptions, framework-specific loading behavior, and AI-generated code built around those assumptions.

Converting the project would have been a rewrite disguised as a refactor. We would keep the framework around which most of the wrong assumptions had already been built, spend weeks stripping features away, and still carry the mental model that had already failed the product.

Starting fresh with Vite and React was not about chasing a new trend. It was about making the application honest again: a client application consuming APIs, with one clear runtime model.

Rewrites are dangerous. They can destroy hidden business behavior, delay delivery, and create a second system that looks cleaner but understands less. So the decision had to be weighed against real options:

Because the API boundary was stable, the domain was understood, and the scope could be copied feature-by-feature instead of rediscovered from zero, a clean rebuild was estimated at 3-4 months. The case was not "new code is better." The case was that a controlled rebuild was cheaper than years of compounding patchwork on a misaligned architecture.

The stack had to survive team review, senior oversight, lead approval, and the product reality.

A clean stack does not prevent a messy codebase. Without strict boundaries, even Vite and React can degrade into another chaotic folder tree. My first job was to turn the rewrite from a concept into an engineering system.

As a code owner, my development-to-review ratio shifted heavily. The squad still used AI for acceleration, so I was reviewing four to five PRs daily, often spanning 1,500-2,500 lines of code.

AI is fast, but it does not understand system ownership by itself. I spent 2-6 hours a day catching prop drilling, derived state anti-patterns, loose typing, naming drift, duplicated logic, and business logic bleeding into UI components. Leaving 20-30 comments on a PR was not about ego. It was about protecting the baseline.

Every accepted hack today becomes tomorrow's standard.

These are internal before/after observations from our application and development workflow, not a public benchmark and not a framework shootout. The exact numbers should be read with the environment, data size, branch, internal build/test setup, network conditions, and traffic profile in mind.

The previous structure made the framework louder than the product. One feature could live across routes, actions, data folders, API routes, nested components, stores, hooks, and shared utilities. Before understanding the business flow, a developer first had to understand where the implementation had scattered the pieces.

Why it mattered:

The old implementation placed too many decisions in middleware. Auth, redirects, tenant context, and feature access all depended on one sensitive request-time decision point.

This is not actual production code. It represents the shape of the problem.

The new model moved route-level access checks closer to the feature that needed them.

Access logic moved closer to the feature. One route could change without shaking the whole application request path.

Feature availability used to appear in pages, route logic, navigation, and validation. That looks manageable in one place, then quietly duplicates in another, then becomes fragile without looking obviously broken.

The new direction was a centralized, typed feature-scope model.

Why it mattered:

This is one of the places where human architecture mattered more than generated code. AI could produce the component. It did not produce this system-level thinking by itself.

The old request path added a frontend server hop before reaching the existing BFF.

The new request path was more direct.

Why it mattered:

The old state management model had too many possible owners. Depending on the feature, state could start in a server component, move through a server action or route handler, get reflected through cookies, hydrate on the client, and then be handled again by hooks or a local store.

The new model separated server state from client UI state.

Why it mattered:

Again, dead simple. That was exactly the value.

The AI era changed developer mentality very fast. Somewhere along the way, "make it correct" started turning into "make it work." Around the environment I was in, speed became so loud that people started acting like technical debt had magically disappeared.

That was one line I did not want the team to cross. So I pushed one principle again and again:

AI usage had to be directed toward specific, high-value work:

What I did not support was prompt-engineering entire features and accepting the output as it is, because it looked complete. We moved toward a simple cycle: Plan, Implement, Review. AI could accelerate the work, but it could not replace ownership. The developer still had to understand the decision, the code, the tradeoff, and the failure modes.

No architecture decision came for free. The rewrite was the right decision, but it still had tradeoffs that had to be accepted consciously.

At one point, the manager himself said something close to:

And I did enjoy that. Pure developer dopamine. Not because it was praise for the sake of praise, but because it meant the product felt better. The rewrite was not just technically cleaner on paper. Someone using and judging the product could feel the difference.

I do not care to be the loudest "100x engineer" in the room. I want to be the engineer who deeply understands the product, weighs the tradeoffs, solves the problem, and delivers a system with care that the team can actually work in.

This journey from a legacy React app, through a framework misalignment, and finally to a modern React + Vite + TanStack architecture became a masterclass in product-first engineering. Identifying the need for a reset, pitching the architecture, bootstrapping the foundation, and protecting the quality standard as an engineer relatively early in my career became a massive milestone.

It reinforced a core truth: choosing the right technology is not about picking the most popular framework. It is about understanding the product deeply enough to know what the product does not need.

Written in March 2026.