How do I know whether I need software at all?

Ask whether the work is already happening reliably by hand, and whether the only thing missing is throughput, consistency or an audit trail that a human process structurally cannot deliver at your volume. If the answer is yes, that is a genuine software need. If the work is not happening reliably now, software will not make it happen, because a tool does not supply the thing that is actually missing.

What is the most common wrong reason to build?

That nobody has written the process down. Software encodes a single path, so if the process currently exists as three informal versions in three people's heads, the build will encode whichever one the loudest person described in the discovery call. Everyone else then works around the tool. The project was a documentation exercise wearing a software costume, and it becomes much harder to fix afterwards.

How do I test for the undocumented process problem?

Try to write the process down end to end, including every exception, without a developer in the room. Then ask two other people who do the work to read it and mark what is wrong. If you cannot produce a version all three agree on, you are not ready to build, and doing that exercise is worth more than any discovery workshop a supplier will sell you.

How do I test for that one?

Ask who the named person is who keeps it accurate, and what happens if they do not. If there is no name, or no consequence, you have a staffing and accountability question rather than a software one. That is worth knowing before you spend, because the software will be blamed for the gap it did not create and cannot close.

Should I build something for a one-off task?

Almost never. Building reusable software for something that happens once means paying for reusability nobody will use. A one-time data migration, a single large onboarding, a report needed for one board meeting: a script, a manual pass, or somebody doing it carefully by hand is cheaper and faster. Ask whether this genuinely recurs on a schedule or whether you are making a one-time event feel permanent.

My biggest client wants a system. Should I build it?

Ask what happens when that client leaves. Custom software built around one counterparty's requirements becomes a maintenance liability the moment they leave, renegotiate, or change their own systems, and you are left maintaining logic that serves nobody. If nobody else would ever use it, a manual process or a service commitment to that one client is usually the better answer.

What should I try before building anything?

A spreadsheet, an off-the-shelf point tool, a no-code automation, or simply changing the process. That last one is free, is the most commonly correct answer, and is the one nobody in a sales conversation will suggest, because nobody is paid to recommend it. Reassigning a task, removing an approval step that exists out of habit, or agreeing one naming convention resolves a surprising share of system requests.

When does a spreadsheet actually stop working?

Later than people claim, and for different reasons than they claim. Google publishes a ceiling of one hundred simultaneous editors, which almost no SME reaches, so the concurrency argument is largely a myth. What genuinely breaks is structural: no granular access control, no meaningful audit trail of who changed what, formulas that fail silently, and no validation to stop bad data entering.

What are the real signals to move off a spreadsheet?

You need to know who changed a figure and when, and cannot find out. Different people need different levels of access and the file gives you all or nothing. The process now crosses departments and things get lost at the handoff. Or an error rate has started costing more than the fix would. Those are structural limits rather than size limits.

How big can a spreadsheet actually get?

Larger than most businesses will ever need. Microsoft publishes an Excel worksheet limit of just over a million rows by 16,384 columns, and Google publishes a limit of ten million cells across a Sheets file, with a beta raising that further. So if somebody tells you your spreadsheet is too big, ask what the actual number is. Usually the real problem is structure rather than size.

What about no-code automation tools?

They are a genuine middle ground and worth trying before commissioning anything. The major automation platforms publish tiered pricing starting in the low tens of dollars a month, with free tiers adequate for testing whether an automation is worth having at all. If a no-code version of your idea saves real time for a few months, you have both solved the problem and produced a much better specification.

What is the risk of building the wrong thing?

Not just wasted money, which is recoverable. The process gets locked into software, staff start working around a tool that does not fit, and you need a second project to undo the first. That is why the diagnostic is worth doing before the build rather than after, and why we are not going to quote you a project failure statistic. The mechanism is more useful than a number.

What should a good supplier ask me before quoting?

What the process looks like today, who does it, how often, what happens when it goes wrong, and who would be accountable for the new system. A supplier who asks only about features is scoping a build. One who asks about the process is trying to work out whether you need one. The questions asked before the quote tell you a great deal about what you are buying.

Is root cause analysis a real discipline or consulting jargon?

It is a named, standard technique in the business analysis body of knowledge, which is to say it is an established practice rather than something invented by a consultancy to sell workshops. The detailed material sits behind a professional membership, so we are not quoting it. The principle is simple enough without the reference: establish the cause before designing the solution.

