Why the questions matter more than the pitch

Most proposals look similar at first glance: a nice portfolio, a timeline and a price. The differences appear later, when a feature is missing, the site is slow on a phone, or you discover you cannot access your own hosting. Asking the right questions upfront is the simplest way to avoid that.

These are the questions I would ask if I were hiring someone, and the ones I am happy to answer myself. Use them in a first call or send them by email; a good developer will give you clear, specific answers rather than vague reassurance.

Questions 1–3: experience and proof

1. Can I see live websites you built, not just screenshots? Mockups can hide a lot. A live site lets you check speed, mobile behaviour, forms and the quality of details. Open a few on your phone and try to use them as a real customer would.

2. Which projects are closest to mine, and what was your role? Building a portfolio site is very different from building a booking flow or a multi-language platform. Ask specifically what they designed, what they developed and what was handled by others.

3. Who will actually do the work? Some providers subcontract parts of a project. That is not necessarily a problem, but you should know who designs, who codes and who you talk to when something needs fixing. Ask whether that person stays the same throughout the project, including after launch.

Questions 4–6: process and communication

4. What does your process look like, step by step? A clear process usually includes discovery, a written scope, design, development, testing and launch. If the answer is “send me your logo and I’ll start”, expect surprises along the way.

5. How will we communicate, and how often? Agree on channels, response times and checkpoints. Regular demos of work in progress help you correct direction early, when changes are still cheap. It also helps to keep one shared place for decisions, so nothing gets lost in scattered messages.

6. How are changes and extra requests handled? Every project evolves. Ask how many revision rounds are included, how new requests are estimated, and how the scope is updated in writing so nobody is caught off guard. A precise answer usually signals someone who has managed real projects.

Questions 7–9: ownership and technology

7. Will I own the domain, the hosting account, the code and the content? The domain should be registered in your name or your company’s name. You should receive admin access and, for custom builds, the source code. This protects you if you ever change provider.

8. Why this technology for my project? WordPress, a custom framework or a headless setup can all be valid. A good developer explains the choice in terms of your needs, budget and team, not just personal preference. Ask what it means for maintenance, and whether another developer could take over easily.

9. How do you handle Arabic and multilingual content? For a Moroccan audience, this is essential. Ask to see an Arabic, right-to-left version of a past project, and how each language gets its own URLs and SEO metadata. Check that forms, numbers and mixed Arabic and Latin text display correctly.

Questions 10–12: quality, visibility and support

10. How do you make sure the site is fast and works well on mobile? Many visitors will discover you on a phone, sometimes on a slow connection. Ask how images, fonts and scripts are optimised, and how the site is tested on real devices.

11. What SEO and analytics work is included? Technical foundations such as clean structure, metadata, a sitemap and structured data should be part of a good build. Be wary of anyone who guarantees a ranking; nobody controls Google. Ask which analytics will be set up, so you can see where visitors come from.

12. What happens after launch? Clarify maintenance, security updates, backups, bug fixes and how quickly issues are handled. Ask whether training is included so your team can update content independently, and whether there is a warranty period for fixing defects found after delivery.

Red flags during the first conversation

The first exchange tells you a lot. Pay attention to whether the developer asks about your business, your customers and your goals before talking about design or technology. Someone who quotes immediately, without understanding what the site must achieve, is usually guessing, and guesses tend to become extra costs later.

Also watch for pressure and vagueness. A short deadline to accept an offer, reluctance to put commitments in writing, or answers that avoid the question of ownership are all reasons to slow down. A professional will be comfortable with your questions, even the uncomfortable ones.

  • A price before any question about your goals
  • No written proposal or contract
  • Pressure to decide quickly
  • Vague answers about ownership and access
  • Guaranteed rankings or results
  • No live work you can test yourself

How to compare the answers

Once you have answers from two or three developers, compare them on clarity and completeness, not only on price. A slightly higher quote with a precise scope, ownership guarantees and real support is often cheaper over the life of the site than an offer that leaves important points open.

Trust also matters. You will work closely with this person for weeks or months, so pay attention to how they listen, whether they challenge assumptions constructively, and whether they explain technical topics in plain language. A good first conversation is often a good sign for the project itself.

  • Clear written scope and deliverables
  • Live, testable work similar to your project
  • Ownership of domain, hosting and code in your name
  • Real Arabic RTL experience if you need it
  • Concrete answers on speed, SEO and security
  • Defined support and maintenance after launch

FAQ

Should I hire a freelancer or an agency in Morocco?+

Both can work well. A freelancer often offers direct communication and a single point of responsibility, while an agency can bring a larger team for bigger scopes. What matters most is relevant experience, a clear process and written commitments on ownership and support.

Is it a problem if the developer works remotely?+

Not if communication is organised. Many projects run smoothly with video calls, shared documents and regular demos. Agree on time zones, response times and checkpoints from the start, and make sure you can always reach the person responsible.

What should a web development proposal include?+

At minimum: the goals, the list of pages and features, what you provide versus what the developer provides, the timeline, revision rounds, ownership of domain and code, what happens after launch, and how extra requests are handled.

How long does it take to build a website?+

It depends on scope, content readiness and how quickly decisions are made. A simple showcase site moves faster than a multilingual platform with integrations. Ask for a timeline broken into phases, and note which steps depend on you, such as providing content or approving designs.