The problem is almost never a lack of data
Most businesses that call us already have plenty: a POS system, an accounting package, a CRM, a spreadsheet somebody maintains by hand, and website analytics nobody reads. What they lack is one place where those agree with each other. The first phase of every data engagement is unglamorous: pipelines, deduplication, and definitions everyone signs off on. It is also the phase that decides whether anything built later gets trusted, because a dashboard that disagrees with the finance team's spreadsheet will lose that argument every time and then be ignored. Once the numbers are trustworthy, prediction becomes viable, and that is the AI and machine learning side of the same work.
- Pipelines from your existing systems into one warehouse.
- Agreed definitions: what counts as a customer, a sale, an active user.
- Data quality checks that fail loudly rather than silently.
- Historical backfill, so a trend does not begin last month.
- Reconciliation against the numbers your finance team already trusts.
Dashboards people actually open
A dashboard earns its place when somebody changes a decision because of it. We build to a small number of questions the business already asks out loud in meetings: which lines are losing money, which channel brings customers who stay, what stock is about to run out, which branch is drifting. The view is then designed around answering those, with a default period, a clear owner and a place it is looked at, which is usually a scheduled message rather than a portal somebody has to remember to visit. Internal dashboards people actually use is the longer argument, and the short version is that if a chart does not change an action, it does not ship. Where the report is being assembled by hand every week, the answer may be process automation rather than another dashboard.
Forecasting and models
Once the data is trustworthy, prediction becomes cheap. Demand and stock forecasts, cash-flow projection, churn scoring, seasonal patterns in enquiry volume: trained on your own history and validated against periods the model never saw. Seasonality in Nepal is strong and specific, since Dashain and Tihar, the monsoon and the admissions calendar all move demand hard, and a model fitted without them will be wrong in the same weeks every year. We report accuracy honestly, including where the model is weak, because a forecast presented without error bars is a guess wearing a suit.
Measurement that has to work without third-party cookies
A large part of what businesses call analytics was quietly built on tracking that no longer functions. Attribution now depends on first-party data, server-side collection, consent handled properly, and an honest account of what is modelled rather than observed. We would rather give you a smaller number you can defend than a larger one assembled from three platforms each claiming the same sale. Marketing analytics after third-party cookies sets out what still works, and where the remaining gaps genuinely are.
Open data, and the questions nobody has run yet
Not all of the useful data is yours. Government releases, survey data, weather and hydrological readings and open geographic data can answer questions your own systems cannot, particularly about risk and location. We have written about mapping flood risk with open data and about the state of Nepal's road crash reporting, both of which are ordinary data engineering applied to public sources. The same techniques apply to catchment analysis for a new branch, or to understanding where your customers are not.
What goes wrong in data science, and how we avoid it
- Two departments with two definitions of revenue.
- Definitions are agreed and written down before anything is built, with finance in the room. Skipping this produces a dashboard that is technically correct and commercially ignored.
- A pipeline that fails quietly.
- Every pipeline has freshness and row-count checks that alert a person. A dashboard showing last Tuesday's figures with no warning is worse than one that is honestly empty.
- A forecast presented as a single number.
- We report a range and the historical error, and we validate against periods the model never saw. A point estimate invites decisions that the underlying accuracy does not support.
- Forty charts and no decision.
- We start from the questions asked in the management meeting and build only what answers them. Everything else is available on request rather than on the front page.
How we run data science work
- 01
Inventory
We list every system that holds relevant data, how it can be extracted, and how the numbers currently disagree. The disagreements are the interesting part and they are where the first phase gets its scope.
- 02
Define
Metric definitions written down and signed off, including the awkward edge cases: refunds, cancellations, internal transfers, the customer who is also a supplier.
- 03
Pipeline
Extraction, cleaning and loading into one warehouse, with quality and freshness checks that alert rather than fail silently, and a historical backfill so trends have somewhere to start.
- 04
Answer
Dashboards and scheduled reports built against the specific questions from the management meeting, with an owner named for each one. Anything nobody owns does not get built.
- 05
Predict
Only once the data is trusted: forecasting or scoring models, validated against held-out periods, reported with error ranges and re-measured on a schedule.
What data science costs
A first engagement, pipelines, agreed definitions and the dashboards that answer the questions you already ask, is quoted on the Growth tier against a written scope. Modelling work is quoted separately once the data is trustworthy, because forecasting on unreliable data is money spent twice. Where a business wants an ongoing analytics function without hiring, the Dedicated Team tier puts a data engineer or analyst on your roadmap monthly.
Growth
Software behind the front door.
- Nepal, from
- Rs 320,000
- About $2,290 at Rs 140 to the dollar
- International, from
- $4,200
- A$6,400 · €3,900
6 to 12 weeks
Companies that need logins, payments, dashboards or an app, not just pages.
Dedicated Team
Your engineering bench, offshore.
- Nepal, from
- Rs 145,000per engineer, per month
- About $1,040 at Rs 140 to the dollar
- International, from
- $2,200per engineer, per month
- A$3,400 · €2,050
Monthly, 3-month minimum
Teams in Australia, the US, the UK, the EU or Nepal outsourcing a squad of developers, ML engineers or DevOps people who work to your roadmap.
What pushes the price up
- The number of source systems, particularly any without an export or an API.
- Historical data that is inconsistent, which is most historical data.
- Real-time requirements, which are usually a want rather than a need.
- Modelling that has to be explainable to a regulator or an auditor.
- Definitions that are genuinely contested inside the business.
What brings it down
- Starting with two or three source systems rather than all of them.
- Daily rather than live refreshes, which covers almost every real decision.
- Using a BI tool you already pay for.
- One person on your side empowered to settle a definition.
- Every figure here is a starting point, not a quote. You get a fixed price against a written scope before anything is built.
- Nepali clients are quoted in NPR at local rates, with a VAT invoice against our PAN. International clients are quoted in USD, AUD, EUR or GBP.
- You own the code, the domain and the hosting from day one, on every tier.
Who this is for, and who it is not
Worth a conversation if
- Businesses where the monthly report takes someone three days to assemble by hand.
- Companies with several systems that disagree with each other about basic figures.
- Retail, distribution and hospitality operations with enough history to forecast stock and demand.
- Australian and US teams who want a data function without hiring a full-time analyst.
Probably not us if
- Organisations with a few hundred rows in one spreadsheet. A pivot table is the correct tool and it is free.
- Anyone wanting a dashboard as a display rather than as an input to a decision.
- Businesses unwilling to settle definitional arguments between departments, because that argument is the project.
Frequently asked questions
How much data do we need before this is worth doing?
Less than people assume for dashboards and reporting, more than people assume for forecasting. As a rule, two years of transaction history makes seasonal forecasting viable in Nepal, because you need to have seen at least two Dashains. Below that we would build the reporting layer first and revisit prediction later.
Our data is in five different systems. Is that a problem?
It is the normal starting point and it is the first thing we fix. Getting those systems into one warehouse with agreed definitions is usually the highest-value part of the whole engagement, and it is also the part that gets skipped when someone sells a dashboard on its own.
Can you work with our existing BI tool?
Yes. If you already pay for Power BI, Looker Studio, Metabase or Tableau, we build into it rather than selling you a replacement. The tool is rarely the reason a business cannot answer its own questions.
How accurate will a forecast be?
We validate against periods the model never saw and report the error, so you get a measured range rather than a claim. Accuracy varies by product and by season; the honest answer for a slow-moving line with erratic history is often that a forecast will not beat a simple rule, and we will say so.
Do we need a data engineer on staff afterwards?
Not usually. Pipelines are built to run unattended with alerting when something breaks, and they are documented so any developer can maintain them. We can hold a support arrangement if you prefer, and we would rather that be a choice than a necessity.
How do you handle Nepali seasonality in a model?
Explicitly. The festival calendar moves against the Gregorian one, so a model fitted on month numbers gets Dashain wrong every year. We encode the actual festival dates, the monsoon window and any sector-specific cycle such as admissions intake, and check the residuals in exactly those weeks.
Is this different from what a BI consultant does?
The reporting half overlaps. The difference is that we build and own the pipelines underneath, so the numbers arrive reliably and are checked, and we can go on to modelling once they are trustworthy rather than stopping at the visualisation layer.
