Choosing who builds your software matters more than choosing what you build. The same brief produces four different numbers from four suppliers, three of them may hand you something that works, and one will hand you something you pay for twice. This article is about telling them apart before you pay rather than six months afterwards.
I am writing it as a party to the transaction, so read it that way. I work as an independent developer, and I will say plainly in the relevant section when I am the wrong choice for your project. What follows is drawn from 42 delivered projects, a reasonable number of systems handed to me to rescue after someone else built them, and clients who came to me after a bad experience and explained in detail what happened.
Four kinds of supplier, and why none of them is best
The common question is which kind is best, and the correct answer is that each kind has a project that suits it. The error is not picking a kind; it is picking a kind that does not fit your project.
The local agency
The most expensive, and some of what you pay for is real: a team that does not stop when one person is ill, formal project management, somebody you can meet, and the ability to satisfy formal procurement if you are dealing with a large organisation that wants a commercial registration, a guarantee and a standard contract.
The real risk is paying for account management rather than engineering. In some agencies a meaningful share of the money goes to a layer between you and the developer. Its value is genuine on a large project with several teams and close to nothing on a project one experienced developer could carry.
When it is the right choice: a large budget, a hard deadline needing several people in parallel, formal procurement, or several internal stakeholders who need coordinating.
The regional studio
The middle, and where most of the serious work in this region sits. A team of three to twenty, cheaper than an agency and with broader capacity than an individual.
The risk is that quality varies enormously within this bracket. Two studios of the same size and price can be one excellent and one a template factory. There is no way to tell from a website or a proposal, only from inspecting real work and calling past clients, which I will detail shortly.
The experienced independent developer
Middle to low on cost and highest on direct communication. You talk to the person writing the code with no intermediary, decisions happen in minutes rather than in a meeting, and the person who understood your problem is the person building it.
The two risks are clear: capacity, because they cannot double speed by adding people, and what happens if they disappear. I will explain how to protect yourself from the second in the ownership section, and it is protection you should ask of any kind of supplier rather than only of an independent.
When it is the right choice: a clear project that fits in one head. When it is wrong: a project that genuinely needs four people working in parallel to a hard date. Ask me which of those yours is, and ask every supplier the same question.
Lowest-bid marketplaces
The cheapest, and genuinely suited to small, precisely specified, disposable tasks: editing a page, installing a template, fixing a defined bug. A poor choice for anything you will own for two years.
The reason is not that the developers there are bad; some are excellent. The reason is that the selection mechanism itself rewards the lowest bid, and the lowest bid is won by removing things you cannot see in the proposal and that surface in year two.
What a low bid is really pricing
A quote at a fifth of everyone else's is not generosity and usually not inexperience either. It is a different scope, and the removed parts are predictable, because I have seen them repeat in every system I was handed to rescue.
- Arabic as machine translation, or an English interface with Arabic bolted on that an Arabic reader spots immediately
- A nominal admin panel your team cannot work from, so they come back to the supplier for every change
- No error handling, so any unexpected case gives the customer a blank screen or a technical message
- No real permissions, where hiding the button is the whole of the protection
- No tests and no documentation, so every later change is a gamble
- No tested backups
- A build on a purchased template whose licence is in the developer's name rather than yours
- Nothing at all after launch, so the first defect in week two becomes an invoice
The cost appears in year two when you want a change and nobody can safely make one. And I say this as someone who has been handed systems like this: the rescue is frequently more expensive than the original build from someone competent would have been, because the rescuer has to understand what was built and then rebuild parts of it while they are occupied with live data.
So if your budget is small, the right move is a smaller project built properly rather than a large project built badly. One excellent landing page beats eight poor pages, and a system that covers one process well beats one that covers five thinly.
What a high quote is pricing
Fairness requires the other side too, because a high price is not evidence of quality.
Some of what you pay in a high quote is real: experience that lowers risk, documentation that lets you change supplier, handling of cases you had not thought of, and people available when you need them. Some of it is not: a management layer you do not need, an office in an expensive location, a risk premium caused by a weak brief, and the cost of sales and proposals loaded onto the projects that are won.
That last premium deserves a pause because it is larger than people expect. A supplier who sends ten proposals and wins three loads the cost of ten onto three. You cannot prevent that, but you can shrink the risk premium with one thing: a clear brief. A supplier who does not know what they are building prices the bad version of your project rather than the likely one, and you pay that difference for your own vagueness.
How to inspect a supplier before you pay
These checks need no technical expertise, and they are more accurate than any certificate or portfolio.
Ask for a working system and try it yourself
Not screenshots, not a demo video, not a gallery. Ask for a link and a login to something live and in use. Then do the things a tired user does: leave a field blank and submit, type Arabic into a field expecting English, press the button twice quickly, close the page mid-process and come back, open the site on your own phone on mobile data rather than wifi.
A well-built system behaves reasonably in all of those. One built in a hurry breaks within two seconds, and you will have learned what you needed to know with no technical argument.
Watch how they handle your brief
My single best signal. A supplier who reads your brief and comes back with questions, some of which you had not considered, has thought about your project. One who comes back with an instant quote and a copied feature list has not read it.
And treat hard questions as a good sign rather than an irritation. An awkward question in week one is far cheaper than the same question after three months of building. A supplier who asks about your exceptions, about who approves, and about what happens on a cancellation is one who has built real systems before.
Ask about a project that failed
A question I like because its answer reveals more than an entire portfolio. Anyone who has worked for years has a project that broke, ran late, or ended badly. Someone who tells it in detail and says what they learned has actually done the work and thought about it. Someone who says every project succeeded is either very new or not being straight, and both are useful to know.
Speak to a past client rather than reading a testimonial
Testimonials on websites are positive by construction and carry no information. Ask for a past client's number and call, and ask two specific questions: how was communication when there was a problem, and did the project finish on the agreed time and price?
The answer to the first matters far more than the second, because problems will happen on your project too, and the difference between a good and a bad supplier is not the absence of problems but how they behave when one arrives. Ask a third question if you can: would you work with them again? Hesitation is information.
Ask for something they should refuse
A check I use and it works every time. Ask for a feature you do not actually need, something large and shiny: AI that writes your content, a mobile app for a project that does not need one, a system that handles a million users when you have a hundred.
A supplier who tells you it is not worth your budget and explains why is working in your interest. One who adds it to the quote immediately and prices it is working in theirs. And a clearer version of the same question: which item would you suggest cutting from my request, and why? Whoever answers that seriously is who you will get the best result from for your money.
Ask who writes the code
An entirely fair question that embarrasses the people it should. Agencies that win work with a senior and deliver with a junior exist in every market, and that is not a flaw in itself if the junior works under real supervision. So ask: who writes the code, what is their experience, and will they still be on it in month three? Asking for names in the contract is not excessive on larger projects.
How to compare quotes that look incomparable
The commonest error I see on the buyer's side: gathering three quotes and comparing the numbers. The three quotes are for three different projects, and comparing their numbers is meaningless.
Build the table yourself
Write a table with a row per item and a column per supplier, and a mark against what is explicitly included. The rows I always use:
- Roles and what each role can do
- The admin panel, who will use it, and whether it was tested with them
- The Arabic version: who writes it, and whether Arabic search is included
- Integrations by name, and whether an API was verified for each
- Migration of your current data, and whether it gets a trial run before handover
- Permissions and the audit log
- Reports by name, and whether they export
- The number of design revisions included
- Who writes the content and who supplies images
- Hosting, domain and annual fees, and who pays them
- The support period after launch, and the definition of a defect versus a new request
- Training and documentation
- Code ownership, and whose name the accounts are in
- Explicit exclusions
The table turns the comparison from a number into information. In half the cases where I have done this with a client it turned out the more expensive quote was actually the cheaper one for everything it included, and in the other half it turned out the expensive one was selling things they did not need.
Send the table to every supplier
A step that takes minutes and changes the outcome. Send the same table to all three and ask each to fill it in. Whoever fills it honestly, including writing "not included" against items, is the supplier you will work comfortably with. Whoever ticks every row with no detail either did not read it or is selling you a promise.
Be wary of the quote that arrives fast
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 serious estimate needs reading and questions, and sometimes a second call. If an instant quote arrives, ask what basis it was calculated on, and the answer will tell you.
Ask each supplier for two quotes
A simple move with a large effect. Ask every supplier for two quotes: one for the full scope as you described it, and one for the smallest version that solves your core problem. The gap between them tells you three things: whether they understood which parts are essential, whether they can think in phases, and how much of your request was deferrable in the first place.
The supplier who provides both in detail and explains why they deferred what they deferred is who you will get the best result from for your budget. The one who provides only the full quote and says everything is essential either did not analyse your project or prefers the larger invoice.
A second benefit for you: in most cases you will find the smaller quote is actually enough, and that you will decide phase two after three months of real use with evidence rather than deciding it now by guesswork.
The exclusions clause: the strongest check
If you take one thing from this article, take this. Ask every supplier to write in their quote what is not included.
A supplier who writes down what they will not do has thought about your project, because knowing the boundary requires understanding the whole. A supplier who writes only what they will do has written a brochure. Beyond that, the exclusions clause is what prevents every argument you would otherwise have, because most disputes on software projects are not about the quality of what was delivered but about something the client assumed was included and the supplier assumed was not.
Examples of entirely legitimate exclusions that should be written down: content writing, supplying images, buying fonts or templates, translation, payment gateway onboarding, first-year hosting, training beyond two sessions, and any integration with a system that has not yet been inspected. Each of those may or may not be included, and what matters is that you know which.
Ownership: what to ask for before the first payment
This section protects you from every kind of supplier rather than only the bad ones. And it is settled at the start or it is never settled.
The code
You own it on full payment, written into the contract. And the repository lives in an account your company controls from day one, with the supplier invited to it rather than the other way around. That arrangement costs nothing at the start and is close to impossible to obtain after a disagreement.
Licences
Ask directly: is there a template or a commercial component in this build, whose name is the licence in, and does it transfer to me? A template bought in the supplier's name means you are using something you do not own, and you may find yourself with no right to its updates or no right to use it if the relationship ends.
The accounts
The most overlooked item and the most painful. The domain registrar, hosting, payment gateway, analytics, app store listings, the email account. All of them should be registered to your company's email rather than your supplier's, even when the supplier is the one who created them.
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 while being unable to edit or move its own site. The prevention is one line in the contract and five minutes at each registration.
Handover as a deliverable
Ask for this in the contract, tied to the final payment: repository access in your own account, a written deployment process in a file, environment details recorded somewhere other than one person's laptop, and a short recorded walkthrough of how the system runs and is maintained.
And the question that separates suppliers more than any other: if I want to move to another developer in two years, what would I be handing them? Someone building for your benefit answers easily and enumerates. Someone building for dependence changes the subject or says it is premature.
The contract: clauses that protect both sides
A good contract on a software project is not protection from the supplier but a document that prevents disputes before they exist, and it protects them from you as much as you from them. This is what I put in my own contracts.
A definition of delivery
What does finished mean? A list of testable things rather than a general sentence. "The system works" is not a definition. "A user can create a booking, amend it, cancel it, and receives a confirmation" is one both sides can judge.
A defect warranty period
A period after launch in which defects are fixed at no charge, because they are defects in paid work. Thirty days is reasonable and sixty is better. And the clause that must be clear is the distinction between a defect and a new request: if the system does not do what delivery specified, it is a defect; if it does and you want something else, it is a new request. That definition alone prevents months of argument.
Change pricing
An hourly or daily rate agreed in advance for out-of-scope work. Agreeing the number in advance turns every change from a negotiation into a decision, and prevents the supplier becoming someone looking for reasons to say no.
Milestone payments
Do not pay everything up front, and do not expect a supplier to work for months on nothing. A split along the lines of 30 percent at the start, 40 at a working system you can use, and 30 at launch keeps both sides committed. Tie each payment to something you can see and test rather than to a date.
A right to stop
What happens if either side wants to stop the project midway. The fair formulation is that the client pays for work performed and receives what was built and documented, and the supplier does not withhold paid work. Having this clause makes both sides more comfortable starting, because it turns the project from a leap into steps.
Confidentiality
Mutual. Your data and your customers' data are not used or displayed outside the project without written permission, including displaying the project in the supplier's portfolio. I ask for explicit permission before adding any client to my portfolio, and some clients decline, which is entirely their right.
Ownership and handover
As in the previous section, written down, and tied to the final payment.
The signals that say walk away now
These are signals I have seen repeat with clients who came to me after a bad experience, and all of them were visible before signing.
They refuse to write exclusions
The strongest signal. A supplier who refuses to write down what is not included is keeping the vagueness because it serves them. And if they say everything is included, ask about content writing, payment gateway onboarding and translation, and you will find the boundary.
They promise a date without asking about your constraints
Anyone who tells you they will finish your system in three weeks before asking about your integrations, your roles and your size does not know what they are building. A date given without questions is a date that will be missed, and you will be the one blamed for the delay.
They treat Arabic as trivial
A signal specific to our market and an important one. A supplier who says Arabic is just a translation file has not built a real Arabic system. Ask about Arabic search specifically: what happens if a user types a word without its final hamza and expects to find the correct spelling? The answer sorts people immediately.
They do not want you talking to whoever writes the code
On a small or medium project that refusal is unjustified. On a large one it may be reasonable for communication to go through a project manager, but being prevented entirely from knowing who builds it is a signal.
They pressure you with time or an expiring discount
Fast-sales tactics have no place in a project you will own for years. Anyone who needs pressure to convince you knows their quote does not survive a calm comparison.
They agree to everything
The signal most clients misread, because agreement feels comfortable. A supplier who agrees to every request with no discussion of impact or cost will discover the problem after building, and it will then be resolved by cutting something or by missing a date. The supplier who says "that is possible but it will cost this much and delay that much, do you actually want it?" is working with you.
Their quote is far below everyone and they will not explain why
A low price is not a flaw in itself, and the supplier may be in a lower-cost market or have an existing foundation that speeds them up. The signal is not the price but the refusal to explain it. Ask: what makes your quote lower by this margin? A good answer is specific; a bad one is a compliment.
The brief: the cheapest money you will spend
A clear brief lowers the quotes you receive more than any negotiation, and the reason is arithmetic rather than psychological: a fixed price contains a risk premium, and a supplier who does not know what they are building prices the bad version of your project. Every line of clarity removes part of that premium.
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 supplier to tell you the cheapest thing that solves it. Sometimes that is an app. Often it is less.
Describe reality honestly, including the undignified parts
The spreadsheet, the WhatsApp group holding the business together, the notebook behind the counter, the one person who knows the pricing. Those are the real requirements, and a system that ignores them gets worked around within a month.
List the roles
Every type of person who touches the system, with three to five things each one does and one thing it must not do. That page prevents more disputes than anything else in the project.
Name your integrations
Not "our accounting system" but the actual product and version, whether it has an API, and whether you have credentials for it. If you do not know, say you do not know and flag it as an item to investigate with a budget held against it, which is more honest than leaving it unmentioned.
Say what success looks like, with a number
Cut double bookings to zero. Take 30 percent of orders through our own channel instead of the marketplace. Reduce the time to produce the monthly report from two days to an hour. That tells a supplier 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 budget
The question that makes people uncomfortable and is the most useful thing you can do. A supplier who knows your range designs to it and tells you what fits. One who does not either guesses high and loses the work or guesses low and delivers something thin. You are not revealing a negotiating position; you are letting someone solve the right problem.
Add your three hardest cases
The appendix that changes quotes more than anything else. "A customer reserved a unit, paid half, then asked to transfer the reservation to his brother" is more useful to a supplier than twenty lines of specification. It is also the fastest way to discover who understood your problem.
How to behave during the project
The part the client owns alone, and its effect on the outcome is larger than people expect. I say this from the other side: the projects that come out better are not the ones with the best-paying clients but the ones with the fastest deciders.
Name one person who decides
One person with authority to approve who answers within a day. A committee meeting fortnightly will produce a worse and more expensive project, because supplier time spent waiting is time you pay for, either directly or in a higher fixed price next time.
Inspect early rather than at the end
Ask for a demo every week or two and try the system yourself each time. An observation in week three is cheap; the same observation in week twelve means rework. A client who says they will see it when it is finished is buying a surprise.
Keep a written change log
Every addition or amendment written into a list with its cost and time impact, even when the impact is zero. This protects both sides: it stops you being surprised by an invoice, and it stops the supplier absorbing twenty small additions for free until they reach a point where the answer to everything is no.
Say no to new ideas until after launch
Ideas will arrive during the build and some will be good. Put them in a list for phase two rather than inserting them now. Discipline is the smaller reason: an idea assessed after three months of using the system is assessed with evidence, and half the ideas that look essential today disappear once you see how people actually use it.
Supply your content
Content is often 15 to 20 percent of a project and the leading cause of a delayed launch. If you can write your own copy and supply real images you save money and get better content, because you know your field. If you cannot, say so at quoting time rather than at launch.
Ask for a written summary after every meeting
A habit that takes two minutes and prevents half the disputes. After every call, a summary is written of what was agreed, what remains open, and who is responsible for what, sent by one side and confirmed by the other. It does not matter who writes it, so write it yourself if the supplier does not.
The benefit is not proving anything against anyone but exposing a different understanding early. More than once I have written a meeting summary and had a correction come back from the client, and the gap between what I understood and what they meant would have cost two weeks had it surfaced after the build.
Set a response deadline for yourself too
A clause worth putting in the contract: the supplier responds within one working day, and the client responds to decision requests within two. The second protects you more than you expect, because it makes your own delay visible before it becomes a delivery delay you get blamed for.
What to do if the project goes wrong
This section exists because articles about choosing a supplier end at signing, and life does not.
The early signals
Replies slowing from days to a week. Demos cancelled or postponed. A new person on the project you were not told about. General answers to specific questions. A payment requested before delivering what it is tied to. Any one of those is explicable; two together is a signal.
Write instead of calling
The first step when concerned: move communication into writing. Write what you understood from the last conversation, what you expect, and by what date. A serious supplier will correct or confirm; a struggling one will evade, and either way you know where you stand. Writing has a second benefit: it turns vagueness into commitment.
Ask for the code now rather than later
If the repository is not in your account yet, this is the moment. Ask for it as a routine step rather than as an accusation. A supplier who refuses to hand over paid code is telling you what will happen later, and you now know it rather than learning it in three months.
Split the remaining payments smaller
Propose splitting what remains into smaller payments tied to nearer deliverables. A supplier who is actually working will agree, because it guarantees them continuous income. One who refuses reveals that the problem is not cash flow.
Do not wait too long
What costs clients most in these situations is not the struggling supplier but the waiting. Every extra month is more money paid and more code nobody else understands. If a month passes with no felt progress after you have written, asked and split, then stop, count your loss and move. A contained loss is cheaper than trying to rescue a relationship that will not produce a system.
And before you stop
Get three things: the code in your account, the credentials for accounts, domain and hosting, and any real data in the system. Those three determine whether the next supplier starts where the last one finished or from zero, and the difference may be half of what you already paid.
When not to hire anybody
A section against my own immediate interest, and the most useful part of this article for some readers.
Do not hire a developer if a ready-made platform does the job and your objection is cosmetic or concerns one annoying step. A store with forty products and standard shipping does not need custom software, and a content site with a blog does not need a system. Live with it for a year, spend the difference on bringing in customers, and you will then know precisely what the platform prevents you from doing.
Do not hire anyone to validate an idea you could test with a landing page, a phone number and two weeks of advertising. One page answers whether your offer works faster and cheaper than a full platform, and the gap between them can be tenfold.
Do not start while your own process is unsettled and changes every month, because programming a confused process sets the confusion in concrete and makes changing it more expensive. Organise it on paper until it holds still for three months, then build it.
Do not start while the person who will own the project internally is unavailable for the next two months. The project will drift and you will pay for the drift in late decisions and scope growing without direction. Waiting in that case is cheaper than starting.
The projects that go well for me share one trait: somebody in the business needed the thing badly enough to make decisions quickly. If that person does not exist yet, no supplier you choose will make a difference.
Pricing models and which suits your case
Choosing the wrong model for your situation costs more than choosing the wrong supplier, and that is not an exaggeration. There are three.
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 suppliers like to admit: a company site, a store, a booking system you can describe completely.
What you need to understand is that a fixed price contains a risk premium, because the supplier is absorbing the uncertainty. Its failure mode is change: once the scope is fixed, every addition is a negotiation. So agree in advance how changes are priced, before you need one.
Time and materials
You pay for hours or days. An honest model 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 supplier you can verify. Ask for three things: a weekly cap that is not exceeded without approval, a demo every week or two, and the ability to stop at the end of any month. Anyone who resists all three is telling you something important.
And I would add a fourth request that gets skipped: a statement of hours broken down by task rather than a single total. Not out of suspicion but because the detail shows you where the money goes, and you will usually find a task consuming more than it deserves and decide to cut it.
Monthly retainer
A fixed monthly amount for ongoing work and support. The right model after launch and once the system matters to the business. Expect to pay 10 to 20 percent of build cost per year, and more if your system has many integrations, because other people's systems change and yours has to keep up.
The question to ask: what does the retainer cover when nothing breaks? A good answer includes security updates, monitoring, backups and a defined number of development hours. A bad answer is "support", which means you pay monthly for the privilege of being allowed to report problems.
The hybrid I prefer
A fixed price for the first version with a written scope and explicit exclusions, then a monthly retainer after launch, then time-based pricing for later undefined phases. It gives the client a number they can put in a budget for the known part, and gives the supplier fairness on the unknown part.
A local supplier or one in another country
A practical question in the Gulf, because a lot of the work is executed from Egypt, Jordan, East Asia and Eastern Europe, and the price difference is large enough to be worth considering.
What you genuinely gain
Price first, and the difference is real and does not necessarily mean lower quality. Second, market depth: developers in Laravel and the well-known web languages are available in large numbers across the Arab region, so you are not tied to one person and you can change supplier.
What to watch
Time differences are not a problem inside the Arab region and become a real one with East Asia or the Americas. If the shared working hours are fewer than four a day, expect every question to take a day, and that accumulates.
Language matters more than time. A supplier who does not read Arabic will not notice that the translation is clumsy, nor that Arabic search does not behave as a user expects, nor that the layout breaks in a particular case. If you choose a supplier who does not read Arabic, hold budget for a linguistic and functional review by someone who does.
Market understanding is third. Mada, e-invoicing, local payment methods and the expectations of a Gulf buyer are things someone who has worked here knows and someone else learns at your expense. That is solvable: tell them explicitly what applies and require it in the written scope.
The legal side
A cross-border contract is harder to enforce, and that is a fact to manage rather than ignore. The practical protection is procedural rather than legal: small payments tied to deliverables, the code in your repository from day one, and the accounts in your name. Those three protect you more than any penalty clause you will never litigate.
My conclusion
Choose on competence and communication first and location second. A competent supplier far away beats a weak one nearby, and a competent one nearby who understands your market beats both if the budget allows. And do not choose on price alone in either direction.
How to evaluate a technical proposal you do not understand
The situation where most buyers feel they have no tools. They do, and these questions need no expertise while revealing a great deal.
Ask why this technology
Do not ask what the technology is but why they chose it for your project. A good answer talks about your project: the depth of the developer market, what your system needs, and what you will own for five years. A bad answer talks about the technology itself in general terms.
Ask who else could maintain this
An excellent question because it exposes decisions that serve the supplier rather than the client. A rare technology or an in-house framework means you are tied. A good answer names something for which developers are easy to find in the region.
Ask how many records they tested on
The question that sorts those who thought about performance. Do not ask whether the system is scalable, because the answer will always be yes. Ask about the data volume it was tested against, and ask for the test to be against a size resembling yours in two years rather than yours on launch day.
Ask how permissions are enforced
Ask for proof that a user on a limited role cannot reach a higher role's data even when the direct address is known. Hiding a button is not a permission, and a supplier who built it properly answers this in minutes.
Ask what happens on failure
What does the user see if the payment gateway drops mid-transaction? What happens if email sending fails? Where is the enquiry recorded if everything fails? These questions reveal who has built real systems, because failure handling is the first thing cut from a hurried build.
I learned this question from my own site specifically. Email delivery stopped working for a period, and I lost real enquiries before I noticed, because email was the only path. The rule I built afterwards and now require in every system: the enquiry is written into the system first and then the email is sent. If the email fails you have lost a notification rather than a customer.
Ask who monitors the system after launch
Is there monitoring that tells somebody if the site goes down or something breaks, or will you find out from a customer calling? This is a very cheap addition and most quotes leave it out.
AI-written code: what it means for you as a buyer
A subject that became real in 2026 and has to be discussed honestly. Most developers today, including me, use AI tools when writing code. The question is not whether your supplier uses them but how.
Why this is not a flaw
The tool speeds up writing the repetitive parts, and those are a large share of any system. A developer who uses it well produces faster at the same quality, and that is in your interest because it lowers cost and shortens the timeline. Refusing the tools is no more evidence of quality than refusing to use a framework.
Where it becomes a problem
When the developer is merely a conduit. Code produced without understanding works in the ordinary case and breaks on the exception, is usually longer and more convoluted than it needs to be, and carries assumptions nobody inspected. More dangerously, it may carry security problems that look fine to an inexpert eye: permissions checked in the interface rather than on the server, or queries without input validation.
And that kind of code compounds an old problem: code nobody understands. The difference is that with a purchased template the developer at least knows they did not write it, whereas generated code is assumed to be understood and is not.
How to check this without technical expertise
Do not ask whether they used AI; the answer is yes for nearly everybody and the question is useless. Ask questions that reveal understanding:
- Explain how permissions are enforced in this system, and prove a limited role cannot reach a higher role's data when the direct address is known
- What happens if the payment gateway drops mid-transaction, and where is the order recorded?
- How many records did you test the system against, and what is its slowest page and why?
- What architectural decision did you make on this project that you regret?
Someone who built with understanding answers all of those with detail and examples. Someone who copied without understanding answers in generalities or describes what the tool does. The last question in particular cannot be coached, because it requires memory of a real decision.
The clause I would add
Ask in the contract that the code be understandable and maintainable by another developer, and that it be delivered with deployment documentation and an explanation of the architecture. This was always important and is now more so, because the ease of producing code today means the volume of code nobody understands grows faster than it used to.
And ask for a performance test against a data volume resembling your size in two years. Quickly produced code tends towards patterns that work on little data and collapse on a lot, and this test catches them before you discover them in year two.
A supplier comparison table
A summary of the above in a form you can come back to.
| Supplier | Relative cost | Best for | Main risk | What to ask of them specifically |
|---|---|---|---|---|
| Local agency | Highest | Large budgets, formal procurement, several teams in parallel | Paying for account management rather than engineering | The names of whoever writes the code, in the contract |
| Regional studio | Middle | Most business systems and serious websites | Quality varies enormously between studios | A working system you can log into, and a call with a past client |
| Experienced independent | Middle to low | A clear project that fits in one head | Capacity, and what happens if they disappear | The code in your repository from day one, and deployment docs |
| A small team of freelancers | Middle | A project needing design and development together | Nobody coordinating, so you become the coordinator | One named person responsible for delivery |
| Lowest-bid marketplaces | Lowest | Small, precisely specified, disposable tasks | You will usually pay a second time | A scope written precisely enough to need no interpretation |
I work as the third of those, so read the table with that in mind. The honest version of my bias I wrote at the start and will repeat: 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 hard date.
Who does what: design, development, content and marketing
Conflating these four is a common cause of disputes that have nothing to do with anyone's competence. They are different skills, and it is rare for one person to be good at all of them.
Design
How the system looks and how a user moves through it. A good designer draws the screens and their states, including the empty screen before there is data and the error screen when something fails. Those states are the difference between a system described as professional and one that is not.
What to expect: a defined number of revisions written into the quote. Open-ended revisions end either in a surprise invoice or an irritated designer, and both are bad.
Development
Building what was designed so that it works and holds up. A good developer will put questions to the design, some of which may feel like obstruction: what happens if the name is very long? What happens if the list is empty? What if the user presses twice? Those questions are in your interest.
Content
The words and images, usually 15 to 20 percent of the project and the leading cause of a delayed launch. It is neither a developer's skill nor a designer's, and if written by either it may be weak. The Arabic version in particular: machine translation is immediately obvious to an Arabic reader and damages trust more than its absence would.
The decision I recommend: write your own content if you can, because you know your field and you will save money and get better text. If you cannot, hire a writer as a separate line rather than leaving it to the developer.
Marketing and search visibility
And here is the most expensive conflation. Part of search work belongs inside the build with no extra line: a logical and durable URL structure, a title and description per page within the right lengths, heading levels with no skips, structured data, a sitemap, correct linking between the Arabic and English versions, and a load speed that was measured rather than hoped for.
Another part is a separate, ongoing service: choosing the terms you target, writing the content that targets them, building pages for specific search intents, and following results monthly.
So if you find a line item called SEO in a quote, ask which of the two it is. If it is the first, you are being charged for doing the job properly. If it is the second, it is a legitimate item and it should be monthly rather than one-off.
A note specific to our market: original Arabic content is still far less competitive than English in most professional fields. A business that writes ten real Arabic pages about its specialism can reach results it would not reach with double the advertising budget. It is the cheapest advantage available in this market, and most businesses do not use it because they copy English content and translate it.
Who you actually need
On a small or medium project, a competent developer with reasonable design sense is enough, with you writing your own content. On a project that depends on how it looks, such as a brand compared against international products, you need a real designer. On a project that depends on bringing in traffic, you need someone working on content monthly after launch. The error is paying for all four on a project that needs one, or paying for one on a project that needs three.
One supplier or splitting the work between two
A question that comes up often: do I hire a separate designer and developer to get the best of each, or one supplier who does both?
When splitting is right
When design is a substantive part of the product rather than a means of presenting it. A brand compared against international products, an app whose experience is its advantage, or a platform that will be shown to investors. In those cases a specialist designer adds what a developer with reasonable design sense does not.
The condition that makes splitting work: one named person responsible for the final result. If there is not one, you will be that person, and you will find yourself relaying notes between the two and arbitrating technical disagreements you have no tools for.
When splitting is wrong
On most small and medium projects. The reason is that the handover point between designer and developer is where things get lost: the designer draws a screen with no empty state and no error state, so the developer has to invent both. Or draws a screen that cannot hold a long Arabic name. Or forgets how the screen looks at 360 pixels wide.
Each of those becomes a conversation between three parties, you among them, with the designer finished and unwilling to revise and the developer unwilling to make a design decision. That is what delays split projects more than anything else.
The arrangement I recommend
If you split, make the developer a party to the design stage rather than a recipient of it. One review by the developer on the screens before they are approved saves weeks, because they will ask about the states that were not drawn. And write into the designer's contract that they are committed to two revision sessions after development begins.
If you do not split, ask the single supplier about design specifically: ask to see screens from their projects on a phone rather than only on a desktop, and look at whether empty and error states were designed. Whoever designs the error state is whoever thought about the user.
And content is a forgotten third party
A warning to add: splitting the work between a designer and a developer while leaving content with no owner is the best-known cause of a project that stays finished and unlaunched for months. Name who writes the content and by what date before any design begins, because designing on real text differs from designing on placeholder text, and the gap between them is a full re-layout.
Realistic timelines
Timelines are a cost, because a system that launches four months late means four months of business it did not support. These are estimates from the date of signing, assuming decisions arrive within two 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 | 8 to 20 weeks | Discovering how the business really works |
| Mobile app | 6 to 16 weeks plus review | Store review and a late backend |
The shared pattern: delays come from the client side far more often than the supplier side, and almost always from a decision nobody owns. If you want a project to finish on time, name one person who can approve things and give them the authority.
Payment gateway onboarding deserves its own warning. It involves paperwork, verification and a wait, and has nothing to do with whether the code is ready. I have watched finished projects sit unlaunched for three weeks because nobody began the gateway application until the build was done. Start it on day one.
How to run the relationship weekly
A simple rhythm that prevents most problems, and it is how I work with my clients.
One short weekly call
Twenty minutes at a fixed time. What was finished, what is next, and what is blocked waiting on a decision from you. The third item is the most important and has to be explicit, because most delay in projects is waiting on a decision the client did not know was needed.
A staging link that is always current
Ask for an environment you can open at any time to see the latest state. Not screenshots, not clips. It prevents surprises and turns an observation from an argument into something visible.
One list for feedback
One place where every observation is written with its priority, not scattered WhatsApp messages or email. An observation in a conversation gets forgotten; in a list it gets done or declined with a written reason.
Test it yourself rather than by proxy
Try the system yourself at every stage rather than relying on a member of staff. You are the one who knows the exceptions and you are the one who will notice something missing.
Separate defects from new requests in how you speak
A habit that improves the relationship considerably. When you write an observation, say whether it is something not working as agreed or something new you want. A client who separates the two gets better treatment, because the supplier knows what is owed and what is a priced request.
The signals of an excellent supplier
I wrote the warning signs, and fairness requires the other side. These are what I see in suppliers who deliver good work consistently.
They shrink your request
The strongest positive signal. A supplier who looks at your list and says these three can be deferred and this one you genuinely need, explaining why in each case, is thinking about your outcome rather than their invoice. One who agrees to the whole list and prices it is thinking about the invoice.
They ask about your hardest cases
A supplier who asks you to tell them the exceptional case you handle by hand has built real systems before, because they know the project is judged by those rather than by the ideal path.
They write the exclusions without being asked
A quote that arrives with a section on what is not included, unprompted, comes from a supplier who knows where disputes happen and prefers to prevent them.
They offer you a cheaper option
A supplier who tells you a ready-made platform is enough, or that a design refresh beats a rebuild, or that one page beats a site, loses money in that conversation and gains a client for years. That is the kind worth keeping.
They say they do not know
A signal many people underrate. A supplier who says they have not worked with this system before and needs a day to inspect its API before quoting is more honest than one who confirms everything is possible. Complete confidence on every question is not experience, it is selling.
They give you what you need to leave them
A supplier who puts the code in your account from day one, writes deployment documentation and registers the accounts in your name is building for your benefit. They know they are making it easy for you to leave, and they do it because a client who can leave and does not is the best reference they will ever have.
They raise maintenance at the start
A supplier who mentions annual maintenance and its cost in the first proposal is thinking about the system's lifetime. One who does not mention it until you ask has either not thought about it or is deferring an uncomfortable conversation until after payment.
Client mistakes that wreck projects
This section is about your side, and I write it because most projects that turned out worse than expected were not the supplier's fault.
Not naming a decision maker
The single biggest mistake. A project needing approval from three people who meet weekly will run late and cost more, and the waiting time is paid by the client either directly or in a higher price. Name one person and give them real authority.
Changing direction mid-build
Changing a fundamental decision after things have been built on it is not an amendment but rework. Small changes are normal and expected; changing the thing the system tracks or who uses it is a different project. If you must, know that you are paying twice, and do not blame the supplier for the invoice.
Hiding your constraints
The real budget, the real deadline and why, the technology you are committed to, and who has to approve. Suppliers design within constraints, and a hidden constraint surfaces late and expensively. Hiding the budget in particular does not get you a better price, it gets you a worse design.
Only testing at the end
A client who says they will see it when it is finished is buying a surprise. An observation in week three is cheap; the same one in week twelve is rework you pay for in money or in delay.
Deferring content
The leading cause of delayed launches on website projects. Words and images are not a final step but an input to design, and a site built on placeholder text gets re-laid-out when the real text arrives.
Comparing quotes by number alone
Covered in detail earlier, and repeated here because it is the client mistake with the highest cost. The three quotes are for different projects, and the table you build yourself turns them into something comparable.
Sending someone without authority to negotiate
Sending an employee to negotiate a project they cannot decide on lengthens everything and relays incomplete information in both directions. If the owner or the manager will decide, they should attend at least the first meeting.
Protecting your data during the project
An item that gets skipped because attention is on what will be built, and during the project the supplier gets access to your real data unless you organise that.
Do not hand over real data for development
The supplier needs data to build and test, and does not need your real customers' data. Anonymised copies, where names, phone numbers and email addresses are replaced with generated values while the structure and volumes are kept, cost almost nothing to produce and remove a whole category of risk.
Ask for that explicitly at the start of the project. And if there is a stage that genuinely needs real data, such as migration or investigating a problem, time-box it, limit the access, and record who saw it.
Accounts in the supplier's name rather than your passwords
Do not give the supplier the password to your administrative account. Create an account in their name with the permissions they need, so you can disable it in a second when the project ends and so you can tell from the audit log who did what.
That applies to everything: hosting, the domain, the payment gateway, analytics, email. A shared account means you cannot end access except by changing the password and informing everybody, and that does not happen.
Confidentiality is mutual
A confidentiality agreement covering your data and your customers' data, and also covering what the supplier sees of your numbers and operations. It is a normal clause and not strange to request, and anyone who refuses to sign one on a project touching customer data is telling you something.
And add a point that gets forgotten: permission to display the project in their portfolio. I ask for that permission explicitly from every client before adding them, and some decline, which is entirely their right. If your project is sensitive, write the prohibition into the contract rather than discovering your name on your supplier's site.
At the end
A three-line list executed in half an hour: disable the supplier's accounts, delete any data copies they hold with a written confirmation, and rotate any shared keys or passwords. This is a routine step rather than an expression of distrust, and you should ask for it as part of handover.
Dealing with formal procurement
A section for anyone working in a large organisation or selling to a government or semi-government body, because the rules differ.
Formal procurement asks for things unrelated to the quality of the programming: a commercial registration with a matching activity, statutory compliance certificates, sometimes a bank guarantee, a standard contract that cannot be amended, and a long payment cycle. That practically removes independent developers and small studios from the equation, not because they are less competent but because they do not meet the administrative conditions.
So if you are bound by that cycle, know that you are paying a real administrative premium, and that the supplier will load the cost of the guarantee and the late settlement onto you. Account for that in your budget rather than comparing their quote against an independent's who does not go through the same cycle.
And there is an arrangement that works and is widely used: an administratively qualified supplier contracts with the organisation and an experienced developer executes beneath them. That is acceptable and common, and what you should ask for is to know who actually executes and to have their name in the contract, and not to be paying the administrative premium twice.
Maintenance: choosing who looks after it
A decision taken carelessly because it comes after launch when attention has moved on. It determines the lifetime of your system.
Whoever built it is not necessarily whoever maintains it
Staying with the builder is usually better, because they know the system and need no time to understand it. But that is not a law. If your experience with them on communication was poor, or their post-launch rates are unreasonable, or they disappeared for weeks, moving is legitimate and available, provided you took the code, the documentation and the accounts.
What a maintenance contract should cover
Security updates for the framework and dependencies, monitoring that tells you if something stops, backups with a periodic check that they restore, defect fixing, a defined number of small development hours per month, and an agreed response time for critical problems.
That last item is worth insisting on: what is the response time if the system goes down on a working day? And on a weekend? A written answer turns the contract from talk into a commitment.
What you should not be paying for in maintenance
Fixing defects in work already paid for, during the warranty period. New features called maintenance. And "support" with no definition. Ask for a periodic statement of what was actually done under the retainer, because a retainer that produces no statement becomes, after a few months, an invoice nobody can account for.
Deferred maintenance is a deferred invoice
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 as an upgrade that cannot be done incrementally and whose duration nobody can estimate.
How to move a project to a new supplier
A practical section for anyone in that position now, and it is more common than people assume.
Gather what you own before any conversation
Before you talk to a new supplier, gather: the code, the hosting and domain credentials, a copy of the database, any documentation, and a list of external accounts and who owns them. The more complete that list, the lower the price and the faster the transition.
If some of it is with the previous supplier, ask for it as a routine step in a polite written message. Most suppliers will hand over what has been paid for. For anyone who refuses, record the request in writing and move on with what you have rather than losing months to a dispute.
Ask for an inspection before any decision
Do not ask for a rebuild quote. Ask for a paid inspection that determines whether the code is sound and workable, sound but undocumented, or poor and worth replacing. An inspection costs a small fraction of a build and is the best money you can spend in this situation.
The three outcomes differ completely in cost. The first means you pay only for amendments. The second means a week or two of understanding and documenting and then working normally. The third means a new project, and then know that a rebuild should cost less than the original rather than more, because the requirements are now known: you have a working system telling you exactly what it does.
Be wary of the supplier who says rebuild immediately
A signal worth doubting. A supplier who looks at your system and says on the first call that it needs a full rebuild may be honest, or may prefer building from scratch because it is easier for them and a larger invoice. So ask for detail: what specifically is the structural problem, what cannot be fixed, and why.
I did exactly this inspection for three aviation clients who came asking for new sites with full rebuild budgets. I found the underlying structure sound and the real problem in presentation, speed and content. All three left with improved versions of their own sites for a fraction of what they had been quoted. The inspection cost them little and saved them a great deal.
Migrate in stages if the system runs real operations
If replacement is the decision, there is an overlooked middle path: 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, that is usually what I recommend.
Three real cases
These are situations I have been through. I write them because the pattern in them is more useful than any list.
The client who paid twice
A business asked for a system and chose the lowest quote by a wide margin. Something that worked in a demo was delivered. After four months of real operation three problems appeared: the data was not isolated between branches so a branch manager saw another branch's figures, the admin panel was unusable so the team went back to spreadsheets in parallel, and the code had no documentation so it could not be safely changed.
The amount they paid on the rescue exceeded what they would have paid for a correct build at the start. The reason is that the rescuer has to understand what was built first, then rebuild parts of it while they are occupied with live data that cannot be lost, which is harder than building on empty ground.
The lesson: the price difference was not a discount, it was a deletion. And the one question that would have exposed it before signing: what is not included in this price?
The client who saved by refusing
A restaurant client arrived with a complete list: online ordering, a mobile app, a loyalty scheme, customer accounts, and accounting integration. The driver was clear and calculable: the commission delivery marketplaces take from every order.
What we built was far smaller: a menu with modifiers matching how the kitchen works, delivery zones, opening hours with their exceptions, order status the customer can see, and a kitchen display that does not depend on somebody watching a browser tab. The other three were discussed and deferred.
The project paid for itself on commission saved, and the deleted features became addable from the savings, funded by a system already working. The opposite order, building everything first and hoping it pays, is how restaurant software projects die.
The lesson: a supplier who refused items from your request may be more use to you than one who agreed to everything.
The client who needed an inspection, not a project
Three aviation clients, each arriving with a full rebuild budget asking for a new site. The inspection showed the structure was sound and that what they were actually unhappy about was speed, presentation and content.
So they left with improved versions rather than new ones, for a small fraction of the amount. I could have taken the rebuild budget and built from scratch, and the result would have been good and needlessly expensive.
The lesson: before you decide to build something new, pay a competent person to tell you whether you need it. And if a supplier tells you that you do not need what you are asking for, that is the strongest evidence you will get that they are working in your interest.
Estimated cost by project type
So you can tell whether the quote you received is in range or outside it. These are my ranges in US dollars for 2026, assuming a clear brief and a single decision maker.
| Project | Range | What moves you up it |
|---|---|---|
| Landing page | $600 to $2,000 | Writing the offer, tracking, testing two versions |
| Bilingual company website | $1,200 to $4,500 | More than two languages, a careers section, branch pages |
| Custom e-commerce store | $3,500 to $15,000 | Contract pricing, a product configurator, POS integration |
| Booking platform | $4,000 to $20,000 | Multiple resources, payment, several branches |
| Business system | $6,000 to $40,000 | Multi-tenancy, integrations, a field app |
| SaaS platform | $12,000 to $60,000 | A full billing lifecycle, tenant isolation |
| Mobile app | $5,000 to $30,000 | Two native platforms rather than a shared codebase, offline working |
| Design refresh on an existing structure | $800 to $3,500 | Page count, and whether the structure needs cleaning |
| Inspection of an existing system with a report | $300 to $1,200 | System size and absence of documentation |
That last row is the cheapest and the most overlooked. An inspection at three hundred to twelve hundred dollars may save you a twenty thousand dollar rebuild, and it is the first thing I recommend to anyone who has a system and is thinking of replacing it.
If the quote you received is far below the bottom of the range, ask about the exclusions. If it is above the top, ask specifically why, and it may be a good reason such as a compliance requirement, a data volume, or needing a team to hit a date.
How to negotiate properly
Negotiating on price alone is the worst way to negotiate a software project, because a supplier who lowers the price without changing the scope will compensate by removing something you will not see until launch.
Negotiate on scope rather than on the number
Ask: what can be removed or deferred to bring the price into my range? Every good supplier respects that question and answers it in detail. And you get a lower price for less rather than a lower price for the same promise.
Negotiate on phases
Ask to split the project into two phases with two separate contracts. You pay the first, see the result, and decide the second with evidence. That lowers your risk and lowers the supplier's risk premium at the same time, so it is a gain for both rather than a concession by one.
Negotiate on payments rather than the total
If cash flow is your constraint, say so. Many suppliers will accept more and smaller payments at the same total, which solves your problem without a discount that deletes something from your project.
Offer something in exchange for the discount
Things that genuinely lower a supplier's cost and that you can offer: written content and ready images, a fast decision committed to in the contract with your response window, permission to display the project in their portfolio, and a reference for other clients. Each of those deserves a real discount because it reduces their work or brings them work.
What not to negotiate on
Permissions, the audit log, backups, data migration, and the first month after launch. If those five are cut for price you will pay for them later several times over. Cut features rather than structure.
What to look at in a supplier's portfolio
A portfolio is less useful than people assume, because pictures tell you nothing about the code underneath. But there are things to read from it.
Are the projects still running
Open the links. Projects that have vanished or become parked pages or different sites are not necessarily a bad signal, since clients change direction. But if most of them did not survive, ask why.
Is there variety, or the same project repeated
Ten projects that look identical usually means work on one template. That is not a flaw if what you want is that template, and it is a large flaw if your project needs something different.
Are there systems, or only websites
A brochure site and a business system are different skills. Someone whose whole portfolio is brochure sites may be excellent at those and have no experience of systems, and the reverse holds too. So look in their portfolio for something resembling your project in kind rather than in appearance.
Do they say what they built specifically
A case that says "we developed the website" is less useful than one that says what the problem was, what was built, and what the result was. A supplier who writes about their projects in detail thinks about their work.
Ask for a case resembling yours
Rather than browsing the whole portfolio, ask: what is the closest project you have built to a case like mine, and what was different about it? The answer tells you about their experience and their honesty at the same time.
How to build a long relationship with a good supplier
If you find a competent supplier who communicates well, keeping them is cheaper than searching again. That is not a pleasantry but arithmetic: every new supplier needs time to understand your business, and you pay for that time.
Pay on time
The simplest thing with the largest effect. A supplier paid on schedule puts your project at the front of their work; one chasing payments puts it at the back. That is not a punishment but the cash flow reality of any small business.
Batch your feedback
Ten small observations in one weekly message is more use than ten messages in a day. The supplier can arrange their work around it, and repeated interruption costs time that does not show in an invoice but does show in delivery speed.
Separate defects from requests
Mentioned earlier and repeated because it improves the relationship most. A client who says "this is not working as we agreed" and "this is something new I want, how much?" gets different treatment from one who calls everything a defect.
Give them visibility of what is coming
If you know you have a second phase in three months, say so. A supplier who knows work is coming builds differently: they leave the right space in the architecture, document more, and price better because the risk is lower.
Come back to them for an inspection before deciding
If you are considering an expansion or a change, ask them before you decide. A supplier who knows your system can tell you in an hour what your decision will cost, and that hour sometimes saves a whole project.
And keep your ability to leave
A healthy long relationship is not dependence. The code in your repository, the accounts in your name, deployment documented. That makes staying a choice rather than a necessity, and a good supplier is comfortable with it, because a client who can leave and does not is the best reference they will ever have.
If your budget is below every quote
A common situation that means neither that the suppliers are overcharging nor that you should pick the cheapest. These are the real options, best first.
Cut the scope to a first version that works
Always the best option. Ask every supplier: what is the smallest version that solves my core problem and fits my budget? You will be surprised how far the number falls when what can be deferred is removed. Half a system built properly can grow; a complete system built badly has to be replaced, so you pay twice.
Split it into two phases with two contracts
Pay the first from this quarter's budget and the second from next quarter or from the first phase's return. That solves the cash flow problem without deleting anything, and many suppliers welcome it because it secures them continuous work.
Use a ready-made platform temporarily
If what you need is generic, a ready-made platform on a monthly subscription is far cheaper than an incomplete build and launches this week. Use it for a year to learn exactly what it prevents you from doing, then build that part specifically. That turns guesswork into knowledge for the price of a subscription.
Supply what you can supply yourself
Write your content, provide real images, clean your data before migration, and make your decisions within a day. All four genuinely lower the supplier's cost and deserve a real discount, and they are better than asking for a bare reduction.
And what I would not advise
Do not take the far cheapest quote hoping it is the same thing for less. Do not cut permissions, backups, data migration or the first month after launch for price. And do not defer the whole project six months to save, because the cost of deferral is not zero: it is every month you worked by hand and every enquiry you lost because there was no way to receive it.
If what you need is a repair rather than a build
A final section, because many readers are in this position while believing they are in a different one.
If you have a site or a system that works and you are unhappy with it, define the complaint precisely before asking for a quote. It looks dated? That is a design refresh at a fraction of a rebuild. It is slow? That is a performance analysis measured in days, and the cause is usually a small number of queries rather than the size of the server. It brings you no customers? That is a content and search visibility problem rather than a code problem. Every change takes weeks and breaks something? That is the one complaint that genuinely justifies a rebuild.
And the supplier you ask for a rebuild quote will give you a rebuild quote. So ask for an inspection first, at three hundred to twelve hundred dollars, and ask that the report answer one question plainly: what is the cheapest thing that fixes my specific complaint?
I ran that inspection for three aviation clients who came with full rebuild budgets, and all three left with improved versions of their sites for a small fraction of the amount. I could have taken the budget and built from scratch, and the result would have been good and needlessly expensive. A supplier who tells you that you do not need what you are asking for is the strongest evidence that they are working in your interest, which is what this whole article condenses to.
A final checklist before signing
Print it or copy it, and go through it before you pay the first instalment to any supplier.
- I tried a working system myself and logged into it with a real account
- I called at least one past client and asked about communication during problems
- I have a written quote with roles and integrations named
- I have a written section on what is not included
- I know who writes the code and whether they stay on the project
- I know who writes the Arabic content
- Migration of my current data is a line with a price, and it gets a trial run
- Permissions and the audit log are included rather than deferred
- Payments are tied to deliverables I can test rather than to dates
- The code will be in a repository in my company's name from day one
- The domain, hosting and payment gateway will be registered to my company's email
- The defect warranty period is written down, and the defect versus new request definition is written down
- The hourly or daily rate for changes is agreed in advance
- The annual maintenance cost is known and what it covers is written down
- The first month after launch is included and paid for
- I know what I would hand another developer if I wanted to move in two years
- I have named one person on my side who owns the decision and they are available
The last four items are the ones most clients skip, and they are cheapest to request in advance and most expensive to retrofit. The final item is about you rather than the supplier, and it determines the project's outcome more than any other line on the list.
Where to start
If you are about to choose a supplier, the shortest route to a good decision is this: write the two-page brief, add your three hardest cases, build the comparison table, and send it to three suppliers asking each to fill it in and write their exclusions. What comes back will sort itself.
And a final note about time. Most clients spend a week gathering quotes and a day reading them. The correct order is the reverse: spend a day writing a clear brief and your three hardest cases, and a week reading what arrives and talking to whoever sent it. A clear brief lowers the risk premium in every quote you receive, and the conversation reveals who understood your problem. The two hours you spend calling a past client are more use than ten additional quotes.
If you want me to be one of the three, send the brief and I will reply with an estimate, with what I think the correct first version is, and with what I recommend deferring. In the cases where the answer is that you should buy a ready-made platform, or improve what you already have rather than build something new, I say so, because a project you did not need is worse for me than it is for you.
And if you are mid-project and it is going wrong, start with the three steps in that section: move communication into writing, ask for the code and the accounts now, and propose smaller payments tied to nearer deliverables. All three will tell you where you really stand within a week.