Where AI actually pays for itself
The projects that succeed share a shape: a repetitive task, a definition of a correct answer that two people would agree on, and a human who reviews the output at first. The projects that fail are the ones where nobody wrote down what correct meant before the build started, so the model is judged on vibes and the argument at the end is unwinnable. We insist on that definition before quoting, and if the task cannot be defined that clearly, we will tell you it is not ready. A fair share of what arrives under this heading is really process automation with no model in it at all, which is cheaper to build and more reliable to run.
- Retrieval over your own documents, with citations back to the source.
- Support automation that hands off to a person cleanly when unsure.
- Classification, extraction and routing for high-volume inbound work.
- Drafting assistance inside tools your team already uses.
- Evaluation harnesses so quality is measured rather than assumed.
Evaluation before deployment, and after it
We build a test set from your real cases, with the expected answers agreed by the people who do the job today, and measure against it before anything reaches a user. Then we keep measuring, because a change to a prompt, a model version or a document set can quietly move accuracy and nothing will tell you. Without that harness, the only available signal is whether it seems better, and that is not a signal you can make a commercial decision on. Shipping AI features users actually trust covers the interface side of the same problem: how to show uncertainty rather than hide it.
Machine learning, not only language models
Half of what gets called AI is better served by a model that has nothing to do with chat. Demand forecasting, churn and default prediction, anomaly detection on transactions or sensor data, image classification and OCR for documents: all trained on your own history, cheap to run, and producing a number you can act on. We pick the smallest model that solves the problem, because a gradient-boosted tree a business trusts beats a large model it cannot explain, and it costs a fraction to run. Where the work is mostly about getting the data into a usable state first, that belongs on the data science page.
- Forecasting: demand, stock, cash flow, patient or student volume.
- Prediction: churn, credit default, no-show, equipment failure.
- Anomaly detection for fraud, reconciliation and quality control.
- Computer vision: counting, inspection, document and identity capture.
- Recommendation and ranking inside your own product.
Cost, latency and keeping the exit open
Model choice is an engineering trade-off between quality, latency and cost per request, and the largest model is rarely the right default. We measure cost per request and keep the model behind our own interface so a provider can be swapped without rewriting the product, which matters because pricing and availability change several times a year. Caching, shorter contexts and routing easy cases to a smaller model usually cut the running cost substantially without a change a user would notice, and we treat that as part of the build rather than as an optimisation to fund later.
Data, privacy and what the rules now require
We are explicit about what data leaves your environment, under whose terms, and where it is processed. For clients in the EU, the UK, Australia and several US states, that is now a documented obligation rather than a preference, and it constrains architecture: what may be sent to a provider, what has to stay inside your infrastructure, what has to be disclosed to a user, and what must be logged. What AI regulation actually changes in client projects and US state privacy laws for small product teams cover the practical version. If your data genuinely cannot leave your own servers, we will tell you which approaches remain viable and which do not.
What goes wrong in ai & ml development, and how we avoid it
- A demo that impressed everyone and cannot be evaluated.
- Before any build, we agree a test set of real cases with expected answers. If nobody can produce fifty examples with agreed correct outputs, the task is not defined well enough to automate.
- An assistant that answers confidently from nothing.
- Retrieval systems cite their source and are built to say they do not know. An answer with no citation is unverifiable, and one wrong invoice figure delivered confidently costs more trust than fifty right ones earn.
- Cost discovered in the second month's invoice.
- We measure cost per request during the build, load-test it at expected volume, and put a spend limit and an alert in place. Token costs scale with success, which is the wrong surprise to have.
- No answer for when the provider is down.
- Every integration has a documented fallback: a queue, a smaller model, or a clean handover to a person. An API outage should degrade the feature, not stop the business.
How we run ai & ml development work
- 01
Qualify
We look at the task, the volume and the cost of being wrong, and say whether AI is the right tool. A fair number of these conversations end with a recommendation to fix a form or a process instead, and no project.
- 02
Define correct
A test set of real cases with expected answers, agreed with the people who do the work today. This is the contract the system is measured against and it is written before anything is built.
- 03
Prototype and measure
The smallest thing that could work, scored against the test set, with cost and latency per request recorded. If the numbers do not justify going further, we stop here and you have spent a fraction of the budget.
- 04
Integrate
Into the tool your team already uses, with the human review step, the logging, the spend limits and the fallback path all in place before real work goes through it.
- 05
Monitor
Accuracy re-measured on a schedule and after every model or prompt change, with the review queue watched. Quality drift is normal and silent, so it has to be looked for deliberately.
What ai & ml development costs
A defined AI feature integrated into an existing product is quoted on the Growth tier against a written scope, with the evaluation set agreed before the price. Continuing work, where models, prompts and data keep changing and someone has to own the accuracy number, is the Dedicated Team tier. Provider costs are separate: you pay the model provider directly on your own account so you can see exactly what the feature costs to run.
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
- Documents that arrive as scans or photographs rather than as text.
- Accuracy requirements high enough to need a bespoke evaluation and review workflow.
- Data that cannot leave your infrastructure, which rules out managed options.
- Integrating into systems with no API, where the work is mostly plumbing.
- Regulated contexts needing audit trails and disclosure to end users.
What brings it down
- One task, clearly defined, with examples of correct answers already available.
- Clean text sources rather than scanned paper.
- Accepting a human review step, which allows a cheaper and smaller model.
- Using a managed provider rather than self-hosting.
- 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
- High-volume repetitive work where correctness can be defined and checked.
- Organisations sitting on documents staff read and re-read to answer the same questions.
- Businesses with years of transaction history that has never been used to predict anything.
- International teams wanting ML capacity without hiring a full-time specialist.
Probably not us if
- Tasks that are small, highly varied or done a handful of times a month. A better form and a clear procedure will beat an AI feature on cost and reliability, and we will say so.
- Anyone who needs the answer to be right every time with no human review. That is not what these systems provide.
- Projects where the data is scattered and inconsistent. Fix that first; it is data science work, not AI work.
- Businesses that want AI mentioned in their marketing rather than used in their operations.
Frequently asked questions
Will our data be used to train a model?
Not under the enterprise API terms we deploy on, and we confirm the specific terms in writing for the provider chosen for your project. If your data cannot leave your infrastructure at all, we will tell you which approaches remain viable and what they cost in quality.
How accurate will it be?
That is what the evaluation set is for. We measure against your real cases and report the number rather than offering a general assurance, and we design the interface so a wrong answer is visible and recoverable rather than silently accepted.
What does it cost to run each month?
Provider costs are billed to your own account so you can see them directly, and we measure cost per request during the build and load-test it at expected volume. Caching, shorter contexts and routing simple cases to a smaller model are part of the build, not an optimisation to fund later.
Is this worth it for a small business?
Sometimes. If the task is small, infrequent or highly varied, a well-designed form and a clear process will beat an AI feature on both cost and reliability. We would rather say that in the first conversation than build something that gets switched off in six months.
What is RAG, and do we need it?
Retrieval-augmented generation means the system searches your own documents and answers from what it finds, with citations, rather than from what the model remembers. You need it when the answers live in your files and change over time. You do not need it for a fixed set of answers that would be better served by a well-written help page.
Can you fine-tune a model on our data?
Occasionally that is the right answer, but far less often than it is asked for. Retrieval, better prompts and a clearer task definition solve most of what people expect fine-tuning to solve, at lower cost and without a model that has to be retrained every time the underlying information changes.
What happens when the AI provider has an outage?
The feature degrades to a documented fallback: a queue, a smaller model, or a clean handover to a person. We test that path rather than assuming it, because provider outages happen and a business process should not stop when one does.
Do the new AI rules affect a project like ours?
It depends on where your users are and what the system decides. Obligations around disclosure, logging and human review are real for clients in the EU, the UK, Australia and several US states, and they change architecture rather than just paperwork. We work out what applies before design, not after legal review.
