What to Check Before Buying a Custom Website

A custom website is one of the few purchases where everything can look perfect and still be worthless. The site loads, the design is good, the forms submit — and three weeks later you discover you cannot deploy a change because the build only ever worked on the developer's laptop. This checklist is ordered by what actually goes wrong.

1. Run It Yourself First

Before anything else, before admiring the design: get the project running on your own machine or your own server.

This single step catches more problems than the rest of this list combined. Undocumented environment setup is the most common failure in custom website transfers, and it is invisible until you try.

Ask for the repository, the setup instructions, and an environment file template. Follow the instructions exactly as written. If you need to ask the seller a question to get it running, the documentation is incomplete — say so now, while funds are still held.

2. Source Code, Properly

The full repository with history, not a zip of the current state. Commit history tells you whether this was built steadily or assembled the week before listing, and whether credentials were ever committed.

No hard-coded secrets. Search the codebase for anything resembling an API key or password. Keys committed to the repository are tied to the seller's accounts and must be rotated.

Dependency manifest with versions. package.json, composer.json, requirements.txt — whatever applies. Check how old the major dependencies are.

Build and deploy instructions that a competent developer who is not the author can follow.

3. Database and Data

A dump taken at handover, not months earlier. Confirm the schema matches the code — a mismatch means migrations were applied manually somewhere.

Check what personal data is in there. If the site has real users, you are acquiring a data-protection obligation along with the rows. That is a legal responsibility, not a technical footnote.

4. Design Assets and Licences

Source files (Figma, Sketch, XD), all images with proof of licence, font files or the licence permitting their use, and the logo in vector format.

Stock photography is the usual trap: images licensed to the seller frequently do not transfer to a new owner. Ask for the licence documentation, not just the files.

5. Functional Testing

Test every interactive element, not just the visible ones:

• Contact forms — confirm the email actually arrives, not just that a success message appears
• User registration, login, and password reset end to end
• Payment flows in test mode, then one small live transaction
• Search, filtering, and pagination
• Anything behind a login
• Error states — what a wrong password or a failed payment does

The success message is not the test. Delivery is the test.

6. Technical SEO Baseline

Titles and meta descriptions present and unique. One <h1> per page. Sitemap present and accurate. Structured data validating. Reasonable Core Web Vitals on more than the homepage. Check robots.txt for a leftover staging noindex — it is a common and quietly expensive oversight.

7. Documentation

A README that covers setup and deployment. Admin panel documentation if there is an admin panel. API documentation if there is an API. A list of external services the site depends on.

8. Third-Party Dependencies

Every external service the site needs to function: analytics, CDN, transactional email, error tracking, payment processors, any paid API. For each, establish whether the account transfers, whether you need your own, and what it costs monthly. A site with $200/month of API dependencies is a different purchase than one without.

9. Ongoing Cost

Add up hosting, domain, licences, and third-party services. Sellers rarely volunteer this and buyers rarely ask.

10. Support Window

Agree in writing how long the seller will answer questions after handover — one to two weeks is normal and costs them little. Get it in the deal chat before you confirm.

Using the Escrow Window Properly

On Escrozon the seller is paid when you confirm receipt, which means the verification window is yours to use. Spend it on items 1, 5, and 8 — running the project, testing real flows, and pricing the dependencies. Those are where the expensive surprises live.

Keep the whole conversation in the deal chat. If a listing claim turns out to be false, the record of the claim is what supports a dispute.

Frequently Asked Questions

The seller will only send a zip, not repository access. Is that acceptable? It is workable but weaker. You lose commit history, which is genuinely useful. Ask why — a reasonable answer exists (private repo with other clients' code), but it should be given.

How much documentation is reasonable to expect? Enough for a competent developer to set up, deploy, and understand the architecture. Not a manual. If the setup instructions work first time, that is usually sufficient.

What if it will not run and the seller says it works fine for them? That is precisely the situation escrow exists for. Do not confirm receipt. Document the exact error in the deal chat and ask for working instructions.

Should I pay a developer to review it? For anything above a few thousand dollars, yes. A few hundred dollars for two hours of review is cheap insurance, and it fits inside the escrow window.

Can I ask for changes after confirming receipt? Only if you agreed a support window in advance. Once funds are released the transaction is complete, so agree that scope before you confirm — not after.