Finding someone who can build a website is different from finding someone who understands what your website needs to do. If you are choosing a web developer in Cheltenham, the useful comparison is how each person would help your customers, handle the work and leave you able to run the site afterwards.
You do not need to judge a developer's programming skills from a conversation. You can ask for clear explanations, relevant evidence and a proposal that makes the responsibilities visible. Those are things a business owner can assess without a technical background.
Write down the job before making a shortlist
Begin with three sentences: who you serve, what visitors need to understand, and what you want them to do next. Add the main problem with the current site, if there is one.
"Make it look more modern" is a valid starting feeling. "People cannot tell which service fits their problem, so enquiries arrive with the same unanswered questions" gives a developer something more concrete to solve.
Decide whether you mainly need design, copy, development, or a combination. A proposal that assumes you will supply finished text is different from one that includes helping you structure and write it. A brief list of responsibilities helps you prepare that information.
Look at work as a customer would
A portfolio can show taste, but a striking homepage is only part of a website. Open a few examples on your phone and try to complete an ordinary task.
- Can you understand the business and its main offer quickly?
- Can you find a service, price explanation or next step?
- Are text and buttons comfortable to use?
- Does the site make useful distinctions between different customer needs?
- Does the developer explain their contribution to the project?
Ask whether the work is a client commission, a personal project or an in-house product. Each can demonstrate ability, but they provide different evidence. For an unfamiliar business type, ask how the developer would learn about your customers instead of assuming that only an identical past project can be relevant.
Ask about the process, using your own project
Questions are more revealing when they refer to a real decision you face. If you have twenty old pages, ask how the developer would decide what to keep. If you rely on email enquiries, ask how they would check that the new enquiry route works.
Useful questions include:
- What information do you need before confirming the scope?
- Who is responsible for writing and approving the content?
- What will I see before the full site is built?
- How are revisions and additional requests handled?
- How will we agree that the site is ready to launch?
- What will I receive at handover?
Listen for answers you understand. Clear explanations matter because you will need to make decisions together when the project becomes more detailed.
Compare proposals on the same basis
The cheapest total may cover fewer pages, less content work or less support. The most expensive total may include functionality you do not need. Compare what is included before comparing the number at the bottom.
For each proposal, note the deliverables, content responsibilities, integrations, review stages, launch work, recurring charges and support arrangements. Mark omissions as questions rather than making assumptions.
You should also understand the boundaries of the estimate. A quotation based on five approved pages cannot necessarily absorb an online shop halfway through the build. The website cost guide explains the scope differences worth checking.
A simple comparison exercise
Imagine a Cheltenham service business choosing between two proposals. This is a hypothetical example, not a client case study.
One includes a polished design but assumes the owner will deliver all copy and imagery. The other includes content planning, a smaller initial site and a documented handover. If the owner has little writing time, the second may fit better even if the first portfolio feels more impressive.
Give each proposal a short written assessment against four headings: customer fit, clarity of scope, working relationship and long-term practicality. Record what evidence supports your judgement. Do not reduce everything to a score that hides an unanswered ownership question.
Make local availability specific
Working with someone based in Cheltenham may make an initial meeting or understanding the local business context easier. Agree what that means in practice: meeting format, who you will speak to, expected response times and how decisions will be recorded.
Location alone does not establish reliability or technical quality. The combination of relevant work, clear communication and a workable process is more useful.
At Singularity Shift, you work directly with James Walford. You can read about website design and development in Cheltenham before deciding whether that way of working suits you.
Before you say yes
Ask for the scope, price basis, payment stages and handover arrangements in writing. Confirm access to your domain and hosting, and clarify what happens if either side needs to pause. See the ownership and handover guide for practical questions.
If you want to discuss your shortlist of requirements, send James a rough outline. A useful starting point is your current site, the customers you want to reach and the decision you are finding difficult.