What if the process changes constantly?

Then encoding it in software now is expensive, because every change becomes a development request. That is not automatically a reason not to build, and it is a reason to build the stable parts and leave the volatile parts as a human process for longer. A tool that is right about the parts that never change is more useful than one that is wrong about everything.

Does compliance change the answer?

It can, because some obligations effectively require structured, auditable records rather than a spreadsheet somebody edits. If you have a regulatory reason to prove who did what and when, that is a genuine driver toward a system. Check what applies to you specifically with the relevant authority rather than assuming, because obligations in the UAE are frequently phased and depend on entity size.

What about UAE e-invoicing, does that force a system?

It may, and the timing depends on your entity rather than on a single national date. The programme is phased and size-dependent, so the right move is to check your own position and date with the Ministry of Finance rather than acting on a general claim. What we would say is that a compliance deadline is a legitimate reason to build, unlike most of the reasons in this article.

How do I tell a genuine need from a wish?

A genuine need is recurring, has enough volume to pay back a build, sits on a process that is actually understood, and has somebody accountable for using it correctly. The clearest signal is that the work is already being done reliably in a stopgap, and the only missing piece is throughput, consistency or auditability. A wish usually fails on at least two of those four.

What if I try the cheap version and it does not work?

Then you have lost very little and gained a specification, which is the genuinely valuable outcome. Knowing exactly where a spreadsheet or an off-the-shelf tool broke tells a supplier far more than any requirements document you could write from imagination, because it is evidence rather than a guess. Almost every good build we have seen started life as a stopgap that stopped coping in a specific, describable way, and the description of that failure is what made the build worth doing.

Is a diagnostic just a sales call with a fee?

It is if the conclusion is always to build, which is why the test of one is whether it can conclude otherwise. Ask directly whether the engagement can end with a recommendation not to proceed, and what that recommendation would look like. A supplier who cannot describe the circumstances in which they would tell you not to build is selling a build.

What does a diagnostic cost?

A short diagnostic engagement starts from around AED 1,500 with us. That covers the process as it actually runs, what the realistic alternatives would cost, and a straight recommendation which explicitly includes the option of doing nothing at all. A fuller discovery that produces a written specification you own outright starts from around AED 4,000. Final pricing depends on scope. These are our own figures rather than a market survey, so treat them as one reference point among several.

Will you actually tell me not to build?

That is what the engagement is for, and you should hold us to it rather than take it on trust. Ask at the outset what would make us recommend against building, and get the answer before you commission anything. A supplier who says yes to everything is not being agreeable, they are declining to give you the one thing you are paying for.

What is the single best question to ask myself?

If somebody handed me this software tomorrow, fully built and free, who in my business would keep it accurate and what happens if they do not? If there is no name and no consequence, the software will not fix anything. That question costs nothing to ask, takes a minute, and prevents more wasted spend than any other on this list.

What if my team keeps asking for a system?

Ask them what specifically they cannot do today, rather than what system they want. Teams describe solutions because that is easier than describing problems, and walking the request backwards often reveals a handoff nobody owns, an approval nobody needs, or a report that already exists and nobody knows about. That conversation frequently produces a change you can make this week at no cost, and occasionally produces a genuine case for building that is far better specified than the original ask.

Does this advice change for a startup building a product?

Substantially, because there the software is the business rather than a support tool. This article is about internal problems where software is one possible answer among several, and where a process change or an off-the-shelf tool competes on equal terms. If you are building something to sell, the equivalent question is whether anybody actually wants it, and that gets answered by putting something in front of real customers rather than by process analysis.

What should I do first, today?

Write the process down and show it to two people who do the work. That single exercise resolves a meaningful share of software requests before anyone quotes anything, because it either produces a clear specification or reveals that the business does not yet agree on how the work is done. Both outcomes are worth more than the afternoon it costs.

StrategyAugust 23, 2026

Is This Actually a Software Problem? Five Cases Where Building Makes It Worse

SKIMBOX Team

A process nobody has written down, a task that happens twice a month, a job nobody is accountable for. Software encodes whatever it finds, so building on top of any of those makes the problem permanent and expensive rather than solved.

