The Developer Took My Money and Didn't Finish the App

Money left your account, the app is not finished, and the person who was building it has either gone quiet or is still replying in a way that never turns into working software. Some version of “the developer took my money and didn’t finish” gets typed into a search box at the worst possible moment, usually within an hour of the penny dropping, and almost everything written for that moment starts at the complaint.

The useful part of this is not the person who left. Three decisions made at hire time set how much their leaving would cost: what the money bought, when it moved, and whose accounts the work lived in. All three can be set differently before the next payment goes out.

Whether you were treated badly is not what this page settles, and none of it is legal advice. It also does not tell you how to get the code and the accounts back, because that job has its own page and its own rules.

Every payment arrangement described below comes from the operator’s own documentation, opened on 26 August 2026: Escrow.com’s milestone pages for how a funded milestone is agreed and released, Stripe’s disputes documentation for what happens after a card payment is contested, and the text of Title 17 published by the US Copyright Office for the one sentence about written transfers. Upwork’s help centre, Fiverr’s help centre and Toptal’s public pages each refused an automated read that day, so nothing here is claimed about what those three currently publish. No arrangement was entered into, no payment was made, and nobody’s dispute was handled for this page.

What the arrangement looked like before the work stopped

Go back to the week you agreed it. Three things got settled then, usually in a chat window rather than on paper, and between them they decided how expensive the ending would be. Behind almost every account of having hired a developer who never finished, those same three are where the money went.

What the money bought. Either you were buying hours, or you were buying a named result somebody else could look at and say yes or no to. Hours are honest and they are also unfalsifiable: forty hours were worked, the login screen exists, and nobody in the conversation can say whether that was a good trade. A named result has an edge on it. “A person can sign up with an email address, get a confirmation mail, come back the next day and still be signed in” is a sentence two people can disagree about and then settle by trying it.

When the money moved. Half up front and half at the end is the most common shape, and it is the shape that concentrates all the risk in the middle. The half you paid up front bought goodwill. The half at the end bought a deadline that only exists if the work is still worth finishing when you get there. Money that moves in smaller pieces, each attached to a thing you can watch happen, is the only version of this where a bad week costs a week.

Whose accounts it lived in. This is the one owners never think of as a payment decision, and it is the one that decides what the money bought when everything else falls apart. If the code host, the database, the hosting, the domain records and the store listings were all opened by the person you hired, then what you bought was their goodwill in handing them over later.

Two shapes turn up again and again in public founder posts. One is the owner who has already paid a second company to rebuild the app, because the first version stopped coping once real numbers of people were on it, which means the same money got spent twice on the same product. The other is the owner asking, after changing the people building their product, what actually turned out to be hard, and getting back an inventory of things they had never held: the backups, the deployment steps nobody had written down, the domain records, the store accounts, the paid API accounts, the database, the cloud console, and the code host itself.

Getting the repository, the database and the accounts moved into your own name is the job that comes before any of this, and each of those moves has a documented rule and a named person who is allowed to make it.

None of the three decisions above requires you to have distrusted anybody. They are the shape of the arrangement, and the shape is what you are choosing again next week.

Why the app kept looking further along than it was

Owners tend to feel stupid about this part, and the feeling is misplaced. You watched it happen. Screens loaded, buttons did things, a record appeared in a list. Everything you were shown was real, and the app was still nowhere near finished, because what you were shown and what was actually wired up are two separate questions and only one of them is visible from the outside.

The audit study behind these counts, and what it did with 26 AI-built apps puts a number on the gap. In AxonBuild’s fixed study of 26 real applications audited in June and July 2026, where each finding had to be traced in the application’s own code before it counted at all, 22 of the 26 came out red on at least one confirmed critical finding, and none of the 26 came out green. These were working apps. People were using several of them.

The pattern that matters here has nothing to do with anybody being lazy. AI builders produce the visible part of a feature reliably and the enforcing part of it inconsistently. A limit on how often a costly endpoint can be called gets written and then sits in a file that no running request passes through. An error boundary exists as a component and is not placed anywhere in the tree. A rule about what a customer is allowed to see is written down in the repository in plain words and nothing at runtime reads it. Each of those is a real thing somebody typed. Each of them also does nothing.

