Show me what’s stuck.

Yes, and it’s a large part of what I do. Generated code tends to be locally sensible but globally inconsistent, which is exactly the kind of problem that’s hard to prompt your way out of. I read it the same way I’d read any unfamiliar codebase.

Yes — all of them, plus Claude, Copilot and ChatGPT output. The tool that produced the code doesn’t change how I approach it. What matters is what the application does, how it’s structured, and where it’s breaking. Lovable and Bolt projects tend to need deployment and backend work; Cursor and Copilot projects more often need the seams between generated pieces checked.

Yes. I start by understanding the system before changing anything — dependencies, data model, auth, deployment, and the parts that are load-bearing. Then I’ll tell you what I found before I start editing.

Usually not. Rewriting is the most expensive option and it’s rarely the one the code actually calls for. I’d rather find the specific things that are broken and fix those.

Yes, and it’s a good moment to ask. A pre-launch review covers architecture, security, performance, dependencies and maintainability, and comes back as a prioritized list rather than a wall of comments.

Yes. If something is broken for real users right now, say so when you get in touch and I’ll treat it accordingly. I’ll want access to logs and the deployment, not just the code.

Yes — Flutter is one of the stacks I’ve worked in longest, across both apps and the backends behind them. That includes state management, platform channels, builds and store releases.

Yes. Node is one of my primary backend stacks, including APIs, background jobs, integrations and the deployment around them.

Yes. FastAPI is my usual choice for Python services, particularly anything with an AI or data component. I’m comfortable across the surrounding ecosystem too — async workers, migrations and typed request models.

Yes, and it’s one of the most common reasons people get in touch. "It works locally" is almost always an environment, configuration or build problem rather than a code problem, and those are findable.

Yes, as an engineering review rather than a formal audit or certification. I look at authentication, authorization, exposed secrets, input handling, dependency risk and what your deployment leaves open. If you need a certified penetration test, I’ll tell you that instead of pretending otherwise.

Yes — I work remotely by default and have done for years. Timezone overlap is usually a scheduling question rather than a blocker.

You send me what you have and describe what’s going wrong. I go through the application and the code, then come back with what I found, what I’d fix first, and what I’d leave alone. You get that in plain language, not a report you need a developer to interpret.

Yes — mobile, web and AI-powered products. It's a different engagement from a rescue: we start with what the thing actually needs to do, and I'll usually push to get a small version in front of real users before building the rest. If your idea is better served by something simpler than what you're picturing, I'll say so.

Less than you’d think. A repository or a deployed URL, some idea of what’s broken, and access to whatever is failing — logs, the hosting dashboard, an error message. If you don’t have all of that, send what you do have and I’ll tell you what else I need.