Most of the software that gets built inside UAE businesses is not bad software. It works, it does roughly what the specification said, and it was delivered by people who knew what they were doing. It just solves a problem the business did not actually have.

That is a harder failure to spot than a broken build, because nothing visibly goes wrong. The tool ships, a few people use it for a month, and then everyone quietly drifts back to the spreadsheet and the WhatsApp group. Nobody calls it a failure. It just sits there, being maintained, until somebody asks what it costs and the conversation gets awkward.

This article is the diagnostic we run before quoting a build. It is deliberately written to talk you out of projects, because that is the part of the process nobody sells you.

Five cases where building makes it worse

These are not the only ways a project goes wrong, but they cover most of what we see. Each has a test you can run this afternoon without hiring anyone.

The process nobody has written down

The symptom is that nobody in the business can produce a current, written description of how the work actually runs. Ask three people and you get three answers, all delivered with confidence.

Software forces a single encoded path. If the underlying process is really three competing informal versions, held together by tribal knowledge and exceptions nobody wrote down, the build encodes whichever version the loudest stakeholder described in the discovery call. Everyone else works around it. You have now spent real money making one person's mental model mandatory for the whole company.

The test: write the process down end to end, including every exception, without a developer in the room. Then hand it to two people who do the work and ask them to mark what is wrong. If you cannot get to a version all three agree on, this is a documentation project wearing a software costume.

The volume is too low

The task happens a handful of times a week. Sometimes a handful of times a month.

Automation has a fixed cost that does not care how often you use it. You pay to build it, then you pay to keep it working as the platforms and browsers and integrations underneath it move. Below a certain frequency the fixed cost never gets paid back, and you end up maintaining software that saves less time than the maintenance consumes.

The test: multiply how often it happens by how long the manual version takes by a realistic hourly cost. Compare that against the build plus fifteen to twenty-five per cent of build cost per year for maintenance, which is the figure our app maintenance guide uses.

Do the arithmetic properly, because the intuition is usually wrong in both directions. A task that takes twenty minutes and happens four times a month is roughly sixteen hours a year. Even valued generously, that is a few thousand dirhams of staff time annually, against a build plus a maintenance line that recurs whether or not anybody uses the tool. The payback runs into a decade, and the software will not survive that long before something underneath it changes and forces a rewrite.

Flip the same sums for a task that takes two minutes but happens two hundred times a day and the answer inverts completely. That is the case where a build is not just justified but overdue. The point is not that automation is bad, it is that frequency, not annoyance, decides it, and annoyance is what usually gets measured.

It is a people problem in a systems costume

The stated need is a system to track something. The real situation is that nobody is accountable for the thing being tracked, or the person responsible is not doing it, or two departments each believe the other owns it.

A tracking system does not create accountability. If nobody reliably updates the shared spreadsheet today, nobody will reliably update a purpose-built application either. What the application does is make the gap much more visible and considerably more expensive to have created.

The test: if we handed you a perfect system tomorrow, who is the named person who keeps it accurate, and what happens if they do not? No name, or no consequence, means the problem sits in staffing and management rather than in tooling.

It happens once

A one-time data migration. A single large customer onboarding. A report somebody needs for one board meeting.

Building reusable software for a non-recurring task means paying for reusability that nobody will ever use. A script, a manual pass, or one person doing it carefully by hand is cheaper, faster and does not leave anything behind to maintain.

The test: will this exact task recur on a schedule, or are you trying to make a one-time event feel permanent by giving it a system?

One customer asked for it

A feature, or an entire platform, exists because one client or one partner requested it, and that relationship is the only reason it is on the table.

Custom software built around a single counterparty's requirements becomes a liability the moment that counterparty leaves, renegotiates, or changes their own systems. You are left maintaining bespoke logic that serves nobody, and removing it turns out to be its own project.

The test: if that client left tomorrow, would you keep this? Would anyone else ever need it? If the honest answer is no twice, a manual process plus a service commitment to that one client is almost always the better trade.

What a genuine need looks like

For contrast, so this does not read as an argument against ever building anything.

A genuine software need is recurring rather than one-off. It has enough volume to amortise the build. It sits on a process that is understood well enough to encode, or the discovery work will stabilise it. And accountability for doing the work correctly already exists, independent of any tool.

