Build only what you cannot buy
Your competitive advantage is held together by a spreadsheet that one person maintains.
What you get
- A written case for building instead of buying, or an honest recommendation to buy
- Integration with your ERP treated as part of the build, not a later phase
- Documentation and handover, so the system outlives the developer
- Code and infrastructure you own outright
The spreadsheet nobody else is allowed to touch
It has forty tabs, a macro somebody wrote and left behind, and a filename that ends in final_v7. It prices your work, or it plans your production, or it tracks which client owes what against which milestone. One person maintains it, and when he is on leave the business runs slower. Two other people hold copies that stopped agreeing months ago. A formula in row nine hundred has been wrong since March and nothing in the file will ever tell you.
That spreadsheet is rarely a failure of discipline. It exists because it models something real about your operation that no product you can buy models, and the person who built it was solving a problem the software would not. The mistake is leaving it there once the business depends on it.
The same pattern shows up as a form on a shared drive, a chat group used as a queue, or a database on one machine that produces a report the board reads every month.
Build only what you cannot buy
Most requests for custom software development in Dubai should end in a configuration change to something the company already owns. We test that first and we test it seriously: what does standard software already do, what would have to change in your process for it to fit, and what does that change cost compared with a build plus ten years of maintaining it.
Custom code is a liability you carry for as long as you use it. Every line has to be maintained, upgraded, secured and understood by whoever comes next. It is a good trade when the workflow is genuinely how you compete. It is a bad one when it exists only because a process was never agreed and writing code felt easier than settling an argument.
The written build-or-buy case is a deliverable in its own right, and the recommendation is often to buy. That answer is cheaper for you and smaller for us, and we still write it.
What actually gets built, and what you own at the end
What we are asked for is rarely a product with a market. It is the part of an operation that generic software does not model. A property management system covering more than five thousand units, the lease contracts on them and the department accountable for both. A project management system for a firm whose product is other people's paperwork, built around one file per client engagement rather than one folder per document.
Integration with your ERP is part of the build, not a later phase. A custom system that does not post to the ledger creates a reconciliation job, which is the problem you started with, moved to a new location and given a nicer interface.
You own the source code, the repository, the infrastructure accounts and the documentation. Handover is written so a developer who has never met us can pick the system up. If we end up the only firm able to change it, we have sold you a dependency and invoiced it as an asset.
Why custom projects fail
The specification was a feature list. Features are easy to agree and say nothing about the data model, which is the part that decides whether the system can still be extended in year three or has to be rewritten.
It was designed around one person's opinions, and that person left. Integration was deferred to a second phase that was never funded. Nothing was documented because everyone involved intended to still be there.
And the most common one: the process was still being argued about while the software was being written. Code is the most expensive place in a company to hold a disagreement. We settle the process on paper first, which looks slower on a plan and is not.
If your process is not settled and nobody has the authority to settle it, a build will not fix that, and we will say so before quoting rather than after invoicing.
How a build is priced
By scope, after the scope is written. What moves it: the number of distinct workflows, how many systems the software has to talk to, whether data has to be extracted from the spreadsheets it currently lives in, any requirement that constrains where the data sits, and what level of support you want afterwards.
We do not run open-ended day-rate builds. You get a written specification and a fixed scope at a fixed price before development starts, delivered in phases that are usable on their own. A change to scope is repriced in writing before anyone writes the code, not absorbed quietly into a backlog and billed later.
Hosting, ongoing support and future development are quoted separately and none of them is conditional on the others. Taking the system in-house after handover is a normal ending, not a penalty.
How the engagement runs
- 01
Diagnose
Two weeks inside your operation. We map how the work is actually done, where two systems disagree, and what each gap costs you in a month.
- 02
Architect
A target design tied to operating decisions: which system holds which truth, who owns it, and what has to be true before go-live.
- 03
Implement
Delivery in phases you can stop after. We train your team to run it, because a system that only we can operate is a system you do not own.
- 04
Govern
The part everyone skips. Ownership, review cadence and metrics, so the system does not quietly decay back into chaos.
Questions
What people ask before they start this work
How is custom software priced?
As a fixed scope at a fixed price, written before development starts. The drivers are the number of distinct workflows, how many systems it has to integrate with, whether data must be migrated out of existing spreadsheets, and the support you want afterwards. Scope changes are repriced in writing before code is written. We do not sell open-ended day-rate development against a backlog that never closes.
How long does a build take?
It depends on how many workflows are in the first release and how settled the process is before we start. The single largest cause of delay is not development speed, it is a business decision that has not been made — an approval rule nobody will commit to, or two managers who disagree about a definition. We phase releases so something is in real use early rather than at the end.
Who owns the code and the intellectual property?
You do, outright. The source lives in a repository you control, the infrastructure sits in accounts in your name, and the documentation is written for a developer who has never spoken to us. There is no licence back to Faceela, no runtime fee, and no component you have to keep paying us for. If you want to move the work to another firm, that is a handover rather than a negotiation.
Should we build or buy?
Buy, unless the workflow is genuinely how you compete. Most of what companies want to build already exists as configuration inside a product they own, and buying is cheaper to run, cheaper to secure and cheaper to hire for. We write the build-or-buy case as a deliverable, and it frequently recommends against a build. That answer costs us the larger project and it is still the right one.
Do you build on Odoo or as a standalone application?
Whichever the operation calls for. If the workflow sits inside the commercial chain — orders, stock, costing, invoicing — building it as a proper Odoo module keeps one set of books and avoids an integration. If it is genuinely separate, or has users who should never see your ERP, a standalone application with a clean interface into the ERP is better. The decision is written down with its reasons.
What happens if you stop working with us?
Nothing breaks. You already hold the code, the infrastructure and the documentation, and the handover pack is written during the build rather than assembled at the end when goodwill is short. Any developer with the relevant experience can take it on. We would rather you stay because the work is good than because leaving is expensive.
Where is the data hosted?
In accounts you own, and in a region you choose. For UAE and GCC clients that is usually a regional data centre, sometimes for regulatory reasons and sometimes because latency to the office matters. Where a contract or a client of yours imposes a residency requirement, that constraint is fixed before architecture rather than discovered during it.
Custom Software
Start with a diagnosis
Tell us the symptom in one line. We will come back with what we would look at first and what it would take.
Monday to Friday, 9:00 AM – 6:00 PM (GST)
Prefer we call you?
Leave your WhatsApp number and we will reach out.