A large share of water decision support problems are solved correctly and cheaply by an off-the-shelf dashboarding tool. Power BI, Tableau, Grafana and Superset are mature, well supported, and fast to stand something up in. Any supplier who tells you a custom build is always the answer is describing their business model rather than your problem.
The position is also argued in the literature. A 2026 paper in the Journal of Water Resources Planning and Management makes the case that off-the-shelf dashboarding tools enable participatory development of decision support systems and offer cost-efficient customisation, with libraries of prebuilt templates allowing rapid prototyping without extensive coding at each iteration. That is a reasonable argument and it is right for a substantial class of problems.
The useful question is not which approach is better. It is which of the two problems you have.
When an off-the-shelf tool is the right answer
Reach for an existing tool when the data is already clean and tabular and the job is to look at it. Specifically, when most of the following hold:
- The question is monitoring rather than simulation. You want to see what happened and what is happening, not what would happen under a different policy.
- The data already exists in a queryable form. A database or a well behaved API, rather than a pile of instrument files in six formats.
- The users are internal and few. Licence costs scale with seats, which is fine at ten and a real consideration at a thousand.
- Speed matters more than fit. Something imperfect this quarter beats something ideal next year, particularly when the requirement is still being argued about.
- The organisation already runs one of these tools. Existing licences, existing skills and an existing support arrangement are worth a great deal and are routinely undervalued in these decisions.
In that situation a custom build buys you very little and costs you the thing you were short of, which is time.
When a custom build earns its cost
A build is justified when something has to happen underneath the interface that a dashboarding tool is not designed to do. In practice that is one of five things.
A physical model has to run
Dashboarding tools visualise data. They do not solve groundwater flow, route a flood or balance a pipe network. Where the answer requires MODFLOW, HEC-RAS, EPANET or SWMM, the system has to orchestrate a solver and manage its inputs and outputs, and that is an application rather than a report.
The data needs a pipeline before it can be shown at all
If the honest description of the work is that logger records must be reconstructed across their gaps, satellite imagery must be processed, instrument drift must be separated from real signal, or six incompatible sources must be reconciled, then the visualisation is the last ten percent of the problem. Connecting a dashboard directly to raw sources in that situation produces a fast, confident and wrong picture.
Scenario behaviour is the product
Precomputed results can be displayed by anything. A system where the user changes an assumption and the model responds is a different proposition, because the model has to be callable, the run has to be managed and the results have to come back somewhere sensible. This is usually the requirement that settles the question.
An institution will operate it for years
Long-lived systems inside institutions have requirements that rarely appear in a first specification: user management, audit trails, the ability to add a station without a consultant, and independence from any one person's account. These are achievable in off-the-shelf tools to varying degrees and are native to a built application.
The output has to be defended
Where a number will be challenged by a regulator, a funder or a board, the system has to be able to show its working: what version of the model produced it, what data went in, when it was last calibrated. Provenance of that kind is something you design in rather than switch on.
The hybrid is common and usually sensible
The two approaches are not a fork in the road taken once. A frequent and effective sequence is to prototype in an off-the-shelf tool precisely to settle what the decision is, with real stakeholders arguing over a real screen, and then build once that argument is finished.
This is cheaper than it sounds. The expensive failure in these projects is not writing software, it is writing the wrong software confidently. A disposable prototype that causes someone to say "actually the question is the other one" has paid for itself several times over.
It is also common for both to coexist permanently. A built system handles the modelling and the pipeline and publishes clean outputs to a table that the organisation's existing dashboarding tool reads. Users get the interface they already know, and the difficult work happens where it belongs.
How to tell which you have
Three questions usually settle it. Does anything need to be simulated rather than displayed? Is the data usable as it stands, or does it need work before it can be trusted? Will somebody have to defend a number that comes out of this?
If all three answers are no, buy a licence and get on with it, and treat anyone selling you a build with suspicion. If one is yes, a hybrid probably fits. If two or three are yes, an off-the-shelf tool will get you a convincing screen over an unreliable foundation, which is the most expensive outcome available because it fails slowly and in public.
We build the second kind, and part of scoping any decision support system is establishing whether you actually need one. Where the honest answer is a dashboarding licence and a fortnight of data work, that is worth more to you than a project, and it is a conclusion our consulting work reaches often enough to be worth saying out loud.