The strongest signal is this: the team is already doing the work reliably by hand or in a stopgap, and the only missing piece is throughput, consistency or auditability that a human process structurally cannot deliver at your volume. That is the case where software adds something. Everything else is software being asked to supply discipline it cannot manufacture.

The request you receive is a solution, not a problem

Almost nobody walks into a meeting and describes a problem. They describe a system.

"We need a dashboard." "We need a portal for clients." "We need an app the drivers can use." Those are answers, arrived at privately, by somebody who has already done the diagnosis in their head and skipped straight to the conclusion. Teams do this because describing a solution is easier than describing a problem, and because a solution sounds decisive while a problem sounds like a complaint.

The useful move is to walk it backwards. Ask what specifically they cannot do today. Ask what happens right now when they need that information. Ask who they have to chase, and how long they wait.

What comes back is frequently not a software gap at all. It is a handoff nobody owns, an approval that exists because somebody senior asked for it three years ago and nobody has revisited it, a report that already exists but that nobody knows about, or a permission somebody was never given. Every one of those is fixable this week, at no cost, by a person with the authority to change it.

Occasionally, walking it backwards produces a genuine case for building. When that happens you have something considerably better than the original request: you have the actual problem, described by the people who live with it, in terms a supplier can quote against. That description is the specification, and it costs an afternoon of asking rather than a discovery phase.

What to try before you build

Four options, roughly in order of cost.

Change the process

Nobody sells this, so nobody suggests it. Reassigning who owns a task, changing who signs off, deleting an approval step that exists purely out of habit, or agreeing one shared naming convention resolves a real share of what arrives as a system request. Licence cost is zero. It is the most commonly correct answer and the least commonly proposed, which tells you something about who normally gets asked.

A spreadsheet, used properly

Worth being precise here, because the received wisdom is wrong.

You will hear that spreadsheets break once a few people are editing at the same time. Google publishes a ceiling of one hundred people editing a Sheets file simultaneously [3], which is a number almost no SME in the UAE will approach. Size is not the constraint either: Microsoft's published Excel worksheet limit is 1,048,576 rows by 16,384 columns [1], and Google's Sheets limit is ten million cells across a file, with a beta extending that further [2].

So if somebody tells you your spreadsheet has outgrown itself, ask what the actual number is. Usually there is not one, and the real objection is structural.

An off-the-shelf point tool

When the need is narrow and common rather than specific to your business, somebody has already built it and sells it for tens of dollars a month.

A great many requests that arrive as "we need an app for this" are a scheduling page or a structured intake form away from solved. Scheduling tools publish tiered pricing from a free tier upward [4]. Form and intake tools publish similar tiers [5]. Before commissioning anything, it is worth an hour establishing whether the category already exists as a product, because if it does, no build will compete with it on cost.

The no-code layer

The automation platforms sit honestly between a spreadsheet and a build. They all publish pricing and all have free tiers adequate for testing whether an automation is worth having at all [6][7][8].

The point of trying one is not that it will be your permanent answer. It is that if a no-code version saves real time for three months, you have proven the value and produced a far better specification than anything you could have written from imagination. If it does not, you have found that out for the cost of a subscription.

When the cheap option genuinely stops working

There is a real moment when a stopgap should be replaced, and it is worth knowing what it looks like so you do not move too early or too late.

Move when you need to know who changed a figure and when, and cannot find out. Move when different people need different levels of access and the file offers all or nothing. Move when the process crosses departments and things reliably get lost at the handoff. Move when an error rate has started costing more than the replacement would. Move when a compliance obligation requires structured, auditable records rather than a document somebody edits.

Those are structural limits. They are the honest triggers. Notice that none of them is "it feels unprofessional" or "we are a real company now", which are the reasons that actually get projects started.

On compliance specifically: obligations in the UAE are frequently phased and depend on the size and type of your entity. The e-invoicing programme is a live example. Check your own position and your own dates with the Ministry of Finance rather than acting on a general claim, including a general claim from a supplier who would like to sell you a system.

Why we are not giving you a failure statistic

You have probably seen a figure for how many software projects fail. There are several in circulation and they disagree with each other.

Every version we could find traces back to a consultancy or a research firm that sells remediation, benchmarking or advisory services to the same market the number is about. Some of the underlying methodologies are openly disputed. Repeating one would make this article feel more authoritative without making it more true, so we are leaving it out.

