If you are preparing to hire a web designer in Nigeria, do not begin with “How much do you charge?”
Price matters. But a cheap quote for the wrong website is still expensive.
The useful questions are the ones that tell you what you are actually buying, who controls it after launch, what it will cost to keep running, and whether the designer understands the business problem behind the pages.
Here are the questions I would want answered before paying a deposit.
1. What problem is this website supposed to solve?
A designer should be able to discuss the business before discussing colours.
For one company, the job may be generating qualified enquiries. For another, it may be increasing hotel bookings, helping parents understand a school before applying, giving a consultant credibility after a referral, or turning an internal process into a working product.
If the conversation stays at “five pages, modern design, contact form,” you may be buying a page count rather than a solution.
Ask:
- Who is the primary visitor?
- What should that person understand quickly?
- What action should the website make easier?
- How will the structure support that action?
A good answer does not need marketing jargon. It needs a clear connection between the website and the business.
2. What exactly is included in the quote?
Two quotes can both say “business website” and describe very different work.
Ask for the scope in writing. It should make clear what is included around design, development, copy, forms, mobile layouts, analytics, basic search setup, content upload, integrations, revisions, testing and launch.
Then ask the equally important question: what is not included?
That is how you discover whether the attractive headline price excludes the work you assumed was part of the project.
If you already have several proposals, do not compare only the final numbers. Normalize the scope first. My guide to website design cost in Nigeria is useful for understanding the cost categories behind a quote.
3. Who controls the domain name?
This is one of the simplest questions and one of the most important.
Your business should know which registrar holds its domain, which account controls it, which email can recover that account, and who is responsible for renewal.
ICANN describes the registrant as the person or entity holding the rights to the registered domain and provides registrants with information about managing, renewing and transferring registrations. Its guidance also warns that when a third party registers a domain using its own details, that third party may appear as the registrant of record even when the business paid for the registration.
That is why “my developer handles the domain” is not enough information.
Ask the designer how registration and access will work before the project begins. You can read ICANN’s domain registration guidance at https://www.icann.org/resources/pages/domain-name-registration-process-2023-11-02-en and its registrant information at https://www.icann.org/registrants.
4. Which accounts will be mine?
Domain ownership is only one part of control.
Depending on the project, there may also be hosting, a CMS, analytics, Search Console, email delivery, payment providers, image storage, booking tools and other third-party services.
You do not necessarily need to personally operate every account every day. But you should understand which accounts belong to the business, which are managed by the designer, and what happens if you change providers later.
My preference is simple: infrastructure should not become mysterious merely because it is technical.
5. What will this website cost after launch?
Ask for the year-one and ongoing costs, not only the build fee.
Possible recurring costs include the domain, hosting, email, premium software, external services, maintenance and transaction fees. The exact stack differs by project, which is precisely why the question matters.
Sometimes the right technical decision is the one that removes an unnecessary monthly bill. Sometimes paying for managed infrastructure is worth it because the business needs the support. The important thing is that you understand the trade-off before launch.
If the quote is cheap upfront but requires expensive subscriptions indefinitely, compare total ownership cost before deciding.
6. What can I edit myself?
A website should not become obsolete because changing a phone number requires finding the original developer.
Ask which content you will be able to update and how.
For a hotel, that might include rooms and offers. For a foundation, representatives and activities. For a school, admissions information and announcements. For a service business, it may simply be services, staff, testimonials and contact details.
Not every website needs a large CMS. Giving every client an oversized admin system can create more maintenance than value. The useful question is whether the editing experience matches what your team will actually need to change.
7. How are mobile users being considered?
Do not settle for “yes, it will be responsive.”
Ask to see how important journeys work on a phone.
Can someone understand the offer without fighting the layout? Can they tap the primary action easily? Are forms sensible on a small screen? Does navigation remain clear? Are important images and text arranged deliberately rather than merely squeezed down from desktop?
Google’s developer guidance says sites should be secure, fast, accessible and work on all devices. It also explains that making content search-friendly helps relevant users discover it. See Google Search Central’s developer SEO guide.
8. What SEO work is included before launch?
“SEO included” is too vague to be useful.
Ask what that means.
At minimum, the designer should be able to explain how page structure, titles, descriptions, crawlability, internal links, URLs, mobile usability and performance are being considered. For a redesign, preserving valuable existing URLs and search equity may matter as much as creating new pages.
Google’s Search documentation explains that SEO helps search engines crawl, index and understand content, while Search Console helps owners monitor performance.
SEO should not be a mysterious button switched on after the website is finished.
9. How will accessibility be considered?
Accessibility is not decoration and it should not be reduced to installing a widget at the end.
Ask how the designer handles fundamentals such as semantic structure, keyboard use, form labels, contrast, alternative text and understandable interactions.
The W3C Web Accessibility Initiative publishes the standards and practical resources used to make websites and digital products more accessible to people with disabilities. Its current resources are available at https://www.w3.org/WAI/.
You do not need to become an accessibility specialist before hiring someone. You do need a provider who treats accessibility as part of quality.
10. What happens if the website needs more than a normal website?
This question becomes important when a project starts adding dashboards, user accounts, complicated payments, permissions, workflows or custom operational logic.
At that point you may no longer be buying a conventional marketing website. You may be moving toward an MVP or software product.
A good web designer should be able to recognize that boundary instead of forcing every requirement into the same website package. If your idea includes product-like behaviour, compare it with what I mean by MVP development.
11. How will forms and important journeys be tested?
A contact form looking correct is not the same as a lead arriving correctly.
Ask what is tested before launch: submissions, confirmation states, email delivery, mobile behaviour, broken links, payment states where relevant, analytics and the critical journeys that make the website useful.
This is particularly important because a silent failure can look like a marketing problem. A business may think nobody is enquiring when the form is simply not delivering messages.
Testing should follow business risk, not just visual polish.
12. What happens after launch?
Before signing, know where the relationship ends.
Ask:
- Is there a warranty or launch-support period?
- What counts as a bug versus a new request?
- Is maintenance optional or required?
- What does maintenance include?
- How are future changes priced?
- What happens if I want another developer to take over?
There is no single correct maintenance model. There should, however, be a clear one.
If ongoing support is being sold separately, use this website maintenance plan checklist to see what you are actually paying for.
13. What will I receive at handoff?
“Handoff” should not mean receiving one password in WhatsApp.
The appropriate handoff depends on the project, but you should know what access, documentation, files and instructions you will receive. If the website uses third-party services, you should also know which ones exist and who controls them.
For a simple website, handoff may be very small. For a custom product, it may include repository access, environments, deployment information and substantially more documentation.
The point is not to demand paperwork for its own sake. It is to make the business capable of continuing without being trapped by missing information.
14. Can you explain why you chose this approach?
This is my favourite question because it reveals whether the proposal contains actual judgment.
Why this platform? Why this content structure? Why this hosting approach? Why does this feature need to exist? Why does another feature not need to exist?
You are not testing whether the designer can overwhelm you with technical language. You are testing whether they can make trade-offs understandable.
Sometimes the most valuable recommendation is to remove something you thought you needed.
Before you pay, get these answers in writing
You do not need a 40-page contract to make a small website project safe. But important assumptions should not live only in a phone call.
At minimum, make sure the written proposal or agreement makes the scope, price, exclusions, ownership/access arrangement, recurring costs, revision expectations, launch responsibilities and post-launch relationship understandable.
Then judge the designer on more than the portfolio.
A beautiful portfolio tells you they can produce attractive work. These questions tell you whether they understand ownership, risk, operations and what happens to your business after the screenshots are finished.
If you are currently comparing designers or have a proposal you are unsure about, send me what you are trying to build. I can tell you what I think the project actually needs before you commit to the wrong scope.
