Decision support systems for water

We build water decision support systems, end to end.

A water decision support system is software that combines water data, a model of how the water behaves and a live monitoring feed, and presents the result as a decision your team can act on. Smart Bhujal builds every layer of that system in-house, from the satellite pixel to the dashboard your team opens each morning, and delivers it remotely to institutions wherever they are.

What you receive

Every layer, built in-house

  1. Remote sensing and AIThe data layer, for places with no gauges
  2. Numerical modelingThe physics layer, so the system can be trusted
  3. Software and AI agentsThe decision layer, the part your team opens
  4. Monitoring and sensorsThe ground truth layer, so it stays current

One decision your team can act on

What you receive

Four things arrive, not a slide deck.

A decision support system engagement hands over a working dashboard, the calibrated models underneath it, the data pipelines that keep it fed and the monitoring integration that keeps it current. Each of those is a deliverable in its own right, and each is documented so that your team can run the system after we step back.

A dashboard your team actually opens

The interface is the product as far as the user is concerned, so it is designed around the decision rather than around the database schema.

  • Custom decision-support application
  • Interactive dashboards and visualisation
  • Scenario and what-if tools
  • User access management

Models that hold up under questioning

Every model is calibrated against measurements and documented, because an institutional buyer has to defend the result to a board, a funder or a regulator.

  • Calibrated flow, flood, network or quality models
  • Trained machine learning models
  • Model performance report
  • Scenario simulation capability

Data pipelines that keep running

A decision support system is only alive if data reaches it without someone copying a spreadsheet every Monday, so the pipeline is part of the build rather than an afterthought.

  • Data cleaning and transformation
  • Database and API integration
  • Prediction API endpoints
  • Automated and scheduled reporting

Monitoring wired in, not bolted on

Live observation is what separates a decision support system from a study, and it is integrated at the same time as the rest of the stack.

  • Sensor and telemetry integration
  • SCADA protocol support
  • Alert and notification configuration
  • Historical data analysis and export

The stack

Four layers, built in-house.

A decision support system is only as good as the stack beneath it, and most of them fail at a seam: a dashboard bolted onto a model nobody calibrated, or a model with no live data reaching it. We build all four layers ourselves, which means the seams are ours to get right rather than someone else's to argue about.

01

Remote sensing and AI

The data layer, for places with no gauges

We build the pipeline that turns satellite and sensor archives into a usable signal over your area of interest: surface and groundwater change, vegetation stress and anomalies, over any time window you choose. This is the layer that matters most where ground observation is sparse, because it gives a system something to run on before a single new instrument is installed.

Satellite imagery pipelinesNDVI and vegetation indicesChange detectionTrained ML models
02

Numerical modeling

The physics layer, so the system can be trusted

We build physics-based simulations of how water actually moves through aquifers, floodplains, drainage and distribution networks, calibrated against measurements from your site. A dashboard that only plots history cannot answer a scenario question. A calibrated model can, which is why the model sits underneath the interface rather than beside it.

MODFLOWHEC-RASEPANETSWMM
03

Software and AI agents

The decision layer, the part your team opens

We build the application itself: the dashboard, the scenario tools, the APIs and the AI agents that put the model and the data to work. This is where a decision support system stops being an analysis and becomes an operational tool that a named person uses on a named day to make a named decision.

Decision dashboardsDigital twinsAI agentsAPIs and integrations
04

Monitoring and sensors

The ground truth layer, so it stays current

We build the integration that keeps the system anchored to what is happening in the field: telemetry ingestion, IoT metering, SCADA protocol support, alerting and quality control on the incoming stream. Without it, a decision support system is a snapshot that quietly goes stale.

IoT meteringTelemetry ingestionSCADA integrationAlerts and QA/QC

Delivered remotely

This is work that does not need us on your site.

A decision support system is built and delivered over a network, which makes the location of the buyer irrelevant to the quality of the result. Drilling, pump testing and floodplain survey need people on the ground. Data pipelines, calibrated models and the software on top of them do not, and pretending otherwise only adds travel to the invoice.

The inputs travel

