Dubai · How we deliver
Our web development process — every phase ends in something you can open.
Six phases from discovery to launch, each with a named input, a named output and a date. You get a written scope before anything is built, a staging URL you can open from week three, and every account and repository already in your name at handover.
The six phases
Six phases, and what each one actually needs.
This is how we build websites in Dubai, phase by phase: what a phase needs before it can start, what you get back at the end of it, how long it runs on a typical six-week site and who is in the room. The website design process sits inside phases two to four — and the build starts before it finishes.
01
Discover
Requirements, constraints, competitors and the systems you already run.
- What it needs to start
- A brief, however rough — what the site has to do, and what would count as it working.
- Access to whatever exists already: the current site, its analytics, and Search Console if it has one.
- The list of systems the site has to talk to — CRM, ERP, payment gateway, booking or stock.
- Anything already fixed: a launch date, a tender deadline, a budget ceiling.
- A named decision-maker, and one workshop in their diary.
- What you get back
- Scope document
- Everything agreed as explicitly out of scope, written down beside what is in it
- An indicative price, with the assumptions it depends on named rather than buried
- A short risk list — the two or three things that could realistically move the date
- How long
Week 1
The whole of the first week on a six-week site. Larger platforms extend the build and launch phases rather than this one.
- Who is involved
- Us The engineer who would build it and the designer who would draw it, in the room from the first meeting — not a sales team who hand the notes over afterwards.
- You Whoever can approve scope and budget, plus whoever actually knows how the business runs. Those are often not the same person, and both are needed here rather than later.
02
Architect
Sitemap, URL structure, data model and the technical approach, agreed before design.
- What it needs to start
- The signed scope from discovery.
- The existing URL list, if this is a redesign — every page worth keeping the ranking of.
- A decision on Arabic and RTL, because it changes the architecture rather than the stylesheet.
- API documentation or sandbox access for anything being integrated.
- What you get back
- Architecture + sitemap
- The URL structure, and the redirect map if an old site is being replaced
- The content model — the fields an editor will actually fill in, decided before anyone draws a box for them
- The page-by-page content brief, issued now rather than in week five
- The technical approach, with the stack chosen and the reason written down
- How long
Week 1 into week 2
Starts inside discovery and lands by the middle of week two, so the content brief goes out while there is still time to act on it.
- Who is involved
- Us The engineer, with the designer on the sitemap and the navigation model — structure is a design decision as much as a technical one.
- You Whoever owns the content, and whoever administers the systems the site has to connect to.
03
Design
Wireframes, then interface design in Figma, then a clickable prototype.
- What it needs to start
- The approved sitemap and content structure.
- Brand assets — logo in vector, type licences, photography, or a plain statement that none exists yet.
- Real copy for at least the key templates, or the closest sample you have.
- A named approver, and a review slot booked for the end of wireframes and the end of visuals.
- What you get back
- Figma system
- Wireframes for every key template, reviewed and signed off before a single visual decision is made
- A clickable prototype of the journeys that matter
- Design tokens — type scale, spacing, colour with contrast ratios measured rather than assumed
- The Figma file in your account from day one, not at final invoice
- How long
Weeks 2 to 4
Wireframes first, then the interface. Structure is settled before colour, which is where revisions are cheapest.
- Who is involved
- Us The designer, with the engineer reviewing for buildability before anything is signed off — so nothing is approved that quietly costs a fortnight to build.
- You The named approver, and anyone whose opinion will be sought eventually. Far better at the wireframe review than after the visuals exist.
This phase is the whole of our web design practice described from the discipline rather than from the calendar — research, interface design, redesigns and conversion work.
04
Build
Front-end and back-end, in weekly increments on a staging URL you can visit.
- What it needs to start
- Signed-off design for at least the first templates — the rest can follow while those are being built.
- Content in the agreed structure, arriving as it is written rather than in one batch at the end.
- Sandbox credentials and test accounts for every system being connected.
- The hosting decision, and access to it.
- What you get back
- Staging site
- A weekly increment you can open, on the same URL, for the length of the build
- Repository access from the first commit — not a zip file at the end
- The performance budget measured on staging every week, so speed is never a final-week retrofit
- A written update each week: what shipped, what is next, what is waiting on you
- How long
Weeks 3 to 6
Begins while the last templates are still being drawn, which is why design and build overlap on the chart below.
- Who is involved
- Us The engineer who wrote your scope writes the code, with the designer still available for anything the file did not settle.
- You Whoever reviews the weekly increment, and whoever holds the credentials for the systems being connected.
What gets built varies — the web development services run from custom builds and WordPress through to e-commerce and web applications. The phase order above is the same for every one of them; the length of this phase is not.
05
Launch
Redirects, analytics, search console, performance budget and a go-live checklist.
- What it needs to start
- Final content signed off — the last page, not most of them.
- Domain and DNS access, or the person who holds it on a call at the agreed hour.
- Your privacy policy and terms, reviewed by whoever reviews those on your side.
- Live payment credentials, if the site sells — merchant approval sits with the bank or processor, not with either of us.
- A go or no-go decision from the named approver.
- What you get back
- Live site + handover
- The redirect map executed and checked, so the rankings an old site earned survive the new one
- Analytics, Search Console and every hosting account in your name
- A go-live checklist you can read, and the performance budget measured on the live site
- A recorded walkthrough plus editor training, and a README anyone competent can pick the project up from
- How long
Week 6
Content loading and QA run from week five into it, so launch day is a checklist rather than a scramble.
- Who is involved
- Us The engineer who built it, through the checklist and the handover walkthrough.
- You Whoever holds the domain, and whoever will be editing the site next month — the training is for them, not for the person who signed the contract.
06
Evolve
Measured changes after launch, on a care plan or as a follow-on project.
- What it needs to start
- A decision: you run it, or we do. Both are normal, and the handover is identical either way.
- A named person on your side to receive the monthly report and set priorities.
- A list of what you want changed, in the order you want it.
- What you get back
- Monthly reporting
- Updates, security patching, offsite backups and uptime monitoring, on a care plan
- A named engineer who answers when you write, during working hours
- Larger changes quoted as follow-on projects with their own scope and price, rather than billed as open-ended hours
- How long
From week seven, monthly
Cancellable on thirty days' notice. Nothing here locks you in — the alternative is that you run it yourself, with everything already in your accounts.
- Who is involved
- Us A named engineer on the care plan, and the same team for follow-on work.
- You Whoever owns the site day to day and reads the monthly report.
The retained version of this phase is website care — updates, monitoring, speed and hosting, priced monthly. Taking it in-house instead costs you nothing and changes nothing about the handover.
Durations are for a typical fixed-scope marketing site — the six weeks the chart below lays out. Larger platforms extend the build and launch phases rather than the discovery ones. A phase never starts before its inputs exist, which is why the section after the chart is about you rather than about us.
Timeline
What six weeks actually looks like.
A typical fixed-scope marketing site. Larger platforms extend the build and launch phases, not the discovery ones.
DiscoverWeek 1
ArchitectWeek 1 to Week 2
DesignWeek 2 to Week 3
BuildWeek 3 to Week 5
Content & QAWeek 5 to Week 6
LaunchWeek 6
Content is the usual cause of slippage. We start it in week one, not week five.
Your side of it
What we need from you, and what stops without it.
The chart above holds only if these arrive. Every row below is an input that some phase genuinely cannot start without, set out with the week it is needed and the honest consequence of it being late — beginning with content, for the reason the chart has just given.
| What we need | When | What stalls without it |
|---|---|---|
| A named decision-maker | Week 1, before scope is signed | Everything downstream. Reviews queue behind whoever can say yes, and a scope approved by someone without the authority to approve it is not a scope. |
| Page-by-page copy, in the agreed structure | Brief issued week 1 · first draft by the end of week 3 | The design gets approved on placeholder text the real words do not fit, and the build then waits at the very end for copy that was never anybody's first priority. This is the row that moves launch dates. |
| Brand assets — logo in vector, type licences, photography | Week 2, before interface design | Interface design proceeds on stand-ins. A logo that arrives in week five as a JPEG cropped out of a PDF is a redraw, not a swap. |
| Access — hosting, current CMS, analytics, domain registrar | Week 3 for the build · domain confirmed well before week 6 | The migration, and eventually the launch. Not knowing who holds the domain is a five-minute question in week three and an emergency in week six. |
| Sandbox credentials for every system the site talks to | Week 3, at the start of the build | The integration — and if the API turns out not to do what it was assumed to do, that is a scope conversation, which is far better had in week three than in week six. |
| A review slot at the end of each phase | Booked in advance, one per phase | The next phase. Feedback consolidated into one round moves a project; the same points arriving separately over two weeks re-opens work that was already signed off. |
| Legal text — privacy policy, terms, any licence numbers you must display | Week 5, before QA | Go-live. A policy has to match what the site actually collects, so it is a review on your side rather than a paragraph anyone can drop in on launch morning. |
| Payment gateway approval, if you are selling | Started week 1 — approval sits with the bank or processor | Testing checkout end to end. Merchant approval is outside our control and outside yours, so starting it late is the one delay engineering speed cannot recover. |
Scroll the table sideways to read the rest of each row.
None of these dates is padding. Each row is something the next phase cannot start without, which is why they are published here rather than raised as a surprise in week four. If something is going to be late, the useful moment to say so is now — a date can usually be re-planned around a known delay, and rarely around one discovered at the end.
How you see progress
A URL you can open, and a person you can write to.
Progress on a website is either shown or reported, and reported progress is the kind that turns out to be optimistic in week five. Everything below is the first kind.
A staging URL from week three
The build lands in weekly increments on one URL you can open on any device and send to anyone. You watch the site assemble rather than waiting for a reveal, and a problem spotted in week four is a fix rather than a rebuild.
One engineer, scope to launch
The person who wrote your scope is the person who writes the code, so questions do not travel through an account manager to a team you never meet. Replies come within one working day, Monday to Friday.
A written update every week
Once the build starts: what shipped, what is next, and what is waiting on you. In writing, so it is searchable in month six when somebody asks when a decision was taken and why.
Decisions recorded where the work is
Scope is a document before it is a build, and the outputs listed above are what each phase is measured against. A change that expands scope is quoted in writing before it starts, rather than absorbed quietly and invoiced at the end.
Your accounts from day one
Repository, hosting, analytics and the Figma file are registered in your name at the start rather than transferred at the end. There is nothing to hand over because nothing was ever held, and you can look at any of it without asking us.
The performance budget, measured weekly
The budget is agreed before the build and checked on staging as the site grows. If a change would break it, the change gets reworked and not the budget — which is only possible when the measurement happens weekly rather than in the final week.
There is no client portal to learn, and that is a deliberate choice rather than a gap. A portal is somewhere progress gets reported; the staging URL is somewhere progress can be seen. Everything else happens by email and in the review call, both of which you already know how to use.
Questions
Asked before the first phase starts.
Discover, Architect, Design, Build, Launch and Evolve. Each closes with something you can open: a scope document, a sitemap and architecture, a Figma system, a staging site, the live site with its handover, then monthly reporting. The phases overlap on purpose — architecture starts before discovery closes, and the build starts before the last template is drawn — but none of them starts before its own inputs exist.
On a typical six-week fixed-scope marketing site: discovery takes week one, architecture runs into the middle of week two, design runs from week two to week four, the build from week three to week six, and launch lands in week six with content loading and QA from week five. Larger platforms extend the build and launch phases rather than the discovery ones.
Four moments need you specifically: the discovery workshop, the wireframe review, the design sign-off and the go-live decision. Everything between them is a weekly written update that mostly needs reading. What does need protecting is the review slot. Feedback consolidated into one round from everyone who has an opinion moves a project; the same points arriving separately over two weeks re-opens work already signed off.
We tell you as soon as it is visible, and you choose: move the date, or launch a smaller page set and add the rest afterwards. What we will not do is fill the site with placeholder text and call it live. The page-by-page content brief is issued in week one for exactly this reason — content is the usual cause of slippage, and it is the one input that engineering speed cannot make up.
Yes, and where the change lands is what decides the cost. A structural change during wireframes costs an afternoon; the same change after templates are built costs the build. Anything inside the agreed scope is simply the work. Anything that expands it is quoted in writing before it starts, rather than absorbed and invoiced as a surprise at the end.
From week three, on a staging URL you can open on any device and send to anyone — a colleague, a stakeholder, your own developer. Increments land there weekly, so you see the site assemble rather than waiting for a reveal. Staging is kept out of search results, so an unfinished page cannot turn up in Google while you are still deciding about it.
The engineer who scoped it. The person who wrote your scope is the person who builds the site, so there is no account manager relaying questions to a team you never meet, and nothing is quietly passed to an offshore studio. Replies come within one working day, Monday to Friday — the office runs Monday – Friday, 9:00 – 18:00 GST.
Launch is a checklist rather than an event: redirects executed and checked, analytics and Search Console in your accounts, the performance budget measured on the live site, and a walkthrough with whoever will edit it. Afterwards you either run it yourself — you have the repository, the README and every account — or move onto a care plan with a named engineer and thirty days' notice to cancel.
Ready to build something that lasts?
Tell us what you need. You will get a scoped response with an indicative price — from an engineer, not a salesperson.