Stuck After Building It Yourself with AI — Can a Vendor Take Over the Code?

In the requests we receive, the screens are already built and the work that attaches behind them is where the build stopped. The report lands in one of four forms.

The screens are all finished, but there is no way to put it online. There is no address to send anyone, and it only runs while the laptop is on.

It worked yesterday and does not work today. One change was requested, a different screen broke, and there is no route back to the version that worked.

Login stalled halfway. Sign-up works. Password reset and staying signed in do not, and one user's records show up on another user's screen.

Payments stalled halfway. Test transactions go through, and the merchant review, cancellations, and refunds are a blank.

There are others, and more than one of them can be true at once.

The stuck points have one thing in common. The work of building screens is finished, and the work that attaches behind those screens has started — putting it on a server and keeping it there, deciding who is allowed to see whose data, deciding what appears when something fails. Writing a more detailed prompt does not get past this. Switching tools stops at the same place.

Send the build across as it stands. The receiving side reads it for the decisions already made — how many screens exist and what each one is called, which fields were chosen for storage, what order the steps run in, which cases were given an exception in the wording on screen. Naming that drifts between screens, and the same logic written twice in two places, get tidied during the work that follows, and neither one moves the assessment.

Postponing the decision costs more later. Holding a stuck build for several more weeks means several more weeks of AI-directed edits layered on top of each other, until the person who built it can no longer say where the original design ended. Sorting it out at the point where it first felt stuck is the cheaper moment.

Writing down what only you know, before you contact a vendor, narrows the chance of a "let us just rebuild it" answer arriving before anyone has opened the project.

Start with the list of screens that work. Split it three ways — fully working, half working, started and abandoned — and use the screen names as they appear in the build. The half-working list carries the most weight in the assessment, because how far each one got and where it stopped is all in that line.

Write down where the code lives. In a repository such as GitHub, in a folder on your own machine, or inside a no-code tool with no export. If there are several folders, add one line saying which is current. Without that line the first meeting starts with a search for the latest version. Names like backup, revised, and final mixed together stop being legible to the person who made them within a few days.

The external services and accounts in use belong on the list too. Database, login, email delivery, payments, AI APIs — every service you signed up for, and whether each account is in your own name. An account in someone else's name blocks the transfer step later. Do not send keys or passwords at this stage; the service names alone are enough to make the assessment.

Last is where the data accumulates. Inside the browser only, in an external database, in a Google Sheet. And whether the data collected so far has to be kept or can be discarded. Keeping it adds a migration task; discarding it removes one. That single line changes the quote.

Copy the block below and fill it in.

The code arrives disorganized. Building by directing an AI scatters the same logic across several places and mixes naming conventions along the way. The assessment turns on which of two jobs the thing was built to do — run once, for one person, or run every day, for several. That boundary decides what carries over and what gets written again.

Requirements carry over the most. Decisions made while building by hand include things that do not survive into a written specification — the exact wording on a screen, the term the business uses for a status, what was decided for a case nobody thought to ask about.

Deployment and permissions are where the rebuilt column gets expensive. Adding one more permission tier multiplies the screen-and-role combinations that have to be checked, and every combination is a case someone opens and confirms by hand. Error handling gets written again too. Code that only runs the successful path passes a demo. What to show and what to roll back when a payment window is closed mid-transaction, an upload is cut off, or an external API returns nothing is a set of decisions that has to be made one case at a time.

Validation, logs, and backups sit at the bottom of the rebuilt column and get cut first, since the screens run without them. They are where the evidence comes from when something goes wrong and someone has to establish what broke and when.

To run the assessment yourself, take one screen and ask what happens when it fails. If the answer is "I don't know" or "it just stops," that screen belongs in the rebuilt column.

The default for changing an existing system is incremental improvement. A full rebuild costs about what new development costs and adds the risk that comes with the cutover, so the sequential path — fix the parts causing problems first — gets examined first.

An AI-built result gets the same order of approach. There are signals, though, that the continuation path has stopped being the cheaper one. If any of these are true, asking for a takeover quote and a rebuild quote side by side gives you something to compare.

