How Can I Tell If My Developer Did the Work I Paid For?

How can I tell if my developer did the work I paid for?

Compare what you can see and click against what the contract or proposal promised, feature by feature. Then check that you control the code, hosting and accounts, and that the work history shows steady progress. You do not need to read code to do most of this. The ten checks below show you where to look.

If a few of these fail, that does not prove anything on its own. Projects slip for many reasons. It does tell you whether you need a closer look.

What are 10 checks a non-technical owner can do?

List what was promised, click through the product, test with real data, try other devices, check your logins, ask for repository access, look at activity, compare invoices to activity, ask for a demo, and ask for a handover. Each takes minutes, needs no programming knowledge, and gives an answer you can write down.

• • 1. List what was promised. Pull the contract, scope document, proposal and any change orders. Write each feature or deliverable on a line. If there is no contract, use emails, chats and invoices as your list.
• • 2. Click through the product. Try every item on your list on the live site or app. Mark each one as working, partly working, or missing. Screenshots help.
• • 3. Test with real data. Create an account, submit a form, place a test order. A page that looks finished may not save anything.
• • 4. Try it on your phone and another browser. Problems often show up away from the developer's own setup.
• • 5. Check the logins. Can you sign in to the admin area? Do you know the hosting, domain and app store account owners? If not, you do not control the product.
• • 6. Ask for repository access. Request owner or read access to the code repository. If the developer cannot or will not provide it, note that in writing.
• • 7. Look at the activity. Ask a technical friend, or any developer, to open the repository's commit history. They can see how often work was saved and over what period. Steady activity matches a working project. Long gaps or one huge dump at the end are worth asking about.
• • 8. Set invoices next to activity. Put your invoices and payments beside the dates of that activity. Treat this as a comparison to question, not proof. Commits are not hours, and quiet weeks can have good reasons.
• • 9. Ask the developer to demo. Ask for a screen-share where they run the product from the code, on a clean machine if possible. A developer who built it can usually do this.
• • 10. Ask for a handover. Request the repository, documentation and credentials. How they respond tells you a lot.

Keep a simple table of what you find:

The example is made up, but the format is what matters. A table like this is clear to read, and it is the same format a professional review uses to compare deliverables with the contract.

What signs of trouble do owners describe?

People who have been through this describe similar patterns: a feature that was in scope suddenly "cannot be done" part-way through; payments continuing while the product stays unfinished; a refusal to share the code; and ongoing fees for services nobody can explain. None of these proves bad faith, but each is a reason to look closer.

The phrasing below is paraphrased from public threads where owners asked for help, linked in the bullets.

• • A problem appears mid-project. One owner on r/startups said that at the third sprint they were told some features could not be built, even though those features were part of the agreed scope (thread).
• • Missing or broken features. An owner on r/webdev described many bugs and functions from the scoping document that were not implemented or did not work, and said they did not want to keep working with the previous developer (thread).
• • Fees that are hard to explain. Another r/webdev post describes a monthly hosting fee plus a separate monthly security service fee, with the owner unsure what the services included (thread).
• • No access to the code. An r/appdev post asks how to update an inherited mobile app with no source code access (thread).

Owners also worry about not being able to verify any of it without programming knowledge. That gap is what an independent review fills.

When should I get an independent review?

Get one when your self-check turns up several missing features, when you cannot get access to the code or accounts, when you are about to pay more, or before you hand the project to a new developer. An independent reviewer answers whether it builds and runs, what was delivered, and what it would take to fix.

Look for a reviewer who:

• • Has no stake in selling you the rebuild.
• • Gives you a written scope and a fixed price.
• • Compares the work against your contract or SOW, not just a general quality score.
• • Shows findings with locations, severity and fixes you can pass on.
• • Is clear about the limits of the work. A technical review is a record of facts. It is not a legal opinion.

If there is a possible dispute, talk to a Florida attorney before taking any action against the developer. A neutral technical record of what exists can help the attorney, but the decisions on what to do with it are theirs.

How do I safely share code with another developer?

Use a mutual NDA, give read-only access, and share only what the reviewer needs. Keep the original in an account you own. Never send passwords by email, and rotate any keys or credentials that sit in the code once the review ends.

Owners often worry about this, because it is a fair question: if you hand your app to a stranger, what stops them from copying it or planting something? These steps reduce the risk.

• • Sign an NDA first. A mutual non-disclosure agreement sets the ground rules before any code moves. Some firms offer one as standard before they look at code.
• • Read-only access. Add the reviewer to your repository with read-only permission. They can look but not change anything.
• • Use your own account. Share through a repository or cloud account you own, so you can remove access when the review is done.
• • Do not share live secrets. Production passwords and API keys do not need to leave your hands for a review. If keys were committed into the code, plan to rotate them.
• • Remove access at the end. Revoke the invitation on the date the work finishes.

If you do not own the repository yet, getting that access comes first. See our guide on how to get your source code back from a developer.

What does Cuanto Labs offer for this?

The Project Health Check is for owners whose developer stopped or did not deliver. It is $1,500 flat for up to about 50K lines of code, $2,500 for larger codebases, and takes 5 business days. It answers the question in this article with a written report.

You get whether it builds and runs, a gap table of deliverables against your contract or SOW, an ownership and access checklist, the top code and security issues, a commit-activity timeline set against your invoices, and a fix-or-rebuild estimate. It is independent. We do not require you to hire us for the fix. For inherited or aging codebases at companies, see the Code Audit, from $4,000 and about 2 weeks. For acquirers and investors, see Software Technical Due Diligence, from $7,500 and 5 to 10 business days. To talk through your situation, book a call.

This article is general information, not legal advice. Cuanto Labs is a software studio, not a law firm.