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. I don’t much care which tool generated the code. What matters is the application underneath it: the architecture, APIs, database, dependencies, and where things are 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.

That’s completely fine — “something doesn’t work” is enough to start. Send me the URL, repository, screenshot, error, or whatever you have, and I’ll tell you what else I need. Working out what’s wrong is the first thing I do, not something you have to do before contacting me.

That’s one of the main reasons people come to me. AI is good at generating and modifying code; the problems appear where the generated pieces interact — architecture, state, APIs, databases, authentication, deployment, production environments. Those are exactly the things a model can’t see from inside one file, and exactly what I look at first.

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.

Try the AI once or twice more — sometimes that is enough. If two rounds haven’t fixed it, the model is missing context it can’t get from your description, and each further attempt adds an untested change. That is the point where a developer who reads the code, reproduces the failure and fixes the cause is cheaper than another week of prompting.

For fixing, finishing or reviewing an app that already exists, one experienced engineer is usually the better hire: they read the code before quoting, fix the cause rather than rebuilding, and you talk to them directly. An agency makes sense when you need a whole team from day one. A marketplace bid makes sense for a tiny, well-defined task — generated code with an unknown fault is not that.

For almost every startup app, Flutter: one codebase that runs on both iPhone and Android, with native code added only where a platform genuinely needs it — payments, notifications, sign-in. Fully native (Swift for iOS, Kotlin for Android) makes sense when the app is the platform: heavy graphics, AR, or deep OS integration. If your app is screens over an API — most are — Flutter gets you to both stores faster and cheaper, and it doesn’t feel like a compromise.

Not before we start, but you will need them before release, and they should be in your name, not mine — that is what keeps you in control of your app. Apple’s costs $99 a year and Google’s a one-off $25. I’ll tell you exactly when to set each up and walk you through it.

Yes. Flows and screens first, including the empty, loading and error states most designs skip, then the build by the same person — so nothing gets lost in hand-off. If you already have designs, or a Figma Make or Base44 prototype, I work from those instead.

System design is deciding how an app is put together before it is coded: how the data is organised, which parts exist, how they connect and where they run. You need it when the product has real complexity — several user types, payments, integrations, or plans to grow — because those decisions are cheap on paper and very expensive to change later. A simple app doesn’t need a separate design phase; I’ll say so if that’s your case.

If it is for you or a small team, and the answers don’t need your private data or to take actions in your systems, ChatGPT or a custom GPT is usually enough — start there. You need a custom app when customers will use it, when it must answer from your own documents or database, when it must do things (book, update, send), or when you need accounts, permissions, limits and your own branding. Many custom apps begin as a ChatGPT prototype, and that prototype is a useful brief.

It ranges from a single feature to a full product, so I quote a fixed price after a first look rather than publish a number. Two costs matter: the build, which is one-off, and the model, which is billed per use by OpenAI, Anthropic or Google every time the app calls it. A good design keeps the running cost small — caching, the right-sized model for each step, limits per user — and I estimate both before any work begins.

Usually more than one: a fast, cheap model for the simple steps and a stronger one only where it matters. Between OpenAI’s GPT models, Anthropic’s Claude and Google’s Gemini the right answer changes every few months, so the useful decision is to build the app so the model can be swapped without a rewrite. Open-source models you host yourself make sense when data cannot leave your servers.

Yes — that is most of the AI work I do. Summaries, search over your data, extraction, classification, a support assistant, an agent that handles a workflow: integrated into the product you already have, with the backend, guardrails and cost controls around it, and without a rewrite of what works.

A working prototype of the core feature against your real data usually takes days, not months — that is the point of building one first. A single AI feature integrated properly into an existing product is typically one to three weeks; a full product with retrieval, actions and evals is longer and depends mostly on how ready your data is. I’ll give you a real estimate after a first look, not before.

It depends on the work, so I don’t publish a price list. After a first look I quote a fixed price for the diagnosis, and any fix is scoped from the findings — so you know the cost before any work begins, and nothing changes partway through.

I won’t guess before looking. The diagnosis tells you what needs doing and roughly how long it should take, so the timeframe comes with the findings — before any work begins.

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.