The same code is copied across screens, and fixing one place has already broken another more than once. The time spent locating the right place to change keeps compounding.

Data is stored to match screens. A separate table per screen, with the same information duplicated across several of them, means the cleanup is a redesign.

It only runs inside a no-code tool and the code cannot be exported. There is no code to move. What carries over is the screen structure and the accumulated data; the code gets written from scratch.

It does not start at all as delivered. Tangled package versions that stop it from launching put the work of getting back to a running state into the analysis effort before anything else.

The direction changed during the build. Here the question of what to build has to be settled before anyone opens the code. Deciding what to keep by looking at the code alone keeps screens that were already going to be dropped.

A rebuild verdict does not erase the time already spent. Someone who has built it once already knows how many screens are needed, which fields have to be stored, and where the exceptions show up. The stage of extracting requirements from scratch gets shorter, and the number of "how would you like this handled?" questions in meetings drops. You open what you built and show it.

How the cost of changing an existing system is put together is set out separately in legacy system refactoring cost.

A new-build quote comes out of the volume of what has to be made. A quote for taking over something already built carries the volume of what has to be read in front of it. The shape of the quote document changes for the same reason.

The analysis phase starts with getting the delivered code to run on someone else's machine. Nothing follows until it starts. Screens and data then get checked against each other to see how they are actually connected, and this is where the builder's description and the code turn out to disagree. Then the line gets drawn — what is kept, what is written again. The main quote figure comes after that line exists.

A main quote can arrive before any analysis. When it does, ask what the figure assumes. A number that assumes a full rebuild and a number that assumes reusing the existing code have different amounts of room to move once the code is opened. Ask for the conditions under which the figure changes, in writing, up front.

The same analysis effort is why a quote to improve an existing system can come in above a new build. Reading undocumented code is a line item that a new-build quote does not contain, and an AI-built result does not change that structure.

What to secure from the client side is an agreement that the analysis results arrive as a document. A rebuild verdict still leaves that document behind, and it goes straight to the next vendor you ask. A screen list, a data structure, and a marked boundary between kept and rebuilt make the next quote much faster to produce. Confirm up front whether you can commission the analysis and place the build elsewhere; whether that condition can go into the contract is the answer. Freesi states the analysis scope and the documents it produces in the quote before work begins, and those same two questions are worth putting to any vendor.

This is also where "just add login" stops being a small request. On published software outsourcing rate tables, API integration at the level of social login or maps sits in a small-project band of 500,000–2,000,000 KRW (approx. USD 360–1,450), stated as a project total, because that figure counts the rules and exception handling that attach behind the screen. On the same tables, shipping, public-data, and payment integrations move up to 1,000,000–5,000,000 KRW (approx. USD 720–3,620). What an integration quote has to contain is set out in commonly overlooked items in API integration outsourcing quotations.

Keeping it and running it yourself is a real option under specific conditions: the users are you and a small number of colleagues, no customer personal data is collected, there are no payments, and a day of downtime does not stop the work.

Under those conditions there is not much to maintain.

Save the point where it worked. Put the code in a repository and mark the state that ran well. Saving before you direct an AI to make a change gives you somewhere to return to when it breaks. When a change takes down a different screen, you revert to that point and try again rather than holding a broken build while you hunt for the cause.

Back up the data on a set schedule. Automatic or manual makes no difference, but open the downloaded file once and confirm it actually opens. A backup nobody has opened reveals its problem at the moment recovery is needed, and that is when a zero-byte file or broken encoding shows up.

Keep keys outside the code. Do not write API keys and passwords into the source, and do not leave the repository public. Keys pushed to a public repository get found by automated scanners, and a recent push is not a safe one.

If you do only one of these, do the backup. Deleted data has no route back, which makes it the hardest thing to recover.

The point where these conditions break is easy to recognize. Customer data starts coming in, money changes hands, or someone other than you can no longer do their job without that screen. From there on, who fixes an outage and by when has to be settled in advance. Collecting personal data in Korea brings obligations under the Personal Information Protection Act; if your users sit in another jurisdiction, the equivalent regime there attaches at the same point.

Confirming how much of what you built can be kept is the place to start.