Satellite archives, hydrological records, telemetry feeds and existing model files are all digital. They reach a build team over a network in the same condition they left, which is not true of a borehole, a pump test or a floodplain survey.

The output is software

What we hand over is an application, a set of models and the pipelines feeding them. It is deployed to your infrastructure or to a cloud account you control, and reviewed in the same browser wherever your team sits.

The review loop is short

Decision support work is iterative: you look at a screen, you say that is not the question we ask, and the screen changes. That loop runs over a call and a shared environment, which is how software has been built across time zones for two decades.

Local expertise stays local

We do not replace the hydrogeologist who knows your basin or the engineer who signs off on site. We build the system that carries their judgement into a tool the rest of the organisation can use, working alongside whoever holds that ground knowledge.

What our clients say

“They transform ideas and raw datasets into high-quality AI-powered dashboards and decision-support systems, and do it fast.”
FA

Faiz Alam

Client · International Water Management Institute

Who this is for

Organisations accountable for a water decision.

This work suits any organisation that has to make the same water decision repeatedly and has to justify it to someone else. That is usually a research institute, a development programme, a utility, a funder or a university department, and the common thread is that the answer has to be defensible rather than merely presentable.

Research institutes and CGIAR centres

Research groups sitting on rich datasets and publication-grade methods that need the result to become a tool a partner ministry or a field programme can operate without the original author present.

Development agencies and programmes

Programme teams accountable for water outcomes across many districts or basins, who need one view that consolidates monitoring, modelling and reporting instead of a folder of consultant deliverables.

Water authorities and utilities

Operators of real networks and real aquifers who need abstraction, leakage, demand and quality questions answered on an operating rhythm rather than once per study cycle.

Foundations and NGOs

Funders and implementers who have to show what changed, where, and whether the intervention worked, and who need that evidence to be reproducible rather than assembled by hand for every report.

University programmes

Departments and research programmes that need a modelling or remote sensing method turned into a maintained, documented system that outlives the student cohort which built the prototype.

How a decision support system gets built

The build runs in the order that keeps the system honest: the decision first, the design second, and calibration as a gate rather than a final polish. Working the other way round produces a handsome interface sitting on a model nobody has checked.

  1. Start from the decision

    We establish what you are trying to decide, who decides it and on what cadence, before we ask what data exists. The decision determines the model and the model determines the data, in that order.

  2. Design the system

    Decision workflow analysis produces the system design: which layers are needed, what each one has to output, and what the interface has to show to close the loop.

  3. Build the stack

    Data pipelines, models, application and integrations are built together rather than sequentially, so the interface is tested against real model output from early on.

  4. Calibrate against ground truth

    Models are checked against measurements. A model that has not been compared with observation is an opinion with a mesh, so calibration is a gate rather than a final polish.

  5. Hand over and support

    Deployment, documentation and training sessions transfer the system to your team, with maintenance and support available afterwards.

How we work

Three rules we do not bend.

01

Start from the decision

We ask what you are trying to decide before we ask what data you have. A dashboard nobody acts on is a cost, not an asset.

02

Physics first, AI where it earns its place

We use MODFLOW, HEC-RAS, EPANET and SWMM where physics is the right tool, and machine learning where it genuinely beats them: forecasting, anomaly detection, downscaling and filling gaps.

03

Calibrated, or it is a guess

Every system is anchored to ground truth and recalibrated as new observations arrive, which is why monitoring is part of the stack rather than an afterthought.

More on the team and where these came from is on the about page.

Questions

Frequently asked questions

A water decision support system is software that combines water data, a model of how the water behaves and a live monitoring feed, and presents the result as a decision a team can act on. It is not a report and it is not a map layer. It answers a standing question, such as how much can safely be abstracted this season or where a network is losing water, and it answers it again every time new data arrives.

The deliverables listed against our custom decision-support software work are the application itself, user documentation, training sessions, and source code and deployment. Where the system includes machine learning, that extends to trained models, prediction API endpoints, a model performance report and integration documentation. Where it includes live monitoring, it extends to the dashboard, alert configuration, data export and user access management.

