Developers, a development company, or a software factory? Compare who carries the risk.
There are three ways to get an enterprise system built now: hire developers and give them AI coding tools, engage a development company, or use a software factory that delivers the finished system. AI has made all three fast at writing code. They differ in who is exposed when the system is late, wrong, or right and unused.
This page compares them on seven risks, on when you pay and on what you hold at the end. It also says when each is the right choice, including the two that are not ours.
What you are actually buying
These are general patterns, not a description of any one firm. A good development company can look like the third column; the six tests are how you tell.
| Aspect | Hire developers with AI coding tools | Engage a development company | Use a software factory that delivers |
|---|---|---|---|
| What you buy | Salaries and tool licences | People and time, or a fixed scope | A finished, running system |
| Who owns the requirement | You | You, usually as a brief or a paid discovery phase | You, with the factory turning it into a specification your users confirm |
| Where the build starts | Your codebase, or an empty one | Often an empty repository, or the firm's starter kit | Shared foundations and, where one fits, a core already built for the industry |
| What a change costs | Your team's time | More billed time, or a priced change request on a fixed scope | Depends on the contract. Ask whether changes are billed |
| When you pay | From the first day of hiring | As the work proceeds | From go-live on a usage model; on a licence, by milestones with the final payment held until done |
| What you hold at the end | The code, and whatever your team wrote down | The code, per the contract | The source and the specification, on the terms the contract sets |
Who carries each one on each route
The decision to hire is usually framed as a cost comparison: salaries and tooling against a quote. That misses most of what is being acquired. When an enterprise hires to build, it takes on risks that a delivery partner can be contracted to carry. None of them is new. The falling cost of code has made them easy to overlook.
| Risk | Hire developers with AI coding tools | Engage a development company | Use a software factory that delivers |
|---|---|---|---|
| Talent Finding and keeping people fluent in coding agents | Yours | The firm's | The factory's |
| Delivery The system is late | Yours. Salaries run whether or not anything ships | Yours on time and materials. On a fixed price the firm carries the overrun on the agreed scope; changes reopen it | The cost of the delay is the factory's, where payment starts at go-live. The wait is still yours |
| Outcome It ships and does not move the number | Yours | Usually yours. Delivered to the brief is done | The factory's only if it has committed to correct it. Ask |
| Key person The knowledge of why it works leaves | Yours. Unless you enforce documentation, it lives in prompts, commits and one person's memory | Often yours, once the team rolls off | Reduced: the specification, use cases and test cases remain as the record |
| Quality and regulation Audit trails, entitlements, residency, behaviour under failure | Yours. Found late unless you staff security and compliance review | Depends on the firm's practice | Built into the chain, if the factory governs the running system as well as the build. Accountability stays yours |
| Architecture Each project rebuilds the basics differently | Yours. Without a platform team, three projects can mean three stacks | Per project, unless the firm brings a house platform | Shared foundations across every build |
| Verification Whoever wrote it also marks it | Yours to design. By default the same agent tests its own code | Varies: a separate QA team at some firms, the developers at others | Tests written and held apart from the code-writing agent, then human QA. Still the vendor's own, so keep your acceptance test |
What does not move on any route: process ownership, adoption, data quality, executive sponsorship and regulatory accountability stay with the enterprise, because only the enterprise can manage them. The seven risks are from Position Paper No. 8, section 3; the development-company column is our reading of common contract terms, and yours may differ.
When the cost starts, and when the value does
Return on a system depends less on what it costs to build than on when its value begins and how certain that value is. An in-house build starts its costs on the first day of hiring. Value begins at a later date that nobody can promise, if the project lands at all. For the whole of the build the cost runs ahead of the value, and the gap between them is the enterprise’s exposure. A development company billed as the work proceeds has the same shape.
A model in which payment is triggered by go-live reverses the order: cost sits behind value. If the system also starts from components that already exist, value arrives sooner. And if the deliverer has committed to correcting the outcome when it slips, the delivery risk it can control sits with the party able to control it. The argument is set out in full in Position Paper No. 8, section 4.
Five questions that turn it into a risk-adjusted comparison
Put them to all three routes, including your own hiring plan.
- Who pays if the system ships late, and for how long?If the answer is only you, the delivery risk has not moved.
- Who pays if it ships on time and does not move the number?Delivered to the brief and useful to the business are different things.
- Who holds the knowledge of how it works if the people who built it leave?The acceptable answer is an artifact the next person can read.
- Who finds the regulatory gaps, and when?Before go-live, or at audit.
- Who carries the cost of the second and third systems, if each one starts from nothing?Shared foundations are where the saving compounds.
When each route is the right one
Hire developers with AI coding tools when
- software is the product: a technology company, or a bank whose digital channel is its competitive position
- the tool is small and internal, with little regulatory exposure and a short life
- you are exploring, and prototypes built to learn are the point
- you are prepared to build a governed engineering function around them, and to pay for the years it takes
Engage a development company when
- you already have a precise specification, a product owner and your own QA
- you need more hands on a codebase you own and will keep maintaining
- the work is integration or upkeep, where effort is the right thing to buy
- you are comfortable carrying the outcome yourself
Use a software factory when
- the system is a system of record or a regulated workflow
- it must still behave correctly in three years
- you want cost to sit behind value, not ahead of it
- you want to hold the source without carrying the delivery risk
- you can accept the factory's foundations and, on a shared core, a licence in place of exclusive ownership
Building a full engineering organisation, with architects, QA, security and platform engineering, does address several of the seven risks. It is also building a software factory of your own, with one customer. Where software is the business, that is the right investment. Where software runs the business, the question is whether owning a factory is a better use of capital than owning the problem and the outcome.
The third route, and what we commit to
Xamun takes the third route. These are four things we commit to. Each is described on the page linked; the binding terms are in the signed agreement.
Payment depends on the system going live. Under the usage model nothing is billed before the operation runs through the system. Under a licence there are milestones, with the final payment due at done. Described at: how we price.
We correct the outcome. For three years after done, if the number agreed at Discovery slips, we fix it within the agreed scope, without asking why. Described at: Outcome-as-a-Service.
The tests are not written by the agent that writes the code. A different AI agent, on a different model, writes them, and they are locked away from the code-writing agent. Human QA then runs and verifies the build. Detail: Software Factory.
You get the code. A system we build for you from a blank specification is yours outright. A system built on an OS Series core comes with the full source under a perpetual, non-exclusive licence, for your own business use. Detail: our answers to the six tests.
For buyers in the UAE and the wider Gulf: Xamun has an office at the Dubai AI Campus in DIFC, and the rules that bind a private firm’s AI system in the UAE are set out on AI governance in the UAE.
Questions buyers ask when choosing a route
What is the difference between a software factory and a software development company?
A software development company usually sells effort: people and time, with each change priced. A software factory that delivers to the business sells the finished system. It runs every build through the same chain, starts from components that already exist, and is paid in a way that depends on the system going live. The practical difference is who is exposed if the system is late, or arrives and does not do its job.
Should an enterprise hire developers with AI coding tools or use a software factory?
Hire when software is your product, when the tool is small and short-lived, or when you are exploring what is possible. For a system of record, a regulated workflow, or anything that must still behave correctly in three years, hiring means taking on seven risks that the right delivery model can carry instead: talent, delivery, outcome, key person, quality and regulation, architecture, and verification. A factory is worth it when it takes the controllable ones off your books.
Is a software factory just outsourcing with AI?
Not if it hands over the source and the specification, runs your system as a dedicated instance, and is paid in a way that depends on the system going live. Traditional outsourcing reduced delivery risk and created dependence: a black box, a shared platform, knowledge that left with the team. If a vendor cannot show those three things, it is outsourcing with AI, whatever it is called.
Is a software factory cheaper than a development company?
This page does not compare prices, because the shapes are different. With developers or a development company, cost starts on day one and runs ahead of value until the system is live. With a model in which payment starts at go-live, cost sits behind value. The comparison that matters is risk-adjusted: who pays if the system is late, and who pays if it ships and does not move the number.
Which risks stay with the enterprise whichever route it takes?
Process ownership, adoption, data quality, executive sponsorship and regulatory accountability. Only the enterprise can manage those, and no honest delivery model claims to take them. What can move is the controllable delivery risk: schedule, build quality, architecture, verification, and correcting the outcome within the agreed scope.
Which route suits a system of record in the UAE or the wider Gulf?
The same reasoning applies, with one addition. A system that decides anything about money, tenancy, credit or personal data should be able to show a regulator which component had the final say, so ask every candidate what the system does when the language model is switched off. Xamun has an office at the Dubai AI Campus in DIFC; the rules that bind a private firm's AI system in the UAE are set out on our AI governance page.
Bring your hiring plan. We will put all three side by side.
A Discovery names the operation and the number it should move, and we will walk the five questions across all three routes with you. If hiring is the right answer, we will say so.