The argument does not need it. Encoding a process you do not understand is expensive to build and much harder to reverse than to create, because by then the process has bent itself around the tool. That mechanism holds regardless of what the industry average happens to be.

The questions a supplier should ask you

You can learn a lot about what you are buying from what gets asked before the quote arrives.

A supplier scoping a build asks about features, screens, integrations and timelines. A supplier trying to work out whether you need one asks what the process looks like today, who does it, how often, what happens when it goes wrong, and who would be accountable for the new system once it exists. Establishing the cause before designing the solution is a named, standard technique in the business analysis discipline [9] rather than something invented to justify workshops.

The most useful question to ask them, and the one we would encourage you to ask us: under what circumstances would you recommend that we do not build this? If a supplier cannot describe those circumstances concretely, the diagnostic they are offering has only one possible conclusion.

What this costs

A short diagnostic engagement with us starts from around AED 1,500. That covers the process as it actually runs, what the realistic alternatives cost, and a straight recommendation which explicitly includes doing nothing. A fuller discovery that produces a written specification you own outright starts from around AED 4,000. Final pricing depends on scope.

Those are our figures rather than a market survey, and we would rather you spent the smaller number and walked away than spent a build budget on something the business quietly abandons in month three.

If you want the free version first: write your process down and show it to two people who do the work. That single afternoon settles a meaningful share of software questions before anyone quotes anything. Either it produces a clear specification, or it reveals that the business does not yet agree on how the work is done. Both are worth knowing, and only one of them is a software project.

References

Vendor pricing accurate as of 23 August 2026. All published pricing changes; check the vendor page before budgeting.

Frequently asked questions