Yes, because every input and every output of this work is digital. Satellite archives, hydrological records, telemetry and existing model files all transfer over a network unchanged, and what we hand back is software deployed to infrastructure you control. That is the difference between building a decision support system and running a site investigation, which does need people on the ground.

Yes. Our clients include the International Water Management Institute, an international water research organisation, alongside universities, state programmes and private operators. Because the work is delivered remotely, the location of the institution is not a constraint on the engagement.

We build on standard, peer-reviewed engines rather than proprietary black boxes: MODFLOW for groundwater flow, HEC-RAS for rivers and floodplains, EPANET for distribution networks and SWMM for urban drainage. Using established engines means an external reviewer can interrogate the result, which matters when a funder or a regulator asks how a number was produced.

Both, but not interchangeably. Groundwater and floods obey equations that have been calibrated against field data for decades, so physics is the default. Machine learning is used where it genuinely outperforms physics: forecasting, anomaly detection, downscaling and filling gaps in sparse records. A method is chosen because it is the right tool, not because it is fashionable.

Yes. Sensor and telemetry integration, SCADA protocol support, database integration and API development for third-party systems are all part of the standard scope. A decision support system usually earns its value by consolidating sources that already exist inside an organisation but have never been brought into one view.

Then the model or the platform becomes an input rather than something to rebuild. We can build the decision layer on top of what already exists, wiring an established model or database into a dashboard, an API and a monitoring feed. Rebuilding a working model is a cost with no return, and the budget is better spent on the layer that is missing.

Source code and deployment are listed among the deliverables of a custom decision-support software engagement, so the system is handed over rather than held out of reach. The specific licensing and ownership terms are set out in the contract for each project.

It starts with the decision, not with the data. Send us the question your organisation is trying to answer, who has to answer it and what data already exists, and the first conversation is about whether a decision support system is genuinely the right instrument for it. If it is not, we will say so.

Choosing the tools

Which package the modelling layer runs on

Most of these packages do the same job well enough that the choice comes down to the shape of your problem rather than the quality of the software. Written for the person who has to justify the decision rather than the person who has already made it.

Flood Modelling Software Compared

HEC-RAS is free, capable and accepted almost everywhere, which makes it the right default. Here is where MIKE, TUFLOW and Delft3D genuinely earn a licence fee instead.

PCSWMM vs EPA SWMM: Which to Use

They are not really competitors. EPA SWMM is the free computational engine, PCSWMM is a commercial environment built around it. The question is whether you need what the environment adds.

FEFLOW vs MODFLOW: How to Choose

The honest answer is that the two codes are good at different things, and the deciding factor is usually the geometry of your problem rather than the quality of the software. Here is the line between them.

InfoWorks Alternatives for Small Teams

InfoWorks WS Pro and ICM are strong platforms priced for large utilities. If you are a smaller consultancy or a mid-sized utility, here is what professionals actually use instead, and where the tradeoff bites.

WASP vs QUAL2K: Which One Fits

Both are free EPA water quality models and they are built for different water bodies. QUAL2K is a river reach tool, WASP is a general transport framework. Picking wrongly costs weeks.

WEAP vs MIKE HYDRO Basin

Basin allocation models encode who gets water and in what order, which makes them as much a negotiation tool as a technical one. That shapes which package is the right one.

Go deeper

The layers, in detail

Software and AI services

The full catalogue of what goes into a system: custom software, ML models, dashboards, digital twins and analytics.

Solutions by sector

How the same stack is applied to agriculture, municipal networks, industry, mining and the environment.

Groundwater modeling

MODFLOW-based aquifer simulation, the physics layer underneath most groundwater decision support work.

Surface water and flood modeling

HEC-RAS and hydrological modelling for floodplains, catchments and river systems.

Water distribution modeling

EPANET network simulation for utilities managing pressure, losses and supply reliability.

GWFlowAI

Our own groundwater tool, and a working example of the decision layer we build for clients.

Tell us the decision you are trying to make.

Not the dataset, not the software you think you need. The decision. If a decision support system is the right instrument for it, we will describe what that system would have to contain. If it is not, we will tell you that instead.

contact@smartbhujal.com
Ask about water management
Chat on WhatsApp