Most of what a developer needs is what you’re about to publish on the internet anyway — the genuine exposure is narrow and sits in three specific places, all fixed by account ownership rather than by withholding information. Being straight about the evidence: we found no documented leak cases in the complaint records we collected.
What they actually need
Look at the list and notice how much of it is going public in three weeks:
| What they need | Sensitive? |
|---|---|
| Your services and what you do | No — going on the site |
| The prices you’ll publish | No — going on the site |
| Photographs of your work | No |
| Your address, phone, hours | No — public |
| Your logo file | No |
| How long you’ve operated, credentials | No |
| Access to your domain’s DNS | Manageable — give access, not ownership |
| Where the contact form should deliver | Matters — must be your inbox |
Seven of eight rows are things a stranger will be able to read from your website. The nervousness usually attaches to the whole category when only the last two rows warrant it.
The three genuine exposures
1. Your enquiry inbox. If the contact form delivers to an address the developer controls, they can see who contacts you and what about. This is the real one, and it’s common — not through malice, but because setting the form to their own address is faster during testing and nobody changes it afterwards.
Fix: insist the form delivers to an email account under your control, and test it after launch. Send a test enquiry and confirm where it lands.
2. Accounts registered under their details. The domain, hosting, business email, analytics, payment gateway, Google Business Profile. One buyer’s account describes a developer registering their site against a personal email — when they applied for a payment gateway, the verification details didn’t match and transactions were withheld. The site existed; money couldn’t move.
Fix: everything registered under your own email, in accounts you control. Give access rather than ownership.
3. Customer and order data, on a store. A store means real customer records and order history. That’s a different category from brochure content.
Fix: a short NDA is reasonable here, and any competent vendor signs one without comment. Also limit admin access to what’s needed.
What to hold back
Send the minimum. A developer needs the prices going on the site, not:
- Your full internal rate card or margin sheet
- Your customer list
- Supplier terms or purchase costs
- Bank statements or financial records
- Staff salary information
None of that is required to build a website. If it’s requested, ask why — there’s usually no good answer.
The confidentiality line
For a brochure site, one sentence in your scope message is proportionate:
Please treat our pricing, customer enquiries and any business information shared during this project as confidential.
For a store, or anything touching your internal systems, a short NDA. Not because the risk is dramatic, but because it’s cheap and it sets the expectation.
Why the incentives are mostly on your side
A developer serving small businesses depends on referrals within local networks and trades. Misusing a client’s information would end that, and word travels fast inside a market association or a supplier network.
Also, practically: your competitor can read your prices by opening your website. The information a developer could pass on is mostly information you’re publishing deliberately.
The realistic risk isn’t malice. It’s carelessness — the contact form left pointing at their inbox, the domain registered under their email, an assistant given full admin access. All three are prevented by structure, not by suspicion.
The four-line message that handles this
Send this once, before sharing anything substantial:
Before we start: please register the domain, hosting and any email under my own accounts, with my email address. The contact form should deliver to [your email]. Analytics under my Google account. And please treat our pricing and any customer enquiries as confidential.
Four sentences, and the three genuine exposures are closed. A vendor who objects to any of it has told you which one they’d prefer to keep.
What to do this week
- Confirm the contact form will deliver to an inbox you control.
- Ask for domain, hosting, email and analytics under your own accounts.
- Send the confidentiality line with your scope message.
- Share only the prices going on the site — nothing internal.
- Test the form after launch and confirm where the enquiry arrived.
If you want it done the certain way
Everything goes under your accounts — domain, hosting, email, analytics — so your enquiries never pass through us, and we’re happy to sign a confidentiality line or a short NDA before you share anything. WhatsApp us; we reply in about five minutes between 9am and 7pm.
Related reading
- Will a developer leak my prices to a competitor?
- How to actually hand over website content
- Why is your company email still a Gmail address?
- Should there be a written agreement for a website project?
FAQ
What information does a web developer actually need?
Your services, the prices you’ll publish, photographs, address and contact details, your logo, and DNS access to point the domain. Almost all of it is going on the public site anyway.
What shouldn’t I share with a web developer?
Internal rate cards, margin sheets, customer lists, supplier costs, financial records and salary information. None is needed to build a website.
Where do my website enquiries actually go?
Wherever the contact form is configured to send them, which is sometimes an inbox the developer controls. Insist it delivers to an account under your control, and send a test enquiry after launch to confirm.
