Service
A repository, partial documentation, and nobody who understands it. I read the existing architecture first, tell you honestly what is salvageable, then finish it.
Most of the work clients hire me for is the same job: an application that already exists and is not working. A dashboard rendering blank in production. A marketplace carrying fixes nobody has picked up. A codebase whose author stopped replying.
I start by reading what is actually there rather than proposing a rewrite, because a rewrite is the most expensive way to solve a problem you have not diagnosed yet. You get an honest assessment of what is salvageable and what is not, and then the work to get the product back to a reliable state.
The instinct when inheriting a messy codebase is to start again. It is almost always wrong, and it is wrong for a reason that is easy to miss: the existing code, however ugly, encodes hundreds of decisions and edge cases that nobody wrote down. A rewrite throws away that knowledge and rediscovers it one production incident at a time.
What actually fixes a struggling codebase is finding the small number of real structural problems underneath the large number of cosmetic ones. A blank dashboard in production is rarely a rendering problem — it is usually a data assumption that holds in development and fails against real data, and the fix is one guard in the right place rather than a new frontend.
I will tell you when a rewrite genuinely is the answer. Sometimes it is: a codebase built on a framework version that no longer receives security patches, or one where the data model is wrong in a way that every feature has to work around. But that is a conclusion you reach after reading the code, not a proposal you lead with.
The recurring ones: state that works locally and breaks against production data volume, API calls with no error path so a single failure blanks the screen, authentication that leaks between users because tenancy was added after the fact, and bundle sizes that grew until first load became the product’s worst feature.
I also find things nobody asked me to look for. On one contract I found and patched a cross-site scripting vulnerability that was not in the brief — the client had not considered it. Flagging what I notice outside the scope is part of the job rather than an upsell.
VisaConnect came to me as an existing codebase and was rebuilt end to end — a community platform with a marketplace and real-time interactions. TranquiLove was a rebuild, redesign, and security pass on a live product rather than a fresh start.
NuVisa and Wavel were both existing codebases I joined to fix and extend: a UK immigration platform built on multi-step form workflows, and an AI tools directory indexing 10,000+ entries, where the problems were search and scale rather than screens.
Takeover work starts with a paid audit, usually a few days. I read the repository, run it, and come back with a written assessment: what is broken, what will break next, what it costs to fix, and what I would leave alone. You can act on that with or without me — it is your document either way.
If we continue, you get commits that explain themselves and documentation written as I work, specifically so that you are never again dependent on one person’s memory.
Yes — this is the majority of my contract history. You typically have a repository, partial documentation, and nobody who understands it. I read the existing architecture first, tell you honestly what is salvageable and what is not, then finish it. I work on React, Next.js, Node.js and MEAN stack codebases.
Almost certainly not. A rewrite discards all the undocumented edge cases the existing code encodes, and rediscovers them one production incident at a time. I look for the small number of real structural problems underneath the large number of cosmetic ones. When a rewrite genuinely is the right call — an unsupported framework version, or a data model every feature works around — I will say so, but only after reading the code.
That is exactly why it starts with a paid audit rather than a quote. A few days of reading the repository produces a written assessment: what is broken, what will break next, what it costs to fix, and what I would leave alone. You get a real estimate from that, and the document is yours whether or not you continue with me.
Often, yes. Bugs that resist reproduction are usually environmental — they depend on production data shape, timing, or volume that development never sees. I trace to the source rather than patching the symptom, which matters because the same root cause is usually producing two or three other bugs you have not connected to it yet.
Yes, by default. On one contract I found and patched a cross-site scripting vulnerability the client had not asked me to look at and had not considered. If I notice a security or scalability problem outside the brief, you hear about it — whether or not you hire me to fix it.
A community platform for visa workers in the US — connect with peers, get help, and access a built-in marketplace.
Read the case study →A UK visa & immigration services platform — guided application flows and multi-step forms that turn a confusing process into a clear path.
Read the case study →An AI tools and agent marketplace — a searchable directory of 10,000+ tools with categories, rankings, and a live leaderboard. Built for scale and discovery.
Read the case study →A 15-minute call is usually enough to scope it. If I am not the right fit, I will tell you on the call.