Custom software when no product fits how you work.

Buy the product unless the process is genuinely yours. Custom earns its cost when the sequence you run is the thing clients pay for, when the licence or the obligations shape it in a way no vendor models, or when the integration between systems is itself the product. Everything else is usually a product plus a short build, which costs a fraction and ships in weeks. Webzenia writes the shortlist of products first, and the engagement stops there when one of them wins.

You own all of it, and the assignment is written into the agreement rather than implied by it. The repository sits in your organisation from the first commit, the cloud tenancy and the deployment pipeline are in your entity, and handover is a walkthrough of accounts you already hold. Documentation is written for a developer who has never seen the code. We ask somebody on your side to read it and ask questions before the phase is closed, because a document nobody has opened is not a handover.

It is priced per phase after the process is mapped, and three things move the figure more than anything else. The first is how many systems it has to talk to, because integration is where estimates go wrong. The second is how many distinct roles use it, since each one is a separate set of screens and permissions. The third is whether the records it produces have to satisfy an obligation, which turns a form into a schema. You get a fixed price for phase one after the mapping, rather than a range before it.

The first working version is weeks rather than months, because the build runs in short cycles with something usable at the end of each. A full replacement of an operational system takes longer and is delivered in stages, so the old one retires piece by piece rather than on a single date. What stretches a timeline is almost never the code. It is a decision waiting on somebody, which is why the phase plan names who owns each one before the phase starts.

It is part of the build when it is scoped that way, and a second project when it is not. Bilingual software carries three costs a translation file does not: the layout has to work right to left, names and addresses have to store both scripts, and reports have to print in the language the reader needs. That is a decision taken at the start, because retrofitting right to left through a finished interface costs more than building it in. Webzenia states the Arabic scope in the same breath as the English one, or says plainly that the engagement does not include it.

Yes, and it is an architecture question rather than a legal footnote. A free zone entity generally cannot sell direct to mainland customers without a distributor, a mainland branch, or a permit under Dubai Executive Council Resolution No. 11 of 2025, so the customer records, the invoicing entity and the permitted activity list all have consequences in the data model. The tax posture follows the same logic: corporate tax is 9% above AED 375,000 of taxable income, with a 0% rate available to a qualifying free zone person on qualifying income. Which entity issued a record is therefore a field, not a convention. We read the licence before the first screen is drawn, and the e-invoicing consequences by revenue band are set out on software and automation in Dubai.

The software keeps running, because it was never running on our accounts. The repository is in your organisation, the cloud tenancy is billed to your entity, and the deployment pipeline is a file inside that repository rather than a setting in a console we hold. Documentation is written so a developer who has never met us can take it on. We run a handover session with whoever picks it up, and we do that whether the ending was planned or not.