So when the person you hired said a feature was done, they may have been describing the file rather than the behaviour, and you had no way to tell the difference from a screen share. That gap is a measurement problem rather than a character judgement, and it has a purchasing fix: pay for behaviour you can produce yourself, on your own machine, with your own account, and pay after you have produced it.

Grading what somebody hands over while there is still a person answering messages is a different exercise, run on things you can watch happening rather than on the arrangement that produced them.

How do you pay for app work so the money is not gone if the work stops?

Four arrangements cover almost every way a non-technical owner pays for app work, and they behave completely differently at the moment the work stops. Only one of the four has a company in the middle holding the money and publishing the rule for releasing it. Two of them have nobody in the middle at all.

The marketplace row is empty on purpose. On 26 August 2026, Upwork’s help centre articles, Fiverr’s help centre articles and Toptal’s public FAQ each returned an HTTP 403 to an ordinary automated read, and so did Upwork’s legal page. The four addresses tried that day were support.upwork.com/hc/en-us/articles/211062898-Fixed-Price-Protection, help.fiverr.com/hc/en-us/articles/360010451397, toptal.com/faq and upwork.com/legal, credited by address and never linked, because all four belong to companies selling the same hire. Those three run the fixed-price arrangements most owners will actually be offered, and I will not describe a mechanism I could not read on the day I wrote about it. Nothing on that row is filled in from memory, from a search result summary, or from what marketplaces are generally understood to do. If one of them becomes readable, the row gets filled from the source and dated again.

That gap is worth sitting with rather than skipping past. Three of the largest operators in this market publish their rules behind a door that closes on anybody trying to read them programmatically, which means the comparison a buyer most wants is the one nobody can assemble.

What does a funded milestone actually do for the person paying?

A funded milestone is money the buyer hands to a third party before work starts, released one piece at a time as each piece is accepted. Escrow.com’s own milestone process page describes five steps and six things both sides agree to at the beginning. The surprise for most owners is that the whole amount goes in up front.

Escrow.com’s milestone process page states that “Milestones divide a transaction into multiple phases, each with a clearly defined parameter and a corresponding dollar amount”. The five steps it lists run in this order: the buyer and seller agree to terms, the buyer pays Escrow.com, the seller delivers the milestone, the buyer accepts the milestone, and Escrow.com pays the seller. The transaction is complete when the buyer has accepted all of them.

The agreement at step one is the part that does the work, and it is short enough to hold in your head. Escrow.com’s page lists what both sides settle before any money goes in: the number of milestones, a description of each milestone, the price for each milestone, the number of days for the buyer’s inspection, who pays the escrow fee or whether it is split 50/50, and shipping information. Six lines, and the last one is there because the same process also moves physical goods; it has nothing to answer on software work. An owner who has never written a technical brief can still settle the other five, because none of them is a technical question.

Now the part people flinch at. Escrow.com’s milestone page states that “Buyers are required to fully fund milestone transactions at the start of the transaction before any goods are delivered or any work is completed by the Seller”, and that “Sellers receive funds as they successfully complete each milestone within a transaction”. So you part with all of it on day one. What you keep is the release.

Paying everything up front and releasing it a piece at a time is a different arrangement from paying half up front: more money leaves your account on day one, and what you keep is control of the release.

Two details worth knowing before you suggest it to somebody. Escrow.com’s process page states that “If your payment is under $5,000, then you can use PayPal, Credit, or Debit card. If your payment is for more than this amount, then you can only pay via wire transfer”, read on 26 August 2026, and a threshold like that is a number the company can change without telling anybody. The same page says the fee can be paid by either side or split evenly, which makes it something to raise at step one rather than discover at the end.

And when a milestone is contested, the page describes a process rather than a verdict: the buyer has a set number of days to inspect each milestone and can accept or reject it, and if there is a disagreement “The dispute resolution service is a formal process, so both Buyer and Seller receive support from a neutral Escrow agent”. What that sentence promises is support through a process. Nobody is promising you a refund at the end of it.

