Frontend audit · React and Vue
I trace architecture, state, shared UI, and critical flows, then give your team a clear repair plan.
Typical engagement: 1 to 2 weeks. Fixed price, agreed before the work starts.
One screen, one value. The filters a user picks are kept in three places at once, and three parts of the screen ask the server for the same list separately. Nothing here is broken, which is why it stays this way for years. No one can say where a value comes from any more.
The product works. The problem is that every change costs too much context, caution, or repeated work. These are the five places that usually explain why.
Where feature boundaries, shared code, and responsibilities stopped being obvious.
Where server state, local state, side effects, and cross-screen behavior create risk you are not choosing.
Why repeated components drift, where reuse pays, and where product rules belong in the feature instead.
Measured rendering, loading, and interaction cost in real use, not lab scores.
What can be repaired in place, what needs a staged migration, and what to leave alone.
We agree on the areas causing the most trouble, I trace the real code and the critical flows, then we go through what I found. Each finding explains what I saw, why it matters, and what I would do next.
A fixed price, agreed before any work starts. I scope it on the first call once I know which product areas are causing trouble and how much of the codebase the answer has to cover. There is no hourly meter running and no invoice that grows during the engagement.
One to two weeks, depending on how much of the codebase the answer has to cover. Shorter than that and I am guessing from file structure. Longer and the findings start describing a version of the code your team has already moved past.
Read access to the repository, someone to show me around the product, and the flows your team finds most painful. Time with whoever remembers why the difficult parts ended up that way is worth more than any document.
No. The work is reading, tracing, and measuring, not changing your code, so your team keeps shipping throughout. The time it asks for is a kickoff conversation, occasional questions, and the walkthrough at the end.
Both, when the product needs it. A frontend code audit looks at architecture, state, and component boundaries. A performance audit measures rendering, loading, and interaction in the flows that matter. Most teams need some of each, and the first call decides the balance.
Audit first when the team disagrees about what is actually wrong. Go straight to a sprint when you already agree on the diagnosis and want the fixes built.
An audit is a diagnosis, not delivery capacity. If you already know what to build and need hands to build it, an agency or a full-time hire is the better spend.
Yes. I work remotely across North American hours, from Toronto. An audit does not need anyone in a room, and every engagement I have run in the last few years has been remote.
LockeBio
I inherited unclear ownership, overloaded shared state, and duplicated UI across healthcare applications. I moved production forms, tables, and shared behavior behind clearer boundaries without hiding product rules inside a generic internal framework.
Read the architecture insightCandidateX
I joined with an incomplete frontend and unreliable product flows. I stabilized the React foundation, built a reusable component system, and organized the product into clearer apps and shared packages. The team reported faster delivery after adopting the shared UI work.
View CandidateX case studyThe scope covers frontend architecture, state, shared UI, and critical-flow performance. We agree on it before repository access.