Activity CZ 227
How to Start a Communication Equipment Software Design Business in Dubai
Software written for communication equipment ships inside hardware, so a defect cannot be pushed to a server. What this design line covers, who signs for it, and who ends up owning the code.
ConsultZone licensing desk
- Activity code
- CZ 227
- Category
- Information Technology
- Reviewed
- Read
- 7 min
Listen instead
51 seconds
An audio summary of this guide.
Topic summary
How to Start a Communication Equipment Software Design Business in Dubai
A defect report arrives naming a build that shipped eight months ago. The software is not on a server anybody controls; it is inside two thousand devices mounted in racks and cabinets belonging to customers who have never heard of the firm that wrote it. Fixing it means a tested release, a staged update campaign, an engineer somewhere with a console cable, and a customer who has to be persuaded to touch equipment that is currently working. That is the whole difference between this trade and the rest of software, and everything else about the business follows from it.
Computer Systems & Communication Equipment Software Design, as the line reads in the catalogue, is software written for machines rather than for people. Nobody logs into it. Its users are other pieces of equipment, its correctness is judged by a protocol specification, and its release date belongs to a hardware programme that the software house does not run.
The software runs on equipment, not on a screen
What the line covers is the design and development of software that makes computer systems and communication equipment work: the firmware and board support that brings a device up, drivers for the chips on it, the protocol and signalling stacks that let it talk to other equipment, the management and provisioning interfaces an operator configures it through, the diagnostic and test harnesses the manufacturer needs on the production line, and the build and release tooling that turns all of it into something shippable.
Two characteristics separate it from ordinary application work and both are commercial rather than technical. The first is that it cannot be developed without the hardware. A protocol stack is only correct against real silicon on a real board, and until boards exist the work is a simulation of itself. The second is that correctness is defined elsewhere. An application is right when the customer is satisfied; a protocol implementation is right when it interoperates with equipment made by somebody who was never in the room, which means conformance and interoperability testing is part of the deliverable rather than an afterthought.
What it givesWhat it costs
- Fixed-scope development for one equipment makerA named reference and a milestone plan you can finance againstThe customer owns the result, so nothing accumulates between projects
- An embedded engineering team charged by the monthRevenue that survives a cancelled product programmeThe rate is benchmarked against salaries, and you become staff by another name
- Licensing your own stack per device shippedIncome that grows without adding engineersYears of unpaid development before the first unit ships
- Maintaining and patching software already in the fieldThe only genuinely predictable line in the businessOn-call obligations, and defects written by people who have left
- Porting an existing stack onto new siliconShort, well-defined, repeatable workThe boards arrive late and nothing can start without them
The second row is marked because it is where most firms in this line actually live, and it is worth understanding why that is a trap as well as a living. Monthly engineering capacity is easy to sell, easy to budget for and easy to cancel, and because the customer can price it against the cost of hiring, the rate has a ceiling that does not move with skill. The firms that escape it do so by the third row, which requires funding a stack before anybody has agreed to buy it.
The buyer is an equipment maker, not an end user
Four kinds of customer sign this work. An equipment manufacturer with its own product roadmap and more silicon than engineers. A system integrator that has won a contract requiring a feature its chosen hardware does not have. A telecommunications operator's engineering group, which wants something specific from equipment it has already bought in volume. And a product company putting a connectivity module inside something that is not a computer at all — a meter, a vehicle subsystem, a piece of industrial plant — and which needs somebody who can make a radio work and has no interest in becoming that somebody.
Who signs, and who ends up owning the code
The person who wants the work is an engineering director. The person who writes the contract is in procurement, and the document that arrives is a development and supply agreement rather than a consultancy letter. It will carry acceptance criteria tied to test results, a defect liability period, and an assignment of intellectual property in the deliverable to the customer.
That assignment clause is the most commercially consequential paragraph in the business, and it is routinely signed without being read. Assigned wholesale, it means a firm can build the same subsystem five times for five customers and own nothing at the end of it. The clause that changes the trajectory of the practice is a carve-out for background intellectual property — the tools, the generic layers and the know-how that existed before the project and are reused on the next one — and it has to be negotiated before the first programme, because no customer grants it retrospectively.
The hardware schedule owns your calendar
A software house in this line cannot plan its own year. Boards slip, silicon re-spins, a product programme is cancelled by a customer's board for reasons nobody explains, and in each case the revenue moves without the costs moving. The practical consequence is that the firm needs either two unrelated customers whose schedules are uncorrelated, or a maintenance book large enough to pay the engineers between programmes. The fourth row of the drawing above is unglamorous and it is what keeps the lights on.
Where it sits between the mainland and a free zone
The honest answer here depends more on geography than on activity, because the customers are frequently not in the UAE. A free zone licence suits a firm whose work is delivered to equipment makers abroad, where nothing is sold into the local market and the engagement is an export of engineering effort. A mainland licence is the ordinary route where the customers are UAE operators, integrators and government buyers served on UAE soil, and where the firm expects to sit on local tenders. What a particular licence permits you to sell and to whom is settled by the authority issuing it rather than inferred from the activity name, and the choice is awkward to reverse once contracts are in place.
One boundary matters more than the licence choice and is regularly misunderstood. Communication and radio equipment placed on the UAE market is subject to type approval — a control on the equipment and on the party putting it on the market, administered in the UAE by the telecommunications and digital government regulatory authority. Writing software that runs on such equipment is not placing equipment on the market, so this activity does not carry that obligation. The moment the firm begins importing, branding or selling the devices themselves, however, it has added a trading proposition with its own activity wording and the equipment's own approval position becomes its problem. Where the software itself affects how a radio behaves, the manufacturer's approval is the thing the work has to stay inside, and that is a condition of the customer's product rather than of your licence.
Two further lines sit next to this one in the same catalogue and should be named rather than blurred. Computer system Consultancies is advice about which systems an organisation should run; this line builds software for the equipment those systems are made of. IT Infrastructure is the supply and construction of an estate of hardware; again a different proposition, with physical goods and customs exposure this line does not have.
What the licence costs, which form it takes, what the premises require, and how conformity and approval questions apply to a specific product all depend on the emirate and the licensing authority. ConsultZone confirms those against the actual engagement before a licence is applied for.
References
- Telecommunications and Digital Government Regulatory Authority — type approval for telecommunications and radio equipment, which is the control this line sits beside rather than inside. TDRA
- Ministry of Industry and Advanced Technology — national standards, conformity marks and in-country value, which bear on equipment built or supplied in the UAE. MoIAT
- Ministry of Economy — intellectual property, which is what the assignment clause in a development agreement is dealing with. Ministry of Economy
- Ministry of Human Resources and Emiratisation — work permits and labour contracts for embedded engineering staff. MoHRE
Elsewhere in Information Technology
Activities that sit beside this one
Most licences carry more than one activity. Adding a neighbouring line at the application stage costs a fraction of amending the licence afterwards.
Begin with a clear conversation
Tell us what you intend to build.
A consultant will map the structure, jurisdiction, approvals and likely cost against what you actually described — not against a package.
