To test an app a freelancer or agency built for you: ask for a working staging copy and test accounts for every role, then turn each item in the contract or requirements document into a test with a result of 'matches' or 'does not match'. Walk the journeys in full on a phone, try wrong input and permissions, write every finding with steps and a screenshot, and classify it as a defect against the agreement or a new request. Do not sign off or make the final payment with a critical bug in a core journey, or before you hold the code, accounts and domain.
- how to test an app built by a freelancer
- how to accept software from an agency
- user acceptance testing checklist
- how do I check a developer's work if I am not technical
- what to ask a developer for at handover
- software handover checklist
What does it mean to accept an app someone else built?
The developer sends a link and a message: 'The app is ready, waiting for the final payment.' You browse three pages, it looks good, you transfer the money. Two weeks later you find the admin panel cannot export reports and bookings accept past dates, and the developer is busy with another client. Testing an app you did not build prevents that story. Its usual name is acceptance testing.
IllustrationIt is like taking over an apartment from a contractor: you walk through with a list. Power works, water runs, doors lock. The reference is the contract, not your taste.
- The question
- Does it match what was agreed?
- The reference
- The contract or requirements document
- Who does it
- You or your representative, not the builder
- When
- Before sign-off and the final payment
- The outcome
- Accept, accept with conditions, or reject
What should you have in hand before you start?
Do not start until this list is complete:
No requirements document? Write a list now of what you agreed, from messages and the quote, and have the supplier confirm it before testing. For future projects: how to write a requirements document.
How do you turn contract items into tests?
Each line of the feature list becomes a yes-or-no question plus evidence. Contract items are written loosely; make them checkable:
| Contract item | The test | Evidence |
|---|---|---|
| 'Sign-in by mobile number' | I register with my number, the code arrives, I get in. A wrong code is refused | A screenshot of each case |
| 'Cart and online payment' | I add two products, pay with a test card, and the order shows as paid in the admin panel | The order number on both sides |
| 'Admin dashboard' | I add a product, edit a price, change an order status, export a report | Before and after screenshots |
| 'Supports Arabic and English' | Every page, message and email in both, with correct direction | The list of pages checked |
| 'Mobile responsive' | Every journey at phone size, no sideways scroll or cut-off button | Screenshots from a real phone |
| 'Staff permissions' | Staff cannot see financial reports and cannot delete | Trying to open the link directly |
These questions are acceptance criteria. For wider checking beyond the contract, use the rounds in how to test a website before launch.
How does the testing period run, day by day?
Agree a fixed testing period with the supplier, in the contract if possible. An example of ten working days for a mid-sized app:
- Day 1Setup
Complete the 'before testing' list. Turn contract items into a test table and send it to the supplier so nothing surprises them.
- Days 2–3Core journeys
Walk every journey in full in every role, phone first. Record what matches and what does not.
- Day 4Hard cases
Wrong input, permissions, double booking, declined payment, and everything obvious but unwritten.
- Day 5First report
Send the findings in one batch, numbered and sorted by severity, not as scattered messages.
- Days 6–8Fixing
The supplier fixes. You add no new requests during this window.
- Days 9–10Re-check and decide
Repeat every journey, not just what was fixed. Then the acceptance decision.
One re-check round is expected and two are acceptable. If you need a fifth, the problem is the build quality itself, which is a different conversation.
How do you write findings so the supplier fixes instead of arguing?
Most handover disputes start from vague findings such as 'payment has a problem'. The supplier cannot reproduce them and replies that it works. A good finding leaves nothing to debate: a clear title, numbered steps, expected versus actual, a screenshot and the device used. The full template is in how to write a bug report.
Before sending, classify each finding as one of three kinds:
| Kind | Meaning | Who bears it | Example |
|---|---|---|---|
| Defect | Does not work, or contradicts the agreement or the obvious | The supplier, within the price | A booking accepts a slot already taken |
| Change request | Works as agreed; you now want it different | You, with a new agreement and price | I want to add installment payments |
| Ambiguity | The item can be read two ways | Negotiate in good faith | 'Reports' without saying which reports |
A finding the supplier reproduces first time gets fixed. A finding they have to ask you about turns into a debate.
Be fair: do not slip new requests into the defect list to get them free. It sours the relationship and delays acceptance.
When do you sign off, and when do you refuse?
Pick the one that sounds like you to see the advice.
Accept. Write a short acceptance note with the date, the app version, and any remaining low findings with a date for fixing them.
Accept with conditions: take delivery with a written list of findings and fix dates, and tie part of the final payment to closing them if your contract allows.
Do not accept yet. Customers could not buy or book, so the app is not fit to launch. Give a fixed deadline for the fix and re-check.
That is an incomplete delivery, not a bug. Go back to the contract: either they are built, or the price and agreement change in writing. If it gets complicated, consult a legal professional.
This is practical guidance, not legal advice; payment, acceptance and warranty terms are governed by your contract. If you are still choosing a supplier, compare the options in AI builder or freelancer and AI builder or app agency.
How does an AI QA agent give you an independent opinion?
At handover the only expert in the room built the app. You need a third party with no stake. Fanann's QA Engineer tests any website or web app, even one not built in Fanann: you give it the staging address and what was agreed, it proposes a plan you review, runs it in a real browser, and reports with screenshots, steps to reproduce each bug, and its severity.
- Proof of ownership: before testing an external site it asks for proof that it is yours: a file on the site, a tag in the page, or a DNS record. Ask the supplier to add it.
- A shareable report: on plans that include sharing, you send the supplier a read-only link instead of scattered screenshots.
- Re-testing: after the supplier fixes, you rerun the same cases, and a bug closes only when they pass.
- Its limits: it tests what runs in the browser. A store-installed mobile app, load testing and security audits are outside its scope.
I received this app from a software agency and want to confirm it matches the contract before I accept it. The agreed items: sign-in by mobile number, a list of services with prices, booking an appointment with a choice of staff member, paying a deposit online, a confirmation notice, an admin panel that shows today's bookings and allows canceling them, a staff role that cannot see revenue, and an Arabic and English interface. Test each item at phone size and tell me: matches or does not match, with evidence. Then try the obvious: booking the same slot twice, a date in the past, and a staff member opening the revenue page by direct link. You are on the staging copy and may create test bookings; do not complete a real payment.
Try it in FanannWhat should you receive besides a working app?
An app running under the supplier's accounts is not yours yet. Before signing, make sure all of this is in your name:
Code ownership is worth reading about before any contract: who owns the code?. After acceptance, keep the test cases and rerun them after every change; they are now your permanent safety net.
Key takeaways
- Acceptance testing asks one question: does what was delivered match what was agreed? Not: do I like it?
- Test a working copy in your own hands, not a video or a demo the developer drives.
- Separate a defect from a change request; the first is the supplier's, the second is a new agreement.
- An opinion independent of the builder protects you; a QA agent gives an evidence-backed report both sides can read.
- Handover is more than a working app: code, accounts, domain and database must be in your name.
Frequently asked questions
How do I check a developer's work if I am not technical?
Should I make the final payment before testing?
What is the difference between a bug and a change request?
How many days do I need to test an app before accepting it?
Can a QA agent test an app on the supplier's server?
What if the supplier refuses to fix the findings?
Ask your AI assistant about this
Copy this prompt into the AI assistant you use, then add the details of your own case.
I am reading this guide: “How to test an app someone else built for you, before you accept it” https://fanann.com/en/blog/test-an-app-you-did-not-build/ My question: how to test an app built by a freelancer Use that page as a source and explain the answer step by step for my situation, tell me what to check before I start, and cite the page link.