Hurghada has no shortage of people who will build you a website. Freelancers, small studios, hotel IT staff moonlighting after hours, international agencies working remotely, and a handful of engineering teams all send proposals that look similar on paper: a page count, a price, a delivery date and a list of buzzwords. The proposals are not similar in what happens after launch. The difference shows up twelve months later, when you discover that you do not control your own domain, that the Arabic version breaks on a phone, that nobody can explain why bookings stopped arriving, or that every small change costs a new invoice.
This guide gives you ten questions to ask before you sign. They are written for hotel owners, real estate developers, dive centres, restaurants, clinics and corporate service firms in Hurghada and across the Red Sea, but they work anywhere. Each question explains what a good answer looks like, what a weak answer sounds like, and what to put in writing. Use them in a meeting, send them in an email, or paste them into a tender document. A supplier who answers all ten clearly is almost always a safer choice than one who is cheaper and vague.
Why local comparison is harder than it looks
A website for a Red Sea business has requirements that a generic template rarely meets. Your visitors arrive in several languages, often from mobile networks while travelling. Your revenue depends on enquiries, bookings or calls rather than page views. Your competitors include international platforms with large budgets. And your site has to stay online, secure and fast through high season, when a failure costs the most.
Price alone hides all of this. Two quotes of the same amount can describe a template with your logo on it, or a properly engineered site with a structure built around your market. For a sense of what drives cost, read our website design cost guide before you compare quotes. Then use the questions below to find out what each quote actually contains.
Question 1: Who will own the domain, hosting, code and content when the project ends?
This is the most important question and the one most buyers skip. Ask for a plain statement of ownership for five items: the domain name, the hosting account, the source code or theme, the content and design files, and the third-party accounts such as analytics, Search Console, Google Business Profile, email and payment gateways.
Google recommends using separate URLs for different language versions and correctly implementing hreflang so search engines can serve the right version to the right audience. See the Google Search Central guide to localized and multilingual pages.
A good answer is that all of them are registered in your company name, with you as the administrator, and that the supplier is added as a user. The supplier may keep ownership of reusable framework code, which is normal, but you should receive a licence to run your site on it indefinitely. A weak answer is that the agency manages everything on your behalf for convenience. That convenience becomes leverage the day you want to change supplier.
Put it in the contract: domain registered to you, hosting account in your name or full credentials handed over at launch, repository access or a code handover, and a written statement that you can leave without a release fee. If the supplier insists on hosting, ask what the monthly cost is, what it includes, and how you would export a full copy of the site and the database if you decided to leave. Our article on hosting in Egypt or abroad explains the trade-offs you should be discussing at this point.
Question 2: Is the site designed for every language, or translated at the end?
Most Hurghada businesses need Arabic and English, and many also need German, Russian, Polish or Czech. Ask how languages are handled in the structure of the site, not just in the text. A good supplier describes separate URLs for each language, a language switcher that sends the visitor to the equivalent page rather than the homepage, correct hreflang tags, right-to-left layout that is tested rather than mirrored by a plugin, and fonts that render Arabic properly.
Ask who writes and reviews each language. Machine translation pasted into a template is easy to spot, and it damages trust with Arabic and German readers in particular. Ask whether the booking form, confirmation emails, error messages and legal pages are translated too, since those are where visitors decide whether to complete a purchase.
Weak answers sound like this: we install a translation plugin and it translates automatically. That can be a useful starting tool, but without review and proper structure it produces pages that search engines index poorly and customers distrust. For the technical detail, see our guide to multilingual SEO for Red Sea tourism sites.
Question 3: How will the site behave on a phone with a weak connection?
Most of your visitors will open your site on a phone, often on mobile data in a hotel lobby, a marina or a taxi. Ask the supplier to show you a site they built, opened on a mid-range Android phone, not on a developer laptop over office fibre. Watch how long the first screen takes to appear, whether text jumps around while images load, and whether the menu and buttons respond immediately.
A good supplier talks about image formats and sizes, font loading, caching, a content delivery network, limiting third-party scripts and testing on real devices. They can name the metrics Google publishes, Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, and they can tell you what they would do if one of them fails after launch. A weak supplier says the site will be fast because it is responsive. Responsive means the layout adapts; it says nothing about speed.
Ask for the target in writing, for example that the key pages pass the Core Web Vitals assessment in field data within a stated period after launch. Be careful with promises of a perfect lab score, because lab tools simulate one device and one network. If speed matters to you, which it should, read about our page speed optimisation approach and compare it with what your candidate proposes.
Question 4: How is performance measured, and who is responsible when it slips?
A website is not finished at launch; it is exposed to plugin updates, new images, new tracking scripts and a growing database. Ask what the supplier measures after launch and how often. The sensible baseline is a monthly check of Core Web Vitals in Search Console, uptime monitoring with alerts, and a review of errors in the server log.
Ask what happens when a metric degrades. Is investigation included in a maintenance plan, or billed by the hour? Who decides whether to remove a slow third-party widget? A good supplier has a clear process and does not treat every problem as a new project. Compare the plan against our notes on website maintenance cost in Egypt so you know which tasks are normally covered and which are not.
Question 5: What SEO work is built into the project, and what is left for later?
Search engine optimisation is often sold as a separate monthly service, but a large part of it is engineering done during the build. If it is not done then, it becomes expensive to fix afterwards. Ask the supplier which of these they do as part of the design and development phase:
- A keyword and page map: which page targets which search intent, so you do not build five pages competing for the same query.
- Clean URLs, one H1 per page, a logical heading structure and unique title tags and meta descriptions.
- An XML sitemap, a correct robots.txt, canonical tags and a plan for noindex on thin or duplicate pages.
- Structured data suited to your business, such as hotel, local business, product, FAQ or event markup, validated against Google documentation.
- Redirects from every old URL if you already have a site.
- Search Console and analytics set up before launch, with verified ownership in your account.
A weak answer is that SEO starts after launch. If you are replacing an existing website, the risk is real: a rebuild with changed URLs and no redirect plan can erase years of ranking in a week. Ask to see their migration checklist, and compare it with ours in moving your website without losing Google rankings. If you are unsure whether to rebuild at all, our piece on redesign or rebuild lists the signs to look for.
Question 6: How do enquiries and bookings reach you, and how will you know what works?
A business website exists to produce a result: a booking, a call, a WhatsApp message, a form submission, a brochure download. Ask the supplier to describe the full path from a visitor landing on a page to you receiving the lead. Where does the form data go? Is it stored in the database as well as emailed, so a spam filter cannot lose it? Are the confirmation emails delivered reliably, with proper domain authentication? What happens if the booking engine or payment gateway is unavailable?
Then ask about measurement. A competent supplier configures conversion tracking for form submissions, click-to-call, WhatsApp clicks and completed bookings, and sets up reports you can read without a developer. If the answer is that they will install the analytics code, probe further: which events, named how, and tested by whom?
If you take bookings, ask whether the supplier proposes a plugin, a hosted engine or a custom system, and why. The trade-offs are covered in our guide to booking system cost in Egypt. For hotels, ask how the site reduces dependence on commission-heavy channels; the maths is in our article on direct booking versus Booking.com.
Question 7: What platform will you use, and why is it right for this project?
The honest answer is rarely a single brand name. A brochure site that your team updates weekly may suit WordPress with a carefully chosen set of blocks. A system with roles, approvals, integrations and unusual business rules may need a custom Laravel application. Many projects work best as a hybrid. What matters is that the supplier can explain the reasoning in terms of your needs, and can say what they would not recommend.
Ask these follow-up questions. Who will edit content, and how much training is included? How many plugins will be installed, and who updates them? What happens to the design if a plugin is abandoned? Is a page builder used, and what is its effect on speed? Can the site be extended later without a rebuild? Our comparison of WordPress and Laravel for a business website or system sets out the decision criteria we use, and you can apply the same criteria to any proposal.
Be wary of a supplier who recommends one platform for every client. Equally, be wary of anyone proposing a fully custom build for a five-page brochure, which spends your budget on engineering you do not need.
Question 8: How is the site secured, backed up and kept updated?
Hotels, clinics and developers hold customer details, and a defaced or infected site damages reputation immediately. Ask for specifics: automatic backups with a stated frequency and retention, stored away from the web server; a restore procedure that has actually been tested; two-factor authentication on administrator accounts; limits on login attempts; a web application firewall or equivalent filtering; and a patching routine for the core, themes and plugins.
Ask what the response is if the site is compromised on a Friday night. Who is contacted, how fast do they respond, and what is the first action? A strong supplier has a short runbook; we published ours as what to do in the first 60 minutes. A weak supplier says that does not happen, which is the least reassuring answer available.
Also ask who is responsible for personal data handling. Contact forms, booking records and analytics all touch Egypt’s personal data protection regime, so the supplier should be able to describe, in general terms, how data is stored, who can access it, and how it can be deleted on request. You should still take legal advice for your own obligations.
Question 9: What exactly is in the scope, and how are changes handled?
Disputes in web projects usually start with an unclear scope. Ask for a written scope that lists page templates rather than only page counts, features, integrations, languages, content responsibilities, the number of design revision rounds, and the browsers and devices that will be tested. Clarify who supplies text and photography, and what happens if content arrives late, since delays on the client side are the most common reason projects overrun.
Then ask how changes are priced. A reasonable arrangement defines a change request process: you describe the change, the supplier estimates effort and impact on the schedule, and nothing is billed until you approve. Look for a payment schedule tied to milestones rather than dates, for example a deposit, a payment after approved design, a payment at staging delivery and a final payment after launch and a defined acceptance period. Avoid paying the whole fee up front, and avoid arrangements in which the final payment is due before you can test.
Finally, ask what warranty applies after launch. Thirty days of free bug fixing is common; the important point is that the supplier defines what counts as a bug and what counts as a new request.
Question 10: Can I see live sites and speak to the clients behind them?
Screenshots in a portfolio prove very little. Ask for live URLs of comparable projects, in your industry or at a similar scale, and open them on your own phone. Check the speed, test the language switcher, submit the form, look at the source for the supplier’s credit link and see whether the site still looks maintained.
Then ask for two references you can call. Good questions for a reference are: did the project finish on the date agreed, how were problems handled, what did you pay beyond the original quote, and would you hire them again? Ask whether the person who presented the proposal is the person who will do the work, and who your day-to-day contact will be. Check that the team in the proposal actually exists in Egypt, or says clearly where each member is based and when they are available, because response time in a crisis depends on it.
If a supplier cannot show live work, or the live work is all templates with similar structure, you are being asked to fund their learning curve.
A simple scoring sheet for comparing proposals
Once you have written answers, score each supplier from zero to three on each question: zero for no answer, one for a vague answer, two for a clear answer, three for a clear answer backed by evidence such as a live site, a document or a reference. Add up the total out of thirty and compare it with the price. If the highest scorer is also the most expensive, ask what part of the difference buys you the points on questions 1, 5, 6 and 8, because those are the ones that cost the most to fix later.
You can weight the questions to fit your business. A hotel may weight questions 2, 6 and 8 most heavily because of multilingual traffic, bookings and guest data. A real estate developer may weight 2, 5 and 10 because of foreign buyers and the importance of search visibility. A dive centre may weight 3 and 6 because mobile visitors and instant enquiries drive its revenue.
Red flags that deserve a pause
- The price is given as a single number with no scope document.
- The supplier owns the domain or refuses to give administrator access to your accounts.
- The design is shown as finished before anyone has asked who your customers are.
- The proposal contains no mention of redirects, tracking, security or speed.
- Every portfolio site uses the same layout and the same plugins.
- Results are promised in guaranteed ranking positions or a guaranteed number of visitors.
- Support is available only by a personal phone number with no agreed response time.
- The contract says nothing about what happens if either side wants to end the relationship.
Clauses to ask for in the contract
Whatever supplier you choose, make sure the contract states the following in plain language: the scope and deliverables, the milestone payment schedule, the owner of each asset listed in question one, the handover package at launch including credentials and documentation, the post-launch warranty, the service levels of any maintenance plan, confidentiality of your data, the change request process, and an exit clause that lets you leave with a full copy of your site. A short contract that covers these points is better than a long one that does not.
If you want to see how an engineering-led team answers these ten questions, send them to us and compare our written replies with any other proposal on your desk. A supplier who welcomes the questions is usually the one who has already built the answers into the project.