Ask to see an ordinary update.
The proposal says “easy to manage.” Good. Ask the developer to show you what that means.
Choose something your business changes regularly: a service description, a product price, a team member, or an opening time. Watch the whole process, including the preview and publishing step. If every small change needs a support ticket, factor that into the arrangement before you buy it.
You don’t need to become a developer. You do need to know which changes you can handle, which require help, and what that help costs. A website can be beautifully built and still be a poor fit for the people expected to use it.
Whose account is it?
Ask who will control the domain registration, hosting or website platform, analytics, and connected services. Request access appropriate to your responsibilities, with individual logins rather than one password passed around a group chat.
Account access and ownership of the work are separate questions. Have the proposal spell out what is delivered, what rights are included, and what depends on third-party licenses or subscriptions. Know which recurring charges are yours and what happens if a subscription ends.
“Don’t worry, we handle everything” can describe helpful service. It can also describe a business that cannot access its own website. Ask enough questions to know which arrangement you are agreeing to.
What makes this maintainable?
Ask why the proposed platform suits your content, integrations, and budget. Then ask what would make it a bad choice. A thoughtful answer includes tradeoffs. Every platform being “perfect for your business” is less convincing.
For custom work, ask how another developer would obtain the source code, understand the setup, and make a safe change. For a hosted builder, ask what can be exported and what would need rebuilding if you moved. Exporting content is not necessarily exporting the entire website.
Custom development can be the right answer. So can an established platform. The useful distinction is whether the complexity solves a real problem and whether someone else can reasonably maintain it.
What happens after launch?
Agree what the initial handover includes: training, documentation, account access, and a list of ongoing responsibilities. Ask the developer to demonstrate the important customer journeys and explain how issues found during review will be handled.
Separate corrections to the agreed work from future changes. Confirm any support period, maintenance scope, response expectations, and charges. Someone paying the hosting bill does not automatically mean someone is checking the checkout.
Ask about backups and recovery where they apply. What is covered, how is a restore checked, and who handles it? You want an understandable plan, not an impressive collection of reassuring nouns.
Could you leave without starting over?
A good working relationship should survive a practical question about its ending. Ask how a handover to another provider would work, what would be supplied, how long it would take, and whether there are costs or restrictions.
Some dependencies are reasonable. A proprietary platform may offer conveniences that justify its limits. The problem is discovering those limits when you urgently need to move.
Compare proposals using the whole arrangement: initial work, ongoing fees, your team’s time, and the effort of a future handover. The cheapest build may still be the right choice. Just make sure you are buying a website you can run, rather than a permanent appointment with its original developer.
Put the thinking to work
Test the handover before you hire.
Choose one routine edit and ask the proposed developer to demonstrate it. Then request a written list of accounts, recurring costs, documentation, and support responsibilities.
See how the work is organized
Written by
Dan Reed
Founder of Multicomma. I design and build websites, ecommerce experiences, and custom tools, with a focus on what the business needs them to do.
More about working together
