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.
01Remote sensing and AIThe data layer, for places with no gauges
02Numerical modelingThe physics layer, so the system can be trusted
03Software and AI agentsThe decision layer, the part your team opens
04Monitoring 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.
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.