Escrow with an inspection period also turns up when somebody is buying a finished app outright rather than paying for work to be done, and the timings and the checks are different in that direction.

If the money already went out on a card

Before anything else: what follows describes what the documentation says the process is. It does not tell you what will happen in your case, and whether any of it gives you a claim is something only a lawyer in your own country can answer.

If the person you hired took payment by card, or sent an invoice that you paid by card, the deciding party is your own bank rather than the company that processed the charge. Stripe’s disputes documentation is direct about its own position: “Throughout this process, Stripe facilitates your case, but doesn’t have influence over the outcome, which is at the sole discretion of the account owner’s bank.” Read that once more with the roles swapped in, because it is easy to misread. In that sentence the account owner is you, the cardholder who paid, and the bank deciding is your own card issuer; the developer is the merchant on the other side of the charge, and Stripe is the processor carrying the dispute between the two.

The clock is longer than most people assume and it does not always start where you think. Stripe’s documentation says that “Card networks typically allow cardholders to initiate disputes within 120 days of the original payment, but their rules allow more time in some situations”, and that when somebody pays for a future service, “the dispute window starts on the event date, not the payment date”. App work paid for in advance sits somewhere near that second case, which is a question for your own card issuer rather than for a documentation page.

Then it is slow. The same page states that “The full dispute lifecycle, from initiation to the final decision, can take 2-3 months to complete”, and that once the issuer decides, “This outcome is final for all parties.” Stripe’s page adds that it does not support the arbitration phase, so there is no escalation route through the platform after that.

Two to three months, decided by somebody who was not in the room, with no appeal. That is the honest answer to “can I just do a chargeback”, and it is why the arrangement matters more than the recovery. The ordinary complaint route sits alongside it rather than replacing it: the FTC’s page on solving problems with a business points people at their state attorney general or state consumer protection office, which it says “might mediate complaints, conduct investigations, and take other action”, and is plain that filing with the FTC itself is not a personal remedy: “The FTC doesn’t resolve individual complaints, but your report helps law enforcement detect patterns and might lead to an investigation.”

None of this gets you the code. The access work described further up runs on its own clock and does not wait for a card issuer, so start it first whatever you decide about the money.

What to agree in writing before the next payment moves

There is nothing to download here and no contract to copy. What follows is four things written in ordinary words, in whatever the two of you already use, each one earning its place because of a specific way the last arrangement failed.

One: what each payment is attached to, as something a person can do. “The login system” is a component and settles nothing. “I can register with my own email, receive the confirmation, close the browser, come back tomorrow and still be signed in” is a sentence you can go and try. Written that way, each payment carries its own test, and neither side has to argue about percentages.

Two: how long you get to look before the money is released. Escrow.com’s process makes the buyer’s inspection period one of the five things both sides fix at the start, and the same idea works without an escrow company in the middle: a number of days, agreed in advance, between “it is ready” and “it is paid”. Days you have to negotiate while somebody is waiting to be paid are not the same as days you agreed to before anyone was owed anything.

Three: whose name every account is in, from day one. The code host, the database, the hosting, the domain registrar, the payment account, the store listings. You open them. You invite the person you hired into them. The order matters more than it sounds, because every one of those platforms treats the account holder and the person with access as separate roles, and only one of the two survives somebody going quiet.

Four: that the code you paid for becomes yours, in writing, signed. In the United States, this is not a formality you can leave implied. Title 17 of the US Code, section 204(a), published on the US Copyright Office’s Title 17 chapter 2 page, states that “A transfer of copyright ownership, other than by operation of law, is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed”. That is the whole of what this page says about copyright, and it is US law only. What it means for your situation, and what your local law does instead, is a question for a lawyer.

Whether the code you already paid for is yours today, and which accounts have to carry your name for that to mean anything, is settled item by item somewhere else. This section is about the next arrangement, not the last one.

What to change about the next hire

