You are most of the way there
You got most of the way with AI. I can help you finish.
The tool got you further than most people expect, and then stopped short. That last stretch is almost always the same short list: it will not publish, it breaks on phones, the form goes nowhere, the login is wrong, it crawls, or Google cannot read it. Send me the link and I will tell you exactly what is standing between you and going live.
Looking at it costs nothing and does not commit you to anything. If I think it is not worth repairing, I will say so before you spend anything.
Nothing went wrong here, and you did not make a mistake. Building with AI is genuinely fast and genuinely useful, and I use it every day myself. What it does not hand you is the part nobody sees: what happens when a real person, on a real phone, does something nobody planned for.
That is where these projects stall. Not on the design, which usually looks perfectly good, but on the plumbing behind it. The reassuring thing about plumbing is that it is a bounded problem. It moves quickly when you have seen the pattern before, and drags on for weeks when you have not.
I take these on when there is enough there to save and the job has a finish line I can draw.
And if I open it up and everything is wired into everything else, or the files and access are gone, I will not promise you a rescue. I will tell you honestly that repairing it is not worth it, or which part I would rebuild, or that someone else would be a better fit. It is a better answer to get early than late.
What I fix
The six things that stop these sites launching
Yours almost certainly will not have all six. We work out which ones are actually blocking you, and agree that list before anything starts.
You hit publish and nothing happened
The site works in the builder but not on the real address. Usually the domain is not pointing where it should, or the site only ever existed in a preview. Once we know which of those it is, it is normally a small fix.
It looks right on a laptop and falls apart on a phone
Text running off the edge, buttons too small to tap, a menu that refuses to open. Most of your visitors arrive on a phone, so this is not a cosmetic problem. It is the whole shop window.
Forms submit into nowhere
Someone fills in your contact form, hits send, and it goes nowhere. You never find out, and neither do they. This one is worth checking early, because unlike the others there is nothing on screen to tell you it is happening.
Logins are wrong, or people see things they should not
Accounts that will not let the right person in, or that let the wrong person see the owner's screens. I sort out who can reach what, which is worth doing before a customer finds it first.
It is slow, or fixing one thing breaks another
That usually means things are tangled together underneath. I look for what is actually causing it, keep the parts that work, and rebuild only the parts that keep causing trouble, so the next change is less of a gamble.
Google cannot read it, or has not found it yet
Page titles, descriptions, the actual content, and what appears when someone shares a link. If search engines cannot make sense of your site, you are effectively invisible no matter how good it looks.
Honest scope
Check whether your project is a fit before you write
This works when
- There is something real to look atA link, the project files, or a login to whatever is broken. I do not guess from a description, I look at the actual thing.
- You know what it is supposed to doYou can say what a visitor or your team should be able to do on it, and where it currently stops working.
- You are open to rebuilding a part of itMost of it stays. But when propping up one section costs more than replacing it, I will say so and you get to decide.
This is not the right service when
- You need someone watching it around the clock and fixing things immediately.
- There are no source files, no admin access, and nobody can hand anything over.
- It is a large system where every part touches every other part and no piece can be separated out yet.
Not sure which side you are on? Send it anyway. Being told not to repair something is a useful answer, and it costs you nothing to get it.
How it works
Inspect first, agree the list, then fix it
- 01
Send me the real thing
The link, the tool you built it with, and what is going wrong. Do not tidy it up first.
- 02
I look, and tell you what I find
What can be kept, what needs rebuilding, and whether repairing it is the shorter road. An honest answer, including no.
- 03
We write down the job
The exact list of fixes, what is not included, and what finished means. Agreed before I start.
- 04
Fixed, tested, delivered
I do the list, test what matters, and hand it over. Anything new after that is a new conversation.
Worth knowing up front
Two things about how we handle the files
Neither of these is unusual, and both exist for the same reason: to make sure the version you end up with is the one we both think it is.
While I am working, your copy is the one we build on
When we agree the job, I take the latest version you hand over, and from that point it becomes the single working copy. If you, your tool, or another developer carries on editing your own copy in parallel, I will not be able to fold those edits into mine. Merging the two and resolving the conflicts would be yours to arrange, and it is genuinely fiddly work.
So it is far simpler to pause your own edits while I have the job, or to tell me what you want changed and let me make the change in the version I am already working in.
After I hand it back, changes you make are your own
Once the finished work is delivered the site is yours to edit, and I would encourage that. But if a change made after handover breaks something, putting it right is separate work and is charged as new work.
The honest reason is that I cannot safely touch it until I know what changed and how far the effects reach. That investigation is most of the job, and it is the part that stops a small fix quietly turning into a bigger problem. It is not a penalty. It is simply what careful work costs.
If you are ever unsure whether something counts, just ask me before you change it. That conversation is free and it takes a minute.
Common questions
What people ask before sending it over
What kind of AI built sites do you take on?
Business sites, service and landing pages, and small systems with a clear purpose. The best fit is a site that is nearly there but stuck on publishing, phone layouts, forms, logins, speed, or search. I look at the real thing before agreeing to anything, then tell you exactly which parts I would fix.
What would you turn down?
Work where there are no source files and no access, because I cannot fix what I cannot open. Anything that needs someone on call around the clock, because I take these one job at a time rather than as a support contract. And large systems so tangled together that we cannot yet draw a line around one piece. If I do not think repairing it is worth your money, I will tell you that before you spend any.
Do I have to scrap it and start over?
Usually not, and I cannot tell you either way until I have seen it. Plenty of these keep their look and their content and only need the parts blocking launch fixed. Some need a section rebuilt because propping it up costs more than replacing it. I lay out the options with the reasoning and you decide, not me.
Is this a monthly retainer?
No, I take these one job at a time. Before I start we agree what gets fixed, what gets delivered, and what counts as finished. When that is done, it is done. If something new comes up later we look at it as a new job. I would rather be clear about that up front than have you expecting cover I am not actually providing.
What should I send you?
The link, the tool you built it with, and a sentence about what is going wrong. If you have the files or an admin login, mention it. Do not tidy anything up first. I want to see the actual state of it, because the mess is the information I need to give you a real answer.
Can I keep editing my site while a developer is working on it?
Better not to, and this applies to most developers rather than just me. When I start a job I take the latest version you hand over, and that becomes the single working copy. If you keep editing your own copy at the same time, the two drift apart, and merging them and resolving the conflicts falls to you. Far simpler to pause your edits for the duration, or tell me what you want changed so I can make it in the version I already have.
What happens if I change something after you hand the work back?
The site is yours, so you are free to change it. But once I have handed it back, changes you make yourself are outside what I am responsible for. If one of them breaks something and you would like me to fix it, that is separate work and is charged as new work, because I first have to investigate what changed and how far the effects reach before I can safely touch anything. If you are unsure whether a change is risky, ask me before you make it. That conversation costs nothing.
I feel stupid asking. Is this a normal thing to need help with?
It is extremely normal, and no, you did nothing wrong. These tools genuinely get you most of the way, and then the last stretch turns out to need someone who has shipped things before. I use AI every day myself. Getting stuck at this exact point is the rule, not the exception.
Something else on your mind? See the full list of questions or just ask me directly.
Send it over
Send me the link and I will take a look
Tell me what you built it with, what is going wrong, and what you want people to be able to do on it. I will look at the real thing first, and we can talk about scope after that.