How do I know whether I need software at all?
Ask whether the work is already happening reliably by hand, and whether the only thing missing is throughput, consistency or an audit trail that a human process structurally cannot deliver at your volume. If the answer is yes, that is a genuine software need. If the work is not happening reliably now, software will not make it happen, because a tool does not supply the thing that is actually missing.
What is the most common wrong reason to build?
That nobody has written the process down. Software encodes a single path, so if the process currently exists as three informal versions in three people's heads, the build will encode whichever one the loudest person described in the discovery call. Everyone else then works around the tool. The project was a documentation exercise wearing a software costume, and it becomes much harder to fix afterwards.
How do I test for the undocumented process problem?
Try to write the process down end to end, including every exception, without a developer in the room. Then ask two other people who do the work to read it and mark what is wrong. If you cannot produce a version all three agree on, you are not ready to build, and doing that exercise is worth more than any discovery workshop a supplier will sell you.
How much volume do I need to justify building?
Enough that the time saved, multiplied by how often it happens, exceeds the build plus its ongoing maintenance. Budget fifteen to twenty-five per cent of build cost per year for maintenance, which is the figure our own guides use. A task happening twice a month rarely clears that bar, and a task happening fifty times a day usually clears it comfortably.
What is the people problem disguised as a systems problem?
When the stated need is a system to track something, but the real issue is that nobody is accountable for it, or two departments disagree about who owns it. A tracking system does not create accountability. If nobody reliably updates a shared spreadsheet today, nobody will reliably update a purpose-built app either. The tool just makes the gap more visible and considerably more expensive to have built.
How do I test for that one?
Ask who the named person is who keeps it accurate, and what happens if they do not. If there is no name, or no consequence, you have a staffing and accountability question rather than a software one. That is worth knowing before you spend, because the software will be blamed for the gap it did not create and cannot close.
Should I build something for a one-off task?
Almost never. Building reusable software for something that happens once means paying for reusability nobody will use. A one-time data migration, a single large onboarding, a report needed for one board meeting: a script, a manual pass, or somebody doing it carefully by hand is cheaper and faster. Ask whether this genuinely recurs on a schedule or whether you are making a one-time event feel permanent.
My biggest client wants a system. Should I build it?
Ask what happens when that client leaves. Custom software built around one counterparty's requirements becomes a maintenance liability the moment they leave, renegotiate, or change their own systems, and you are left maintaining logic that serves nobody. If nobody else would ever use it, a manual process or a service commitment to that one client is usually the better answer.
What should I try before building anything?
A spreadsheet, an off-the-shelf point tool, a no-code automation, or simply changing the process. That last one is free, is the most commonly correct answer, and is the one nobody in a sales conversation will suggest, because nobody is paid to recommend it. Reassigning a task, removing an approval step that exists out of habit, or agreeing one naming convention resolves a surprising share of system requests.
When does a spreadsheet actually stop working?
Later than people claim, and for different reasons than they claim. Google publishes a ceiling of one hundred simultaneous editors, which almost no SME reaches, so the concurrency argument is largely a myth. What genuinely breaks is structural: no granular access control, no meaningful audit trail of who changed what, formulas that fail silently, and no validation to stop bad data entering.
What are the real signals to move off a spreadsheet?
You need to know who changed a figure and when, and cannot find out. Different people need different levels of access and the file gives you all or nothing. The process now crosses departments and things get lost at the handoff. Or an error rate has started costing more than the fix would. Those are structural limits rather than size limits.
How big can a spreadsheet actually get?
Larger than most businesses will ever need. Microsoft publishes an Excel worksheet limit of just over a million rows by 16,384 columns, and Google publishes a limit of ten million cells across a Sheets file, with a beta raising that further. So if somebody tells you your spreadsheet is too big, ask what the actual number is. Usually the real problem is structure rather than size.
Can an off-the-shelf tool really replace a build?
Frequently, when the need is narrow and common rather than specific to your business. A great many requests that arrive as we need an app are actually a scheduling page or a structured intake form away from solved, at tens of dollars a month rather than a build. Scheduling and forms tools both publish tiered pricing openly, so you can price the alternative in ten minutes.
What about no-code automation tools?
They are a genuine middle ground and worth trying before commissioning anything. The major automation platforms publish tiered pricing starting in the low tens of dollars a month, with free tiers adequate for testing whether an automation is worth having at all. If a no-code version of your idea saves real time for a few months, you have both solved the problem and produced a much better specification.
What is the risk of building the wrong thing?
Not just wasted money, which is recoverable. The process gets locked into software, staff start working around a tool that does not fit, and you need a second project to undo the first. That is why the diagnostic is worth doing before the build rather than after, and why we are not going to quote you a project failure statistic. The mechanism is more useful than a number.
Why will you not give me a failure rate statistic?
Because every version in circulation comes from a consultancy or research firm with a commercial interest in remediation, and several are methodologically disputed. Repeating one would make this article feel more authoritative and would not make it more true. The argument stands without it: encoding a process you do not understand is expensive and hard to reverse, whatever the industry average happens to be.
What should a good supplier ask me before quoting?
What the process looks like today, who does it, how often, what happens when it goes wrong, and who would be accountable for the new system. A supplier who asks only about features is scoping a build. One who asks about the process is trying to work out whether you need one. The questions asked before the quote tell you a great deal about what you are buying.
Is root cause analysis a real discipline or consulting jargon?
It is a named, standard technique in the business analysis body of knowledge, which is to say it is an established practice rather than something invented by a consultancy to sell workshops. The detailed material sits behind a professional membership, so we are not quoting it. The principle is simple enough without the reference: establish the cause before designing the solution.
What if the process changes constantly?
Then encoding it in software now is expensive, because every change becomes a development request. That is not automatically a reason not to build, and it is a reason to build the stable parts and leave the volatile parts as a human process for longer. A tool that is right about the parts that never change is more useful than one that is wrong about everything.
Does compliance change the answer?
It can, because some obligations effectively require structured, auditable records rather than a spreadsheet somebody edits. If you have a regulatory reason to prove who did what and when, that is a genuine driver toward a system. Check what applies to you specifically with the relevant authority rather than assuming, because obligations in the UAE are frequently phased and depend on entity size.
What about UAE e-invoicing, does that force a system?
It may, and the timing depends on your entity rather than on a single national date. The programme is phased and size-dependent, so the right move is to check your own position and date with the Ministry of Finance rather than acting on a general claim. What we would say is that a compliance deadline is a legitimate reason to build, unlike most of the reasons in this article.
How do I tell a genuine need from a wish?
A genuine need is recurring, has enough volume to pay back a build, sits on a process that is actually understood, and has somebody accountable for using it correctly. The clearest signal is that the work is already being done reliably in a stopgap, and the only missing piece is throughput, consistency or auditability. A wish usually fails on at least two of those four.
What if I try the cheap version and it does not work?
Then you have lost very little and gained a specification, which is the genuinely valuable outcome. Knowing exactly where a spreadsheet or an off-the-shelf tool broke tells a supplier far more than any requirements document you could write from imagination, because it is evidence rather than a guess. Almost every good build we have seen started life as a stopgap that stopped coping in a specific, describable way, and the description of that failure is what made the build worth doing.
Is a diagnostic just a sales call with a fee?
It is if the conclusion is always to build, which is why the test of one is whether it can conclude otherwise. Ask directly whether the engagement can end with a recommendation not to proceed, and what that recommendation would look like. A supplier who cannot describe the circumstances in which they would tell you not to build is selling a build.
What does a diagnostic cost?
A short diagnostic engagement starts from around AED 1,500 with us. That covers the process as it actually runs, what the realistic alternatives would cost, and a straight recommendation which explicitly includes the option of doing nothing at all. A fuller discovery that produces a written specification you own outright starts from around AED 4,000. Final pricing depends on scope. These are our own figures rather than a market survey, so treat them as one reference point among several.
Will you actually tell me not to build?
That is what the engagement is for, and you should hold us to it rather than take it on trust. Ask at the outset what would make us recommend against building, and get the answer before you commission anything. A supplier who says yes to everything is not being agreeable, they are declining to give you the one thing you are paying for.
What is the single best question to ask myself?
If somebody handed me this software tomorrow, fully built and free, who in my business would keep it accurate and what happens if they do not? If there is no name and no consequence, the software will not fix anything. That question costs nothing to ask, takes a minute, and prevents more wasted spend than any other on this list.
What if my team keeps asking for a system?
Ask them what specifically they cannot do today, rather than what system they want. Teams describe solutions because that is easier than describing problems, and walking the request backwards often reveals a handoff nobody owns, an approval nobody needs, or a report that already exists and nobody knows about. That conversation frequently produces a change you can make this week at no cost, and occasionally produces a genuine case for building that is far better specified than the original ask.
Does this advice change for a startup building a product?
Substantially, because there the software is the business rather than a support tool. This article is about internal problems where software is one possible answer among several, and where a process change or an off-the-shelf tool competes on equal terms. If you are building something to sell, the equivalent question is whether anybody actually wants it, and that gets answered by putting something in front of real customers rather than by process analysis.
What should I do first, today?
Write the process down and show it to two people who do the work. That single exercise resolves a meaningful share of software requests before anyone quotes anything, because it either produces a clear specification or reveals that the business does not yet agree on how the work is done. Both outcomes are worth more than the afternoon it costs.