Most of what is worth doing differently is not on this page, and saying so is more useful than restating it badly.

The eight questions that decide whether the next person is worth paying come with an answer key of their own, and this page does not repeat them. Checking somebody’s history and the work they say they shipped, before any money moves, is an hour of separate work with its own short list of checks. Working out what finishing the app is actually worth, and what a fair first job looks like when you commission it, is the decision that sits above this one. And the money question, what a developer charges for one finished result, route by route, has an answer that does not depend on what happened last time.

What changes on this page specifically is the size of the first payment. Whoever you hire next, buy something small first: one thing, described as behaviour, with a number of days to look at it and a payment that only moves after you have looked. A bad fit then costs you one small piece instead of half a project, and a good fit has proved something neither references nor a call can prove.

Where I fit is worth stating plainly on a page like this one. The 20-minute video call is free. Show me the app, what it should do and where it stops, and I will help you work out what needs checking. If you want me to make the changes, I check the code first and give you a fixed quote, we agree what the app should do, and you pay after you see it working. Finishing what somebody else started is quoted the same way, after I have read what is there. There is nothing to download at the end of the free call and nothing written up afterwards: what you get is what I show you on the call, and then the changes you agree to.

Common questions about a developer who did not finish the app

My developer took my money and did not finish the app. What do I do first?

Put the code, the database and every account back in your own name before any new money moves, or the same bill arrives twice. Each platform publishes its own rule for who is allowed to move what, and on several of them the permitted person is the one who has stopped replying. Ask for those specific transfers while there is still any contact, one named action at a time.

Can I get my money back from a developer who did not finish?

Sometimes, and slowly, and not through the payment company. Where you paid by card, your own card issuer decides the outcome, and Stripe’s disputes documentation states that the full dispute lifecycle “can take 2-3 months to complete” and that the result “is final for all parties”. Where you paid by bank transfer, there is no third party holding anything and no published process to invoke.

Is it normal to pay a developer up front?

Paying something up front is ordinary, and paying half of a whole project up front is where the arrangement goes wrong. The useful change is where the money sits rather than how much of it moves: somewhere it is committed but not yet spendable. Escrow.com’s milestone pages describe the extreme version of that, where the buyer funds the entire amount before any work starts and it releases piece by piece as each one is accepted.

What is a funded milestone, and what does it actually protect?

A funded milestone is money handed to a third party before work begins, released as each agreed piece is accepted by the buyer within a set inspection period. The release is the protected part, and the deposit is not. Escrow.com’s page states that buyers “are required to fully fund milestone transactions at the start”, so all of the money leaves your account on day one and none of it reaches the other side until you accept.

Should I pay through a marketplace instead of paying somebody directly?

I cannot answer that honestly today. On 26 August 2026, the help pages of the three largest marketplaces in this space, Upwork, Fiverr and Toptal, each returned an HTTP 403 to an automated read, so I have no readable statement from any of them about how their fixed-price arrangements hold or release money. What is safe to say is that a company in the middle publishing a written rule is structurally different from a bank transfer, where nobody holds anything.

I hired someone to build software and they did not deliver. Was that my fault for not knowing what to ask?

No. The competent-sounding version of this advice, which is that you should have written better requirements, mostly blames the person with the least information in the room. What was genuinely decidable was smaller than that: what each payment was attached to, how long you had to look before it moved, and whose name the accounts were in. None of those three requires you to understand any code.

Do I own the code if the work was never finished?

Ownership and access are different questions, and both get settled item by item rather than in one answer. On the ownership side, section 204(a) of Title 17 of the US Code says a transfer of copyright is not valid unless it is in writing and signed by the owner of the rights conveyed, which is US law only. On the access side, whose name each account is in decides what you can actually reach today.

Can somebody else finish an app the last person left half done?

Usually, and the price depends on what is really there rather than on how far along it looked. Anybody picking it up will want to see the code running, find out which parts are wired up and which only exist as files, and check which accounts you can already sign into yourself. That inspection is worth paying for on its own before you commit to a second build.