Web Development Is the Half That Outlives the Design
A visual concept is finished the day it is approved. The build underneath it has to survive editors adding content badly, browsers changing, security advisories arriving, campaigns demanding new page types and, eventually, a different agency taking over. That is why the questions worth asking a web development company are not about style. They are about the content model, the hosting, the ownership of accounts, the documentation and the exit.
If the creative direction is already settled, say so and buy web development on its own. If it is not, treat concept and build as two priced stages so you are not forced to accept whichever visual language the development team happens to prefer. Plenty of good outcomes come from one firm doing both, but only when both were scoped rather than bundled.
Register the Domain, the DNS and the Hosting in Your Own Name
Ownership of the technical accounts is the difference between changing supplier in a week and negotiating for months. The domain registration should list your company as registrant with an email address on a mailbox you control, not the agency's. The DNS zone, the hosting account, the content delivery and certificate provider, the analytics property and the search console verification should all be yours, with the supplier invited in as a user.
Check this at the start, because retrofitting it is unpleasant. Ask for a written list of every account the site depends on, who holds the administrative role on each, and what the monthly cost is when billed directly rather than resold. Where a country level domain is involved, make sure the registrant details match your licensed entity so you can prove control if a dispute ever arises.
Pick the Platform for the Team That Will Run It
The technology argument web development suppliers enjoy having is rarely the one that matters. What matters is who will publish a page next year and how much help they will need. A conventional content management system with a familiar editor is a reasonable choice when marketing runs the site with occasional support. A headless setup with a separate front end is stronger when the same content feeds several channels, and it requires more discipline and a developer on call.
Ask candidates to demonstrate the editing experience on a real page rather than describe it, and ask what happens when someone wants a layout the templates do not have. A build where every new section requires a developer will quietly become a bottleneck. A build where editors can assemble anything will quietly become inconsistent. Where the site is a storefront rather than a brochure, weigh the same question against the tooling ecommerce specialists work with daily.
A Bilingual Site Is a Structural Requirement, Not a Plugin
Arabic and English coexisting properly affects the information architecture, not just the stylesheet. Each language needs its own addressable pages so they can be linked and indexed separately, with correct language annotations connecting the pairs. The layout mirrors, which means navigation, breadcrumbs, form fields, carousels and icon direction all flip, and components built with hard coded directions break. Typography needs a licensed Arabic family with matching weights, and line breaking behaves differently.
The editorial side needs a plan too. Decide whether every page exists in both languages or only a defined set, decide what a visitor sees when a translation is missing, and decide who approves the Arabic. Sites that machine translate at render time read badly and tend to perform poorly in search. Build the workflow so that a human writes each version and both are publishable independently.
Hosting and Form Data Carry Obligations in Dubai
Every enquiry form, chat widget, booking step and newsletter signup collects personal data, and that data lands somewhere. Federal data protection rules, and the separate regimes that apply to entities licensed inside the financial free zones, govern consent, retention, access requests and transfers abroad. If you serve European visitors you inherit obligations there as well, which is what makes a cookie banner a functional requirement rather than decoration.
Ask where the site is hosted and where the form submissions are stored, since those are often two different places once a customer relationship system or a third party form tool is involved. Require a documented list of the external scripts the site loads and what each one collects, keep retention and deletion in scope, and confirm that backups are taken, stored somewhere else and actually restorable. Ask the supplier to demonstrate a restore rather than describe the schedule.
Put Performance Targets in the Contract
Speed is a build decision that gets undone by everything added afterwards. Agree measurable targets on real mobile connections for the templates that matter most, and require the site to be tested against them before the final payment, not after the campaign traffic arrives. Image handling, font loading strategy, script bundling and caching should all be described in the proposal.
The usual cause of a fast site becoming slow is tag sprawl: analytics, chat, remarketing pixels, heat mapping and testing tools added one at a time by different teams. Agree who owns the tag container, require a review before anything new goes in, and have the supplier state the performance budget so there is a reference point when someone asks why the homepage got heavy.
Third Party Tools Are Where Most Websites Actually Break
The parts of a site that fail after launch are usually not the pages. They are the booking calendar, the payment step, the customer relationship system the enquiry form writes into, the review widget, the job board, the chat tool and the map. Each is a separate vendor with its own contract, its own outage history and its own habit of changing an interface without telling anyone who built against it.
List those dependencies in the brief and ask who holds each account and who pays the licence, because a tool bought on the agency's subscription becomes a hostage at handover. Ask what the site does when one of them is unavailable: a payment step that fails silently loses orders you will never hear about, while a form that queues a submission and alerts someone does not. Agree monitoring and an alert route so that a broken integration is noticed by your supplier rather than reported by a customer.
Accessibility Is Code, Not a Statement
Accessible markup is cheap while the templates are being written and expensive afterwards, which is the entire argument for putting it in the specification. Semantic structure, keyboard operability, visible focus, sufficient contrast, labelled form controls, captions on video and sensible heading order cover most of the practical requirement, and the recognised international guideline set gives you a testable standard to name in the contract.
Ask which level the supplier will build to, how it will be tested, and whether a keyboard and screen reader pass is included in acceptance. Check that the Arabic pages get the same treatment, since assistive technology depends on correct language and direction attributes being present. This work also improves the experience for everyone using a phone in bright sunlight, which is most of your audience here.
Migrate Without Losing the Traffic You Have
Relaunches lose rankings when addresses change and nobody maps the old ones to the new. Before anything goes live, export the existing address list, agree a redirect map for every page that has links or traffic, keep the staging environment closed to search engines, and check that the new templates carry the structured markup and metadata the old site had. Analytics and conversion tracking should be verified on the new build before the switch, not rediscovered a week later. Keep the old site reachable in a staging copy for a few weeks so that anything missed can be checked against the original rather than reconstructed from memory.
Ask for a post launch check at day one and again a fortnight in, with error reports and traffic compared against the previous site. A supplier that treats launch day as the end of its obligation is one you will be calling with problems it has no incentive to fix.
What Web Development Handover and Comparison Should Look Like
Complete handover means the repository with its history, the deployment process, environment configuration, editor documentation, the design source files and administrative access to every account. Prove it by having someone outside the project deploy a small change from the documentation while the original team is still available to answer questions.
When you tender, send every candidate the same page inventory, language requirement, integration list, performance target, accessibility level and handover checklist, and ask for effort broken down by phase. Where the visual identity is the gap rather than the web development, bring in web design teams, and where the site's job is to win search traffic, talk to search specialists before the structure is locked rather than after. Verified profiles and client feedback for web development companies sit on Edvido, and one brief sent to a shortlist produces proposals you can lay side by side.