Frequently asked questions

We compare your requirements against what licensed products already do well. If a product covers your process with reasonable configuration, that is usually the better commercial decision and we will say so. Custom development earns its cost when your process is genuinely distinct, when integration requirements exceed what a product allows, or when licensing costs grow faster than the business does.

Yes. We begin with an assessment of the existing code, data and infrastructure, then report honestly on its condition — including when the finding is that continuing costs more than rebuilding. You receive that assessment as a deliverable whether or not you proceed with us.

Functional testing against the agreed requirements is always included, alongside cross-device, accessibility and performance checks. Automated test coverage is scoped to the parts of the system where a defect would be most costly, since testing everything to the same depth is rarely a good use of budget.

Yes, when a content management layer is in scope. Pages, services, articles, FAQs and SEO fields become editable in both languages, and we train your team before handover. If you would rather not manage content at all, we can handle updates under a support arrangement instead.

Mobile is the primary case, not an adaptation. Each section is designed deliberately for small screens rather than left to stack automatically, and layouts are verified on real devices across the supported range in both Arabic and English.

We can arrange and manage it, but we recommend the hosting account stays in your company’s name with administrative access granted to us. That keeps ownership, billing and the ability to change supplier with you.

Not necessarily. Launching on one platform first is often sensible when budget is limited or the concept still needs validation, and cross-platform development makes adding the second far cheaper later. The right call depends on where your users actually are — which we check rather than assume.

We handle submission, but under developer accounts registered to your company. That keeps the app listing, its reviews and its ownership with you rather than with a supplier.

Rejections are a normal part of publishing, most often over privacy declarations, metadata or account-deletion requirements. We handle the review correspondence and resubmit. Addressing store feedback for the initial release is part of the engagement, not a chargeable extra.

A small number of genuinely different directions, each with the reasoning behind it. Presenting many superficial variations tends to turn a strategic decision into a preference poll, which produces weaker outcomes. The number and the revision rounds are agreed in the proposal.

Yes. Editable source files and full usage rights transfer to you on completion. Licensed typefaces are the exception — those are licensed from their foundries directly to your company, and we tell you exactly which licences are required.

Yes, and we treat them as separate design problems. Arabic typography has different optical weight, line height and alignment needs, and a right-to-left layout is designed independently rather than produced by mirroring the English one.

No. Outcomes depend on your market, pricing, competition and follow-up speed — none of which a supplier controls. We commit to a defined scope, measurement that shows exactly what the spend produced, and a clear recommendation each reporting cycle.

Your company. We work inside accounts registered to you with manager access granted to our team, so campaign history and audience data remain yours if the engagement ends.

In business terms: spend, enquiries generated, cost per enquiry, and which channels produced them — followed by what we intend to change next period and why. Reach and impressions appear as context, never as the headline result.

That depends on scope, integration complexity and how quickly decisions and content arrive from your side — which is more often the constraint than development capacity. We provide a phased schedule with the estimate after requirements analysis, and we state the assumptions each date depends on.

Almost always one of three things: content and approvals arriving late, scope expanding mid-project, or a third party being slower than expected. We manage the first two through scheduled review points and a written change procedure, and flag third-party dependencies as risks at planning stage.

Because a meaningful figure requires knowing the scope. The same brief can differ several-fold in cost depending on integrations, data migration, content volume and support expectations. Publishing a headline number would mislead on both sides, so we quote after understanding the requirement.

You submit a quote request or contact us, we discuss the requirement and clarify what is unclear, then issue a written proposal setting out scope, phases, deliverables, timeline, price and the assumptions the price depends on. Anything excluded is listed explicitly.

Payments are tied to phases and delivered milestones, with the schedule set out in the project agreement before work starts. The specific terms depend on project size and duration.

Your company, on final settlement. Source code, design source files and all data transfer to you, and the specific terms are written into the project agreement before work begins. Third-party licences — fonts, plugins, platform subscriptions — are held in your name and identified in the proposal.

The handover package is built for that from the start: code in your repository, documented data model and API, environment configuration and deployment instructions. A competent team should be able to take over without contacting us.

A defect-correction period is included with delivery — issues where the system does not behave as specified are fixed at no charge. Ongoing maintenance covering security updates, monitoring, small changes and enhancements is a separate arrangement, scoped to the coverage you actually need.

They are set in the support agreement and priced by coverage level, since round-the-clock availability costs considerably more than business-hours cover. We recommend matching the level to what downtime actually costs your business rather than defaulting to the highest tier.

Yes, after an assessment. We need to understand the code, infrastructure and access position before committing to response times, and occasionally the assessment concludes that stabilisation work is required before a support arrangement is realistic.

As two independent designs, not one design mirrored. Arabic layouts are built and tested for right-to-left separately, typography is selected so Arabic and Latin sit together at matched optical weight, and copy is written natively in each language. Both directions are tested on real devices before launch.

Yes. Projects are built with a translation layer separate from the interface code, so adding a language is a content and review exercise rather than a rebuild. Adding another right-to-left language is straightforward; a language with different layout conventions may need some design review.

We write it. Direct translation of marketing copy produces text that is grammatically correct and commercially flat. We compose each language version to carry the same meaning in phrasing that reads naturally to its audience, then review both in layout together.