Every pricing article about software says the same useless thing: it depends. This one gives you numbers. They are the numbers I actually quote, from building 42 production systems across eight countries, and most of this article is about the part that decides where in the range your project lands. If you only read one section, read the one on what you are really paying for. That is where budgets get won or lost.
Why the price ranges you found online do not apply to you
Search for what a website costs and you get a figure built from American or European agency rates, usually two years old, usually describing a market where nobody needs Arabic, nobody integrates with Mada, and nobody has to think about e-invoicing. Then you ask three developers in Riyadh or Dubai and get three quotes that differ by a factor of six. Both things are true at once, and neither helps you plan.
Here is what is going on. Software has almost no fixed cost. A kilo of steel costs what it costs, but a booking system can be assembled in nine days from a template or engineered over five months, and both get called "a booking system" in the quote. The word describes the output, not the work. So the first job of anyone buying software is to stop comparing prices for a noun and start comparing prices for a scope.
The second thing going on is specific to this region, and it is the reason imported price lists mislead. A Gulf project carries requirements that a London project does not: a genuinely bidirectional interface rather than a translated one, payment methods your customers trust rather than the ones Stripe defaults to, and in Saudi Arabia a set of compliance obligations that are not optional. None of that is exotic. All of it is work, and work that nobody included in the number you read online.
What you are really paying for
When I price a project I am estimating seven things. Any one of them can double a quote, and understanding them lets you have a different conversation with every developer you talk to.
1. How many user types the system has
This is the single biggest driver and almost nobody asks about it. A site with visitors only is one system. A site with visitors and an admin is roughly two. A marketplace with customers, vendors, a dispatch team and a finance admin is four, and the cost is not four times one, because every pair of roles creates rules about what one can see and do to the other's data.
When I built Wasiila for pilgrim supplies in Mecca, the catalogue was the easy half. The hard half was that independent suppliers list and fulfil their own orders, which means a supplier must see their orders and not their competitor's, the customer must see one basket spanning several suppliers, and the money has to split correctly when it arrives. Count your roles before you ask for a price. If a developer quotes without asking, they are quoting for one role and you will find out later.
2. Whether money moves through it
A site that explains your service and a site that takes payment for it are different categories of project. Once money moves, you inherit refunds, partial refunds, failed payments that silently succeeded, duplicate charges from a double tap, reconciliation when your gateway report disagrees with your database, and a paper trail somebody will eventually audit. The payment button takes a day. The states around it take weeks.
3. Whether it talks to anything else
Every external system you connect to is a small project with its own documentation, its own sandbox, its own failure modes and its own habit of changing without warning. Shipping carriers, accounting software, a POS, an SMS provider, a national identity service, a hotel channel manager. I price integrations individually and so should anyone quoting you, because "connects to our accounting system" can mean a CSV export or six weeks of work, depending entirely on which accounting system.
4. How much of the content is structured
Twelve pages of text is a small job. Twelve pages plus a product catalogue with variants, stock, pricing rules per customer group and a search that has to work in Arabic is a different job, and the catalogue is most of it. Arabic search alone deserves a mention: a naive search box fails on Arabic because of definite articles, hamza variants and diacritics, so a customer searching for the thing you sell gets nothing. Fixing that is a day of work that most quotes do not contain, and the cost of not fixing it is every search that returns empty.
5. Who it has to keep out
An internal tool used by nine people you trust has a security budget. A public platform holding customer identity documents, legal case files or medical records has a much larger one, and the difference is not a checkbox. For Isgha, a Riyadh law firm, confidentiality was the design constraint rather than a feature: case material belongs to one matter, visible to the people on it, and the intake flow had to collect enough to evaluate a case without collecting things the firm would rather not hold at all.
6. How many people use it at once
Most business systems in this region serve tens to low hundreds of concurrent users, and at that size almost any competent build works. Above that, choices that were free become expensive, and the ones that bite are usually database choices made in week one. I have been called in to fix systems that were fine at 500 users and collapsed at 5,000, and the fix was never the server. It was an unindexed query written three years earlier.
7. Who maintains it afterwards
A system built to be handed over costs more than one built to be finished. Documentation, a sane deployment process, tests on the parts that would quietly corrupt data, code a stranger can read. If you intend to hire an in-house developer later, say so during pricing, because it changes how the thing should be built and it is much cheaper to decide at the start.
Price bands by project type
These are my own ranges for 2026, in US dollars because clients across the Gulf, Europe and Egypt all read dollars without converting. They assume a working brief, a single decision maker, and no redesign halfway through. Where a range is wide, the section underneath tells you what moves you up it.
Company website, brochure style
$1,200 to $4,500. Five to fifteen pages, bilingual Arabic and English, a contact form that reaches you reliably, structured data so you appear properly in search, and speed that holds up on a phone on mobile data. The low end is a well-built site on a clear structure. The top end adds a real content model so your team can publish without calling anyone, custom illustration or photography direction, and a design that was drawn for you rather than adapted.
What moves you up: more than two languages, a careers section with applications, multi-branch location pages, or an approval workflow before content publishes.
Landing page built to convert
$600 to $2,000 for one page. That sounds like a lot for a single page, and it is, if you think of it as a page. What you are buying is the offer written clearly, a form short enough that people finish it, tracking wired so you can see which ad produced which enquiry, and page speed good enough that your ad spend is not paying for people who leave before it renders. I have seen a 2.5 second improvement in load time change enquiry volume more than a month of ad optimisation.
E-commerce store
$3,500 to $15,000 for a custom build. Below that range, use Salla or Zid in Saudi Arabia, or Shopify elsewhere, and spend the money on photography and ads instead. I tell clients this regularly and it costs me work, but a shop selling forty products with standard shipping does not need custom software and will launch six weeks sooner on a platform.
Build custom when the platform genuinely cannot do it: pricing that varies by customer contract, a product configurator, stock split across branches with click and collect, B2B accounts with credit terms and purchase orders, or an integration with a POS or ERP that the platform's app store does not cover.
Booking and reservation platforms
$4,000 to $20,000. The spread here is the widest of any category because "booking" covers a dentist with one chair and a tourism operator selling packages with transfers, hotels and a separate supplier API. Lotus Sharm, a Sharm el-Sheikh tourism platform, sat at the top of that range: packages, airport transfers, hotel booking and full itinerary management, with its own API because the operator needed to feed partners too.
What drives the cost is not the calendar. It is availability. The moment two people can book the same slot, you need the system to be correct under pressure, and correctness under pressure is engineering, not design.
Custom business systems: CRM, ERP, POS
$6,000 to $40,000. This is where most of the serious work in the Gulf sits right now, and where the gap between a demo and a system that survives a year is widest.
Omnixtrack, a multi-tenant Arabic CRM, and Kassenta, a cloud POS serving multiple businesses from one deployment, are both in this band. Multi-tenancy is the reason. One company's data must never appear in another's, every query carries that constraint, and getting it wrong once is the kind of incident a business does not recover from. Single-company systems cost noticeably less for the same feature list.
SaaS platform
$12,000 to $60,000 for a first version that real customers pay for. Not a prototype. Subscriptions, plan limits that are actually enforced, a billing lifecycle including upgrades, downgrades and failed payments, tenant isolation, and an admin side you can run a business from.
Most founders ask for version three. The job of a good first version is to be small enough to ship while being real enough to charge for, and the hardest part of the work is deciding what to leave out. I have talked more clients down from this band than up into it.
Mobile applications
$5,000 to $30,000 per platform, less when a single codebase covers both. Published apps carry costs a website does not: store review, which rejects things for reasons you will not predict; forced updates when the OS changes; and the simple fact that a user running your six-month-old version is still your problem.
I have taken apps through Google Play for clients in Egypt, the Gulf and Europe, and the pattern repeats. The store is never the bottleneck. The bottleneck is a backend that was not built for two weeks of real users, which is why the API and the data model get planned before anyone designs a screen.
AI features
$2,000 to $25,000 on top of the system they live in, and the honest answer is that most requests for AI are better served by a well-built search box and a clear form. The ones that genuinely pay for themselves tend to be narrow: scoring and sorting incoming enquiries, extracting structured data from documents people currently retype, drafting a first version of something a human then approves.
Sigma PMO is the clearest example I have of the shape that works. The analysis runs automatically across seventeen governance stages, and nothing reaches a bank or an investor until a named person has approved it. Automated analysis, human approval. Build it the other way around and you have bought yourself a liability.
Budget for the running cost too. Model usage is an ongoing bill that scales with traffic, unlike hosting, which mostly does not.
The Gulf costs that imported price lists leave out
This section is the reason a quote from an overseas agency and a quote from someone who works here can differ so much while both being honest. These items are real work. If they are missing from a quote, they are not free, they are deferred.
Arabic that was designed, not translated
Bidirectional layout is not a stylesheet flag. Direction flips, but numbers, currency, phone numbers, code snippets and brand names stay left to right inside a right to left sentence, and every mixed string is a chance to get it wrong. Icons that imply direction have to mirror. Form validation messages need to read like something a person would say in Arabic, not a machine translation of an English error.
Then there is type. Most of the web's default font stacks render Arabic badly, with wrong line height and letterforms that look borrowed. Choosing and loading an Arabic typeface properly, and keeping the file small enough not to hurt load time, is its own small job.
Budget 15 to 25 percent on top of a single-language build for Arabic done properly. Budget nothing if you are willing to accept a site that Arabic speakers can tell was built in English first, which most visitors notice within a second and read as a signal about the company.
Payment methods people here actually use
A checkout that only takes international cards will lose a large share of Saudi customers, because Mada is the card most people are carrying. Add Apple Pay, which in this region converts better than almost anything else on a phone, and depending on your market STC Pay, and increasingly the buy-now-pay-later options that younger shoppers expect.
In practice that means working with a regional gateway rather than defaulting to Stripe: Moyasar, Tap, HyperPay or PayTabs in Saudi Arabia, with Telr and Network International common in the UAE. Each has its own integration, its own test environment and its own settlement behaviour. One gateway is a day or two of work. Supporting several, with a clean fallback when one fails mid-transaction, is a week.
Merchant onboarding is also a dependency you should start early. It involves paperwork, verification and a wait, and I have watched finished projects sit unlaunched for three weeks because nobody began the gateway application until the code was done. Start it the day the project starts.
Saudi compliance
If you invoice in Saudi Arabia, electronic invoicing is a legal requirement, not a feature. Invoices must be generated in a prescribed structure, carry a QR code, and be reported to or cleared by ZATCA depending on the phase and the obligations that apply to your business. Getting this right involves certificates, a defined invoice format and an integration that has to keep working, because an invoice that fails to clear is an invoice you cannot give a customer.
This is the item most often missing from a quote, and the most expensive to add afterwards, because invoicing touches the data model rather than sitting beside it. If your system will issue invoices, raise it in the first meeting and ask directly whether the quote includes it. Confirm your own obligations with your accountant or ZATCA rather than with your developer, then tell the developer what applies.
Selling to consumers online in Saudi Arabia also comes with registration expectations, and platforms and payment providers will ask for commercial registration details during onboarding. None of it is difficult. All of it takes calendar time.
National identity and government integrations
Some sectors need verified identity rather than an email address. Saudi Arabia has national digital identity infrastructure that services can integrate with, and where that applies it removes a whole category of fraud and manual verification. It also adds an approval process, a sandbox phase and a compliance review to your timeline. Treat it as a project milestone with its own date, not a task in a sprint.
Hosting close to your users
A server in Frankfurt serving customers in Jeddah adds latency to every single request. For a brochure site a CDN fixes most of it. For an application where people submit forms and move through screens all day, the difference is felt, and staff will describe your system as slow without being able to say why. Regional hosting or a properly configured edge setup costs a little more and is usually worth it.
What different industries actually need
Price follows requirements, and requirements follow the sector more than most buyers expect. Here is what changes the number, industry by industry, drawn from systems I have delivered.
Real estate and property development
Listings are the easy part. The cost sits in the workflow behind them: units with status that must never be wrong, reservations that hold for a period and then release, commission splits, document packs per unit, and handover tracking. Developers also need governance over the numbers, which is a different system entirely from the one that shows a customer a floor plan.
Typical range for a sales-and-inventory platform: $8,000 to $30,000. A listings site alone sits far below that.
Legal practices
Confidentiality shapes everything, so access control stops being a feature and becomes the architecture. Matter-based permissions, a document store with a real audit trail, deadline tracking, and an intake flow that collects enough to evaluate a case without collecting more than the firm wants to be holding. Public-facing, a service tree that lets someone find the specific thing they need rather than a page listing everything.
Range: $4,000 to $18,000 depending on whether the internal matter management is in scope or only the public platform.
Healthcare and clinics
Appointments are simple until they meet reality: multiple practitioners, rooms as a separate resource, procedure durations that differ, no-show handling, and reminders that actually reduce no-shows. Patient data raises the security floor for the whole project. Any integration with an existing clinic system is usually the largest single line item.
Range: $5,000 to $25,000. Dr Mohamed's dental clinic booking platform sat in the middle of that.
Education and training
Enrolment states, progress tracking, assessment, certificates, and tooling for instructors that does not make them hate the system by month six. Corporate training adds an entire second structure: companies as buyers, cohorts, seat allocation, and reporting the client's HR department will ask for.
OGS Academy, delivering accredited industrial training to oil, gas and heavy industry clients in Saudi Arabia, needed the corporate layer rather than the consumer one, and that distinction moved the project more than any feature on the list.
Range: $6,000 to $30,000.
Restaurants and food service
The economics of this sector drive the technical decision. A delivery marketplace takes a percentage of every order, and for a restaurant doing real volume that percentage is the single largest controllable cost in the business. Own ordering, own table reservations, and the margin stays in the kitchen.
What it actually needs: a menu with modifiers that reflects how the kitchen works, opening hours and delivery zones, order status the customer can see, and a printer or screen in the kitchen that does not depend on someone watching a browser tab.
Range: $3,000 to $12,000, and the payback period is usually measured in months rather than years.
Logistics and delivery
Dispatch, driver applications, live tracking, proof of delivery, cash on delivery reconciliation, and zone-based pricing. Cash on delivery is the item that surprises people: it means driver float, settlement, and a daily reconciliation process, all of which is software. Tamem, an Upper Egypt delivery and logistics platform, carried all of it along with its own Android app.
Range: $10,000 to $40,000.
Pilgrimage and religious services
Demand is calendar-driven and extremely concentrated, which changes the engineering. The system has to hold up during a short window when everybody arrives at once, and it has to behave on a crowded connection in Mecca where a request may take several seconds or not arrive at all. Provider verification matters because trust is the product. Package models have to survive real-world changes without corrupting an existing booking.
I have built in this sector repeatedly, including Hadiah, Taffweed, Maeyn and Wasiila, and the lesson that keeps repeating is that order state has to be designed for an unreliable network, not a good one.
Range: $7,000 to $28,000.
Professional services and consultancies
Usually the public platform plus a structured intake, with the real value in what happens to an enquiry after it arrives: routing, qualification, and a record a partner can act on. Sigma PMO added a governance system to that, where every output has to trace back to a source document before anyone signs it.
Range: $3,000 to $20,000.
How you pay changes what you pay
Three models dominate, and choosing the wrong one for your situation costs more than choosing the wrong developer.
Fixed price
You agree a scope and a number. It works when the scope is genuinely knowable in advance, which is true far more often than developers like to admit: a company site, a store, a booking system you can describe completely.
The thing to understand is that a fixed price contains a risk premium. The developer is absorbing the uncertainty, so they price for the bad version of your project, not the likely one. A clearer brief lowers that premium directly, which is the cheapest money you will ever spend on a software project.
The failure mode is change. Once the scope is fixed, every addition is a negotiation, and a developer who priced thin becomes someone looking for reasons to say no. Agree up front how changes get priced, before you need one.
Time and materials
You pay for hours or days. Honest when nobody can see the end of the work: a long-running platform, an integration into a system you do not control, a product still finding its shape.
It transfers all the risk to you, so it only works with a developer you can verify. Ask for a weekly cap, a demo every week or two, and the ability to stop at the end of any month. If someone resists all three, that tells you something.
Monthly retainer
A fixed monthly amount for ongoing work and support. The right model once you are live and the system matters to the business. Expect to pay roughly 10 to 20 percent of build cost per year for maintenance, more if your system has many integrations, because other people's systems change and yours has to keep up.
The question to ask is what the retainer covers when nothing breaks. A good answer includes updates, monitoring, backups and a small amount of improvement work. A bad answer is "support", which means you pay monthly for the privilege of being allowed to report problems.
Milestone payments, whichever model you choose
Never pay everything up front, and do not expect a developer to work for months on nothing. A split along the lines of 30 percent to start, 40 percent at a working system you can use, and 30 percent at launch keeps both sides committed. Tie each payment to something you can see and test, not to a date.
How to read a quote
Most quotes in this market are one page with a number. That is not a quote, it is a hope. Here is what a real one contains, and what each part protects you from.
| What the quote should contain | What it prevents |
|---|---|
| A list of user roles and what each can do | Discovering the admin panel was not included |
| Named integrations, one line each | "Connects to your system" meaning a CSV file |
| Explicit language scope, including Arabic content entry | An English build with Arabic bolted on |
| Who writes the content and who supplies images | A finished site waiting three months for text |
| Number of design revisions included | An open-ended redesign loop, or a surprise invoice |
| What happens to the code and who owns it | Being unable to hire anyone else later |
| Hosting, domain and third-party fees, and who pays them | Annual bills you did not plan for |
| Support period after launch and what it covers | Paying for bug fixes in week two |
| Explicit exclusions | Every argument you are going to have |
The exclusions line is the one I would insist on. A developer willing to write down what they are not doing has thought about the project. A developer who only writes down what they are doing has written a brochure.
Signals worth taking seriously
A quote that arrives within an hour of a first conversation was not estimated, it was guessed, and the guess will be defended later by cutting things. A price far below every other quote usually means a different scope, not a better deal, and the conversation to have is about what is in it rather than about the number. Ask who writes the code: agencies that win work with a senior and deliver with a junior are common everywhere, and the question is fair.
Ask for a system you can log into, not a gallery of screenshots. Anyone can show pictures. Fewer can show a thing that is running, holding real data, and has survived contact with users.
Costs that appear after launch
The build is the visible number. These are the ones that arrive later, and planning for them is the difference between a system that lasts and one that quietly rots.
| Item | Typical annual cost | Notes |
|---|---|---|
| Hosting | $60 to $1,200 | Shared hosting is fine for a site; an application with real traffic is not a shared hosting problem |
| Domain | $10 to $60 | A .sa domain has its own registration requirements |
| SSL certificate | $0 | Free and automatic now; anyone charging for a basic certificate is charging for nothing |
| Payment gateway | Percentage per transaction | Varies by provider and card type; model it against your real volume |
| Transactional email and SMS | $0 to $600 | SMS in this region is not cheap at volume, and OTP messages add up fast |
| Maintenance | 10 to 20 percent of build cost | Security updates, dependency upgrades, small fixes |
| App store accounts | $25 once for Google Play, $99 a year for Apple | Only if you ship mobile apps |
| Model usage for AI features | Scales with traffic | The one line that grows with your success |
Maintenance is the line people try to cut and the one that costs most to skip. Dependencies accumulate known vulnerabilities whether or not anyone is looking, and the bill for three years of deferred updates arrives all at once, usually in the form of an upgrade that cannot be done incrementally.
How to spend less without wrecking the project
Every one of these works. I have used them with real clients and they reduce cost without the thing collapsing six months later.
Cut scope, not quality
This is the whole game. Half a system built properly can grow. A full system built badly has to be replaced, and you will pay twice.
The practical version: list every feature, then mark each one as needed to operate, needed within six months, or wanted. Build the first group. You will be surprised how much of the second group you stop wanting once the first group is live and you can see how people actually use it.
Use a platform where a platform fits
Custom software should exist because something is specific to your business. For everything generic, a platform is faster and cheaper, and that remains true however much I would prefer to be paid to build it. Where the platform genuinely blocks you, build. Where it merely annoys you, live with it for a year.
Supply your own content
Content is often 15 to 20 percent of a project and almost always the thing that delays launch. If you can write your own copy and supply real images, you save money and you get better content, because you know your business. If you cannot, say so at quoting time rather than discovering it at launch.
Decide quickly
Developer time spent waiting is time you pay for, either directly or through a higher fixed price next time. One decision maker who answers within a day will get a better project than a committee that meets fortnightly, and the difference is visible in the result.
Do not pay for a redesign you do not need
If your site works and merely looks dated, a design refresh on the existing structure costs a fraction of a rebuild. I take this work regularly. Three aviation clients came to me wanting new sites and left with improved versions of what they had, for a fraction of the quoted rebuild, because the structure underneath was sound.
Be honest about volume
Asking for a system that handles a million users when you have four hundred buys you cost today against a problem you may never have. Build for ten times your current size, make sure the data model can grow, and revisit when you get there. Scaling later is a real project but it is a smaller one than over-engineering now.
How long things take
Timelines are a cost, because a system that launches four months late has four months of business it did not support. These are working estimates from a signed start, assuming decisions arrive within a couple of days and content is ready.
| Project | Realistic timeline | What usually delays it |
|---|---|---|
| Landing page | 3 to 7 days | Waiting for the offer to be decided |
| Company website | 2 to 5 weeks | Content and image supply |
| E-commerce store | 4 to 10 weeks | Product data, and gateway onboarding |
| Booking platform | 5 to 12 weeks | Availability rules nobody wrote down |
| Business system (CRM, ERP, POS) | 8 to 20 weeks | Discovering how the business really works |
| SaaS first version | 10 to 24 weeks | Scope growing during the build |
| Mobile app | 6 to 16 weeks plus review | Store review, and the backend being late |
The pattern across all of them: delays come from the client side far more often than the developer side, and almost always from a decision that nobody owns. If you want a project to finish on time, name one person who can approve things and give them the authority to do it.
A worked example
A Riyadh clinic group with three branches wants online booking. Here is how the number is actually built, so you can do the same exercise before you ask anyone for a price.
| Component | Estimate |
|---|---|
| Public site, bilingual, three branch pages | $1,800 |
| Booking engine: practitioners, rooms, variable durations | $3,200 |
| Patient accounts and history | $1,400 |
| Admin: schedules, leave, branch management | $2,200 |
| SMS and WhatsApp reminders | $900 |
| Online payment and deposits | $1,200 |
| Reporting for management | $1,100 |
| Total | $11,800 |
Now the useful part. Remove patient accounts, payments and reporting from version one, and the number drops to about $8,100 for something that opens for bookings six weeks sooner. The clinic then adds the rest once it knows which of the three it actually misses, and in my experience it is rarely all three.
That is the exercise worth doing on any project. Not "what does this cost" but "what is the smallest version that earns, and what does that cost".
Prices are not the same across the Gulf
Clients often assume one regional rate. There is not one. The differences come from what each market requires rather than from developers charging different amounts for the same work.
Saudi Arabia
The largest market and the most demanding technically, because of compliance. E-invoicing obligations, Mada as the default card, and in several sectors an expectation that identity is verified rather than self-declared. Arabic is not optional and it is not secondary: for most Saudi businesses the Arabic interface is the primary one and English is the translation, which is the reverse of how many developers build.
Expect a Saudi project to carry roughly 10 to 20 percent more work than the same project elsewhere in the region, almost all of it in compliance and payments. Expect that to be worth it, because the market is large and buyers there are used to paying for software that works.
United Arab Emirates
More international, more English-first, and generally more comfortable with global tooling, so Stripe and standard stacks go further. Multi-currency comes up more often. Free zone businesses have their own arrangements that occasionally affect payment onboarding.
The design bar is high. UAE buyers compare your product against international products daily and judge it by that standard, which means the budget line for design is harder to cut than elsewhere.
Kuwait, Qatar and Bahrain
Smaller markets with the same Arabic and payment expectations as Saudi Arabia and lighter compliance requirements. Projects here tend to be a little cheaper than the Saudi equivalent, and delivery speed matters more, because buyers are often moving on a shorter horizon.
Egypt
Price-sensitive and volume-driven. Cash on delivery remains a real requirement in commerce and logistics, and building for it properly is more work than building for cards. Mobile data quality varies widely, so a heavy front end that performs fine in a Gulf capital will frustrate users in a governorate. I build lighter for this market deliberately.
Europe and the UK
Data protection shapes the project from the start rather than being reviewed at the end. Consent, retention periods, the ability to export or delete a person's data, and a lawful basis for processing. It adds real work and it is not negotiable. Rates are higher, expectations around accessibility are higher, and procurement is slower.
Technology choices, and what each one costs you later
Buyers are told to care about the stack and then given no basis for having an opinion. Here is the version that affects your budget, with the parts that matter to you rather than to a developer.
WordPress
Cheapest to start, and genuinely the right answer for a content site with a blog and a few forms. The cost arrives when you push it past that. Business logic in WordPress tends to be assembled from plugins, each with its own update cycle and its own author who may stop caring, and a system built from fifteen of them is a maintenance liability rather than an asset.
My rule: WordPress for publishing, not for operations. If your site mostly tells people things, use it and spend the savings elsewhere. If your site runs part of your business, do not.
Laravel
What I build most business systems in, and I should say why rather than just naming it. It handles the things every business system needs (authentication, permissions, queues, scheduled jobs, database migrations) as part of the framework rather than as plugins, which means a developer who did not write it can still read it. The hiring pool in this region is deep, so you are not locked to one person. For a system you expect to own for five years, that matters more than any benchmark.
React, Vue and the heavy front end
Right for applications people keep open all day and interact with constantly: dashboards, editors, anything that feels like a tool. Wrong, and expensive, for a content site, where it adds complexity and slows the first load, which is the one that decides whether a visitor stays.
A lot of money in this region is spent making brochure sites into single-page applications for no benefit. If a developer proposes it, ask what it buys you. There is sometimes a good answer. Usually there is not.
No-code and low-code
Excellent for internal tools, early validation, and anything you need working this week. The limits are real: per-seat pricing that grows awkwardly, difficulty when you need behaviour the platform did not anticipate, and an exit that is harder than it looks. Use it to find out whether the process is right, then rebuild the parts that have proven themselves.
Native versus cross-platform mobile
A shared codebase covering iOS and Android saves a substantial share of the budget and is the right default for most business apps. Go native when the app is the product and performance or deep device integration is the point. For an app that lists, books, tracks or orders, a shared codebase is not a compromise.
When to repair and when to replace
Rebuilding is the most expensive decision in software and it is frequently made for the wrong reason, which is that the current system is unpleasant to look at. Here is how I assess it when a client asks.
| Situation | What it usually calls for |
|---|---|
| Looks dated, works correctly | Design refresh on the existing structure, a fraction of a rebuild |
| Slow under normal load | Profiling and targeted fixes; it is nearly always a small number of queries |
| Every change takes weeks and breaks something | This is the real signal. Consider replacing |
| Built on something no longer maintained | Replace, and plan it before you are forced into it |
| The business changed and the data model cannot express it | Replace. No amount of patching fixes a wrong model |
| Nobody knows how it works | Investigate before deciding; it may be sound and merely undocumented |
A rebuild should cost less than the original, not more, because the requirements are now known: you have a working system telling you exactly what it does. If a rebuild quote exceeds the original build, somebody is scoping a different product and calling it a rebuild.
There is a middle path that gets overlooked. Leave the old system running and build the new one beside it, moving one area at a time. Slower overall and more expensive on paper, but the business never stops, and the risk at each step is small enough to recover from. For anything running live operations, this is usually what I recommend.
Writing a brief that gets you an accurate price
A good brief is two or three pages and takes an afternoon. It will change your quotes more than any negotiation.
Start with the problem, not the solution
"We need an app" is a solution. "Our three branches each keep their own appointment book, so we double-book and we cannot see capacity across the group" is a problem, and it invites a developer to tell you the cheapest thing that solves it. Sometimes that is an app. Often it is less.
Describe today honestly
Including the undignified parts. The spreadsheet, the WhatsApp group, the notebook behind the counter, the one person who knows the pricing. Those are the real requirements. A system that ignores them gets worked around within a month.
List the roles
Every type of person who touches the system, and three to five things each one does. This single page prevents more disputes than anything else in a project.
Name your integrations
Not "our accounting system" but the actual product and version, and whether it has an API. If you do not know, say you do not know and flag it as something to investigate, with a budget line held against it.
Say what success looks like
A number if you have one. Cut double bookings to zero. Take 30 percent of orders through our own channel instead of the marketplace. Reduce the time to produce a monthly report from two days to an hour. This tells a developer which parts deserve the effort, and it gives you a way to judge the result that is not an opinion about the design.
State your constraints
Budget range, deadline and why, any technology you are committed to, and who has to approve. Developers design within constraints. Hidden constraints surface late and expensively.
Where the money goes inside a project
Clients sometimes ask why a system costs what it does when the screens look simple. A rough split of where the hours go on a typical business system:
| Phase | Share of effort | What happens |
|---|---|---|
| Discovery and specification | 10 to 15 percent | Roles, workflows, edge cases, the exceptions nobody mentioned |
| Design | 10 to 20 percent | Screens, states, the empty and error versions of everything |
| Core build | 35 to 45 percent | The part everyone pictures when they imagine the cost |
| Integrations | 10 to 20 percent | Payments, messaging, whatever else it must talk to |
| Testing and fixing | 10 to 15 percent | Finding what breaks before your customers do |
| Deployment and handover | 5 to 10 percent | Getting it live, and making it maintainable by someone else |
Two things stand out. The core build is less than half, which is why quotes based only on feature count come in low and then overrun. And the states nobody asks for, the empty screen before there is data and the error screen when something fails, are a real part of design, not an afterthought. A system judged professional is usually one whose error states were designed.
Security is a budget line, and here is what it buys
Security gets discussed as though it were a single item you either bought or did not. It is a set of decisions, each with a cost, and the right level depends on what you are holding.
The baseline, which should never be optional
Encrypted connections everywhere, passwords stored so that a database leak does not hand over accounts, protection against the standard injection and scripting attacks, rate limiting on anything that can be guessed at, and backups that someone has actually tested by restoring one. This is included in any competent build and should not appear as a line item. If it does, you are being charged for doing the job properly.
The next level, for systems holding personal data
Two-factor authentication for staff accounts, an audit log recording who looked at what, role-based permissions enforced on the server rather than hidden in the interface, and a defined retention period after which data is deleted rather than kept forever. Add perhaps 10 percent to a build.
The permissions point deserves emphasis because it is the most common real flaw I find in systems built cheaply. Hiding a button is not a permission. If the underlying request still works when someone types the address directly, the data is public to anyone curious enough, and that is the kind of thing that gets discovered by a customer rather than by you.
The level for regulated or high-value data
Penetration testing by someone other than the people who built it, encryption of specific fields at rest, strict separation between environments so that nobody develops against live customer data, and an incident plan written before you need it. This is a meaningful cost and it is proportionate when you are holding medical records, legal files or identity documents.
One cheap habit worth adopting at any level: never let real customer data sit on a developer's laptop. Anonymised copies for development cost almost nothing to produce and remove an entire category of risk that has nothing to do with your code.
Speed is a commercial line item
Page speed is filed under technical quality and it belongs under revenue. On mobile data, every additional second before a page becomes usable loses a share of the people who arrived. If you are paying for ads, you are paying for those people twice: once to bring them, and once by losing them.
The cost of building something fast is mostly the cost of not building it slowly. Images at the right size and format, a font strategy that does not blank the text while loading, and restraint with third-party scripts. That last one is where most sites lose their speed. A chat widget, two analytics tools, a heatmap recorder and a social pixel will each add weight, and together they frequently outweigh the entire site.
I removed every render-blocking third-party request from my own site and the measurable difference was larger than any single optimisation I made to the code. If you take one technical argument from this article into your next project, make it this one: ask what each external script costs you, and make someone justify it.
Three projects, and where the money went
Abstract ranges only go so far. These are real systems with the reasoning that set their price.
A multi-tenant CRM in Arabic
Omnixtrack serves many companies from one deployment, with Arabic as the primary interface and a published Android app alongside the web system. The feature list reads like any CRM: contacts, deals, tasks, reporting.
The cost was not in the feature list. It was in the word "multi-tenant". Every query in the system carries a constraint that one company's data can never surface in another's, and that constraint has to hold in reporting, in search, in exports and in the mobile API, including on the paths added a year later by someone who was not in the original conversation. Getting it right is an architectural decision made in week one. Getting it wrong is discovered by a customer.
Then the Arabic. Not a translation layer but a system designed right to left, with Arabic search that copes with how people actually type, and reports that render correctly when numbers sit inside Arabic sentences.
A single-company English CRM with the same features would have cost roughly half. The multiplier was isolation and language, neither of which appears on a feature list.
A restaurant taking back its margin
A restaurant working through delivery marketplaces was handing over a percentage of every order. The brief was effectively arithmetic: build ordering and table reservations we own, and the commission stays with us.
The build was deliberately small. A menu with modifiers matching how the kitchen actually assembles a dish, delivery zones, opening hours including the exceptions, order status the customer can follow, and a kitchen display that does not rely on someone watching a browser tab. No loyalty scheme, no app, no account system beyond a phone number. All three were discussed and all three were postponed.
That restraint is the point. The project paid for itself on commission saved, and the features that were cut can be added from the savings, funded by a system that is already working. The opposite order, building everything first and hoping it pays, is how restaurant software projects die.
A law firm where confidentiality was the architecture
Isgha in Riyadh needed a public platform for a practice of lawyers, consultants, arbitrators and notaries, organised so that a visitor can find the specific service they need rather than reading a list of everything the firm does. Four service branches, each with its own tree underneath.
The expensive decisions were not visible on the public side. Intake had to collect enough to evaluate a case without collecting material the firm would rather not hold before an engagement exists. Everything a potential client types has to be treated as confidential from the moment it is submitted, which affects where it is stored, who can see it and how long it is kept.
A visually similar site for a business with no confidentiality obligation would have cost considerably less. The difference went into the parts nobody sees, which is frequently where the difference goes.
Questions worth asking before you sign
Short list. Ask all of them, to everyone quoting, including me.
- Who writes the code, and will that person still be on it in month three?
- Can I log into something you built that is live and in use?
- What is explicitly not included in this price?
- How do we price a change once we start?
- What happens in the first month after launch, and is it already paid for?
- Who owns the code, and which accounts will be in my company's name?
- What does maintenance cost per year, and what does it cover when nothing is broken?
- If I want to move to another developer in two years, what would I be handing them?
The last question is the one that separates suppliers. Someone building for your benefit answers it easily. Someone building for dependence changes the subject.
Working out whether it was worth it
Software is bought on a feeling and judged on a feeling, which is how businesses end up with systems nobody can defend and no way to decide what to fund next. The arithmetic is not complicated, and doing it before you commission anything also tells you how much you should be willing to spend.
Count the hours the system removes
Take the process you are replacing and count the hours it consumes each week across everyone who touches it, including the part where someone retypes data from one place into another. Multiply by a loaded hourly cost. That annual figure is the first part of what the system is worth.
A clinic group spending nine hours a week coordinating appointments across branches, at a modest loaded rate, is spending several thousand dollars a year on the coordination alone, before counting the revenue lost to double bookings. Against an $8,000 booking system, the payback is visible within the first year, and after that it compounds.
Count the revenue that currently leaks
Harder to measure and usually larger. Enquiries that arrive and never get followed up. Orders placed through a marketplace that charges a commission. Customers who leave because the thing they wanted was not bookable at eleven at night. Quotes that took three days to produce and arrived after the client had chosen someone else.
Pick one of those, estimate it honestly and conservatively, and you usually find a number that dwarfs the build cost. The restaurant example earlier is the cleanest version: commission is a known percentage of a known volume, so the calculation is arithmetic rather than estimation.
Count what you are buying that is not money
Some of the value does not convert cleanly. Knowing your real numbers at the end of a month instead of guessing. Being able to answer a customer immediately. Not depending on one person who holds the pricing in their head and who will eventually leave. These are real and they are why businesses with good systems make better decisions than businesses without them, but do not let them carry the whole justification. If the hours and the revenue do not get you most of the way, the project is probably too big for the problem.
Set the budget from the value, not from a feeling
Once you have an annual figure, a reasonable rule is to spend up to about one year of it on the build, and expect to recover it within eighteen months. If a project cannot clear that, either cut it down until it can or leave it alone. This is also the most effective way I know to resist feature creep during a build: every addition has to earn its place against the same number.
The first ninety days after launch
The part of a project that decides whether people adopt the system, and the part most often left out of a plan.
In the first week, real usage finds what testing did not, because real users do things that nobody thought to try. Expect a list. A system that produces no list in week one is a system nobody is using. Keep the developer engaged and fix things quickly while attention is high.
Through the first month, watch where people abandon a flow and where staff go back to the old method. That second one is the important signal. If someone is still keeping the spreadsheet, the system is missing something they need, and finding out what is more valuable than any feature on the roadmap.
By the third month you have enough real data to make the next decision properly, and it is almost never the thing that was next on the original list. This is the strongest argument for building in stages: phase two designed with three months of evidence is a far better project than phase two designed on day one alongside phase one.
Budget for this period explicitly. A fortnight of developer time held in reserve for the month after launch is the highest-return money in the whole project, and it is the first thing cut when a budget gets tight.
Who you hire changes the price more than what you build
The same brief, given to four kinds of supplier, produces four very different numbers. None of them is wrong. They are different businesses with different cost structures, and the trick is matching the supplier to the job rather than hunting for the lowest figure.
| Supplier | Relative cost | Best for | Main risk |
|---|---|---|---|
| Local agency in the Gulf | Highest | Large budgets, procurement requirements, a need for someone in the room | You may be paying for account management rather than engineering |
| Regional studio | Middle | Most business systems | Quality varies enormously; verify, do not assume |
| Senior independent developer | Middle to low | Clear projects where one experienced person can own the whole thing | Capacity, and what happens if they disappear |
| Lowest-bid marketplace | Lowest | Tiny, disposable, well-specified tasks | You will usually pay a second time |
I work as the third of those, so read the table with that in mind. The honest version of my bias: an experienced individual is the right answer when the project fits in one head, and the wrong answer when it genuinely needs four people working in parallel to a deadline. Ask any supplier, including me, which of those your project is.
What a low bid is actually pricing
A quote at a fifth of everyone else's is not generosity, and it is usually not inexperience either. It is a different scope, and the parts that were removed are predictable: no Arabic beyond machine translation, no admin panel worth using, no error handling, no tests, no documentation, and a build on a template whose licence you will discover later.
The cost appears in year two, when you want a change and nobody can safely make one. I have been handed systems like this to rescue, and the rescue is frequently more expensive than the original build would have been from someone competent. If you have a small budget, the right move is a smaller project built properly, not a big project built badly.
The five ways software projects actually go wrong
Across 42 delivered systems and a reasonable number of rescues, the failures repeat. Almost none of them are technical.
Nobody wrote down what it has to do
The brief is a conversation, the developer builds their interpretation, the client sees something else in their head, and the gap is discovered at demo. The fix is cheap and almost nobody does it: before building, write the user roles, the things each role can do, and the five screens that matter. Two pages. Both sides sign it. Projects with that document behave differently from projects without it.
The scope grew without the price or date moving
Each addition is small and reasonable. Twenty of them is a different project. Keep a written change log with a cost and a time impact per item, even when the impact is zero, so the trade is visible while it is being made rather than argued about at the end.
The real workflow was never understood
A system is built to match the process described in meetings, then meets the process the business actually runs, which includes the exception everyone handles manually and nobody mentioned. This is the main reason internal systems get rejected by the staff who have to use them.
The prevention is to watch someone do the job for an hour before designing the screen that replaces it. I do this on every operations project and it has never failed to turn up something that was not in the brief.
Launch was treated as the finish line
Nobody budgeted for the month after launch, when real usage finds the things testing did not. That month always exists. Plan for it, keep the developer engaged through it, and the system settles. Skip it and the first week's problems become permanent features of how your staff feel about the thing.
The handover never happened
The project ends, the developer moves on, and nobody else can deploy a change. Ask for repository access in your own account, a written deployment process, environment details recorded somewhere other than one person's laptop, and a short recorded walkthrough. Put it in the contract as a deliverable tied to the final payment. It costs nothing to ask at the start and is nearly impossible to get afterwards.
Ownership: the question to settle before you pay anything
Who owns the code when it is finished? The answer should be you, in writing, and the repository should live in an account your company controls from day one, with the developer invited to it rather than the other way around.
Two things to check beyond the headline. First, any third-party licences the build depends on, such as a purchased theme or a commercial component, and whether that licence transfers to you. Second, the accounts: domain registrar, hosting, payment gateway, analytics, app store listings. These should be registered to your company's email, not your developer's, even when the developer sets them up. Recovering a domain registered to a contractor you have fallen out with is a genuinely painful process, and I have watched a business lose weeks to it.
When not to build anything
A pricing article should probably end with an argument for spending money. Here is the opposite, because it will save some readers more than anything else above.
Do not build custom software when an existing product does the job at a fraction of the cost and your objection is cosmetic. Do not build a platform to validate an idea you could test with a landing page, a phone number and two weeks of ads. Do not rebuild a working system because it looks old, when a design refresh costs a tenth as much. Do not commission anything while the person who will own it internally is unavailable for the next two months, because the project will drift and you will pay for the drift.
The projects that go well share one trait: somebody in the business needed the thing badly enough to make decisions quickly. When that person does not exist yet, waiting is cheaper than starting.
What I would do with your budget
Three honest allocations, at three common budget levels, for a business trying to generate work rather than just be online.
Under $2,000
One landing page built properly, tracking wired up, and the rest spent on getting traffic to it. No multi-page site. At this level the goal is to find out whether the offer works, and a single page answers that faster and cheaper than eight pages do.
$2,000 to $8,000
A proper bilingual site with the structure to rank, plus the one piece of functionality that removes the most manual work from your week. For a clinic that is booking. For a restaurant it is ordering. For a consultancy it is a structured intake that qualifies enquiries before they reach you. One piece, built well, beats four built thinly.
$8,000 to $30,000
Now a real system is in reach, and the decision shifts from what to build to what to build first. Pick the process that costs your business the most hours per week, automate that, and ship it before touching anything else. The second phase gets funded by the first phase working, which is a much better position than funding everything on faith.
Getting a number for your own project
If you want a quote worth comparing, bring these to the first conversation and you will get one that holds:
- Who uses the system, and what each of those people can do
- What you do today, including the spreadsheet or the WhatsApp group that is currently holding the business together
- The external systems it has to talk to, by name
- Whether money moves through it, and which payment methods your customers use
- Whether you invoice in Saudi Arabia
- Roughly how many users and how many transactions a month
- Your actual budget range, and the date something has to be working by
The budget question makes people uncomfortable and it should not. A developer who knows your range designs to it. A developer who does not either guesses high and loses the work, or guesses low and delivers something thin. You are not revealing your position in a negotiation; you are letting someone solve the right problem.
I quote on this basis, with the exclusions written down and a fixed price where the scope allows one. If you want to test the ranges in this article against your own project, send me the brief and I will tell you where it lands, including the cases where the answer is that you should buy a platform instead of hiring me.