SKIMBOX Team

Tech Consultancy

Want us to build something?

We work with teams across MENA, UK, USA, and India to build products, run programs, and grow.

Get in touch

Continue reading

Is This Actually a Software Problem? Five Cases Where Building Makes It Worse

Five cases where building makes it worse

The process nobody has written down

The volume is too low

It is a people problem in a systems costume

It happens once

One customer asked for it

What a genuine need looks like

The request you receive is a solution, not a problem

What to try before you build

Change the process

A spreadsheet, used properly

An off-the-shelf point tool

The no-code layer

When the cheap option genuinely stops working

Why we are not giving you a failure statistic

The questions a supplier should ask you

What this costs

References

Frequently asked questions

Want us to build something?

Continue reading

When to Say No to a Feature: The Cost Nobody Prices at Build Time

Build vs Buy: When a UAE SME Should Build an Internal Tool in 2026

Your First Technical Hire: Why It Probably Should Not Be a CTO

Capabilities

Pages

Links

Capabilities

Pages

Links

Five cases where building makes it worse

The process nobody has written down

The volume is too low

It is a people problem in a systems costume

It happens once

One customer asked for it

What a genuine need looks like

The request you receive is a solution, not a problem

What to try before you build

Change the process

A spreadsheet, used properly

An off-the-shelf point tool

The no-code layer

When the cheap option genuinely stops working

Why we are not giving you a failure statistic

The questions a supplier should ask you

What this costs

References

Frequently asked questions

Get fresh writing in your inbox

Want us to build something?

Continue reading

When to Say No to a Feature: The Cost Nobody Prices at Build Time

Build vs Buy: When a UAE SME Should Build an Internal Tool in 2026

Your First Technical Hire: Why It Probably Should Not Be a CTO