DEV Community: Sanjay Katariya

Agentic AI in Manufacturing: 5 Processes That Go First

Sanjay Katariya — Sat, 10 Oct 2026 10:13:05 +0000

Nobody needs to automate the whole plant at once.
The best place to start is one process where two things are already true: the data exists, and people repeat the same task or question every day.
That is where agentic AI becomes practical.

Order status queries “How far has my order reached?” is one of the most repetitive questions in manufacturing. An AI agent can read order records, production stages and dispatch updates from the ERP and answer directly. What needs to exist first: accurate, regularly updated order data. If the ERP is outdated, the AI will simply deliver the wrong answer faster.
Quoting with many variables In many manufacturing companies, quoting still depends on one experienced person. An agent can read specifications, rates, material data and pricing rules, then prepare a draft quote for human review. At Utech Waterproofing, once the quoting logic was captured in a system, quote preparation moved from days to minutes. What needs to exist first: the quoting rules must be documented clearly.
Production exception alerts Production issues often appear in the data before they become obvious on the floor. An agent can compare actual production with planned targets and alert the right person when something goes off track. That could mean a delayed stage, slower output or an order sitting too long in one step. What needs to exist first: timely production data and clear thresholds.
Quality documentation Quality teams often spend hours combining inspection records, batch data and test results into the required format. An AI agent can assemble that documentation, identify missing entries and keep the final output consistent. What needs to exist first: quality information must be captured digitally rather than only in paper registers.
Dispatch and field coordination Questions such as “Has the vehicle left?” or “When will it reach?” often create unnecessary phone calls. An agent can read dispatch records, vehicle details and delivery confirmations, then keep customers or field teams updated automatically. What needs to exist first: dispatch events must be recorded as they happen. Why these five come first All five have the same pattern: structured data + repetitive work. That makes them strong starting points for agentic AI. More complex processes involving subjective judgment or unstructured information can come later. There is another advantage: you do not necessarily need to replace your ERP. An AI layer can work with the systems your team already uses, reading from the ERP and helping people get answers or take action faster. Start with one process Do not begin with a plant-wide AI programme. Start with the process where your data is strongest and your team loses the most time. Prove the value there. Then move to the next one. At Accucia Softwares, we see agentic AI in manufacturing as a process-by-process journey, not a single transformation project. Read full blog -

Pharma Mobile Apps: What Keeps Doctors Coming Back?

Sanjay Katariya — Fri, 09 Oct 2026 12:11:46 +0000

A pharma brand app competes with every other icon on a doctor’s phone.
Across 250+ pharma mobile and web builds, one lesson has stayed consistent: getting the install is easy compared with earning the second visit.
The apps that survive are not the ones with the longest feature list. They are the ones that help doctors get useful information quickly, without depending on a rep.
What pharma apps are really for
Most successful pharma apps serve three practical purposes.
Brand engagement: They keep the brand useful between rep visits by making product information and updates available when the doctor actually needs them.
Product launches: They give doctors one consistent place to access launch information, clinical content and new product updates.
Doctor communication: They create an ongoing channel for product information, educational content and responses to common questions.
The test is simple: can a busy doctor get value from the app in under a minute?
Installs are not the real metric
A field force can drive installs.
A rep asks. The doctor downloads the app. The dashboard looks good.
But the more important question is:
Does the doctor open it again without being asked?
That is where the difference appears.
Apps built mainly around what the brand wants to communicate often get installed and forgotten. Apps built around what the doctor needs in a working moment have a better chance of being reopened.
That means fewer taps, faster answers and useful content without forcing the user through unnecessary screens.
Our rule is to build the rep-free journey first.
A doctor should be able to open the app with a question, find the answer and leave without needing someone to explain how the app works.
Put AI where users already are
One pharma engagement made this especially clear.
Employees were spending too much time searching for product and process information across company documents. Instead of introducing another tool, we embedded an AI chatbot inside the app they were already using.
The result was:

75% less time per query
95% response accuracy
40% faster onboarding
8-month payback The larger lesson was not only about AI. It was about placement. Intelligence inside an existing workflow is often more valuable than asking users to adopt another app. The same principle applies to doctor engagement. Launch timing matters A good app can still underperform if it launches at the wrong time. Launching alongside a product launch gives the app an immediate purpose. The field team has something new to show, doctors have a reason to open it and the content feels current. Launch in a quiet period and the first experience may feel empty. That is why the product calendar should influence the app roadmap from the beginning. Accucia’s view A pharma app should not be judged by how many people installed it. It should be judged by whether they came back. At Accucia Softwares, our experience across 250+ pharma engagement builds has shaped a simple approach: Build for the doctor’s need first. Make the app useful without a rep. Add intelligence inside the existing experience. Measure return use, not installs. If you are planning a pharmhttps://www.accucia.com/blog/pharma-mobile-apps-lessons-from-250-doctor-engagement-buildsa engagement app or adding AI to an existing one, start with the workflow doctors or employees already use most. Read full blog-

Software Maintenance and Support: Choosing the Right Model

Sanjay Katariya — Sat, 03 Oct 2026 12:19:14 +0000

Warranty, AMC, retained hours or managed service? The right choice depends on what happens after your build team leaves.
The riskiest point in a custom software project may not be launch day. It can be month seven.
The warranty has ended. The delivery team has moved to another project. Nothing appears broken yet, but nobody clearly owns the system.
That is when alerts can go unread, credentials expire, backups remain untested and documentation slowly falls behind the code. Pasted text
Software Maintenance Is More Than Bug Fixing
Software maintenance services keep a working system working.
The source article separates ongoing work into several categories, including corrective maintenance for discovered problems, adaptive maintenance for changes in the surrounding environment, and work that improves or extends the system. Pasted text
For a practical support contract, four areas should be clearly separated:
Warranty — defects against the agreed scope during a fixed post-launch period.
Corrective maintenance — faults discovered after warranty.
Adaptive maintenance — updates required because browsers, operating systems, SDKs, payment gateways, certificates or dependencies change.
New features — functionality that was not part of the original handover.
Putting everything under one vague “support” budget is where disagreements begin. Pasted text
Warranty vs AMC vs Retained Hours vs Managed Service
There is no single support model that fits every application.
Warranty only can work for simple, stable internal systems where downtime has limited business impact.
AMC suits established business systems that need predictable corrective and adaptive maintenance.
Retained hours work well when the application is still evolving and you want a committed block of engineering capacity.
Managed service with SLA is designed for systems where downtime can interrupt critical business processes and monitoring, incident response and defined restoration targets matter. Pasted text
The simplest question is:
How much downtime can your business tolerate?
If four hours offline is inconvenient, an AMC may be sufficient.
If four hours stops invoicing, operations or field teams, you probably need contractual service levels rather than AMC-level expectations.
What a Useful SLA Looks Like
An SLA should be understandable by the person experiencing the business problem—not only by an engineer.
A practical structure might look like this:
S1 Critical: Core system or process completely unavailable.
First response: 30 minutes, 24×7
Restore/workaround: 4 hours
S2 High: Core process degraded or a department/site blocked.
First response: 2 hours within cover hours
Restore/workaround: 1 working day
S3 Medium: Secondary function unavailable but work can continue.
First response: 1 working day
Restore/workaround: 5 working days
S4 Low: Cosmetic issues, usability problems or minor requests.
First response: 3 working days
Resolution: next scheduled release Pasted text
And remember: response time is not resolution time.
A vendor acknowledging your S1 ticket quickly does not mean the service has been restored. Both targets should appear in the agreement. Pasted text
Knowledge Continuity Matters
Support quality often comes down to one question:
Who still understands the system six months after launch?
Good continuity requires current architecture documentation, integration details, environment information, scheduled-job documentation and practical incident runbooks.
There should also be a named engineer who knows the codebase and a backup who has actually worked with the system. Pasted text
Don't Forget the Exit
A good support agreement should explain what happens when the relationship ends.
That includes current documentation, runbooks, credential handover, knowledge-transfer time and a final backup that your organisation can restore independently.
These terms are much easier to negotiate when signing the agreement than when leaving it. Pasted text
The Bottom Line
Software support should not begin with the question, “What is the monthly maintenance price?”
Start with:
What needs to stay running? Who owns it? How quickly must it recover? And who still understands it when the original build team is gone?
Once those answers are clear, choosing between warranty, AMC, retained hours and managed service becomes much easier.

Read full blog

Offshore Development Centre in India: A Practical Setup Guide

Sanjay Katariya — Thu, 01 Oct 2026 10:26:28 +0000

An ODC is not a cheaper contractor. It is a second engineering office that happens to be somewhere else.
The companies that get value from an Offshore Development Centre (ODC) treat it that way from week one.
The ones that treat it as a ticket queue usually get exactly that: a ticket queue.
After running this model from Pune across 730+ projects, 500+ clients and 25+ verticals, here are the practical lessons that matter.
ODC vs Staff Augmentation vs Project Outsourcing
These three models are often grouped together, but they solve different problems.
Staff augmentation works when you need specific skills for a limited period and are prepared to manage those developers directly.
Project outsourcing works when there is a clear scope, milestones and finish line.
An ODC makes sense when the roadmap continues, domain knowledge compounds and you want the same engineering team working on the product 12–18 months from now.
A practical ODC usually starts with four to six people.
For a six-person pod, a useful structure is:
1 Senior Engineer → 3 Mid-Level Engineers → 1 Junior Engineer → 1 QA
And QA should be there from week one—not introduced when the codebase already has hundreds of files and a deadline. Pasted text
The First 12 Weeks Matter More Than the Sales Deck
Do not expect an ODC to start shipping major features immediately.
A healthy ramp looks more like this:
Weeks 1–2: Accounts, environments, repository access and architecture walkthroughs.
Weeks 3–4: Shadow the existing sprint, map the system and merge the first low-risk pull request.
Weeks 5–7: Establish the definition of done, regression testing and ownership of the first complete sprint.
Weeks 8–10: Introduce written reporting, escalation processes and measure baseline velocity.
Weeks 11–12: Clear documentation debt, review the team structure and create the next 90-day plan.
Weeks one to four producing relatively little visible output is not necessarily a problem.
If an unfamiliar offshore team is shipping major features in week two, ask what discovery work it skipped. Pasted text
Governance Is Usually Where ODCs Fail
The classic failure is not an engineering team doing nothing.
It is a team that looks busy while the client cannot tell whether that activity is useful.
Four simple things prevent much of this:
One named owner on each side. Someone must be able to answer questions and make decisions.
A written weekly report. What shipped? What slipped? What is blocked? Who owns the next action?
A written definition of done. Code review, testing, documentation and staging deployment should not depend on interpretation.
A real escalation process. “Email us if something goes wrong” is not an escalation path. Pasted text
Code and IP Should Be Yours From Day One
Your repository should sit inside your GitHub, GitLab or Azure DevOps organisation.
The offshore team should be contributors—not owners of the repository.
IP assignment also deserves attention. Under Section 19 of India's Copyright Act 1957, copyright assignment needs to be written and signed. The agreement should explicitly address the work, term and territory rather than relying on a generic “all IP belongs to the client” sentence. Pasted text
Timezone Overlap: Use Numbers, Not Adjectives
This is where offshore sales decks often become vague.
Our standard India working day is 09:30–18:30 IST.
That provides roughly:
UK: 4–5 hours
Western/Central Europe: 5–6 hours
UAE: 8 hours
Saudi Arabia/Bahrain: 7 hours
US Eastern: effectively zero on a normal India schedule
US Pacific: zero
Australia Eastern: around 2–3 hours depending on daylight saving
US Pacific deserves particular attention.
A normal Indian workday does not provide useful Pacific overlap.
Getting around four to five hours requires a dedicated evening roster—staffed and paid specifically for that schedule.
Trying to manufacture that overlap by repeatedly asking a normal day team to stay late is not a sustainable operating model. Pasted text
What Actually Drives ODC Cost?
Headcount alone is a poor way to compare ODC proposals.
Seniority mix usually moves the number most. A senior-heavy pod can cost substantially more than a junior-heavy team of the same size, while potentially costing less per unit of usable software.
Other drivers include:
Skill scarcity: Platform, data and experienced AI engineers generally cost more than general application developers.
Compliance: On-premise deployment, restricted-device policies and external audits add engineering effort.
Contract duration: A longer commitment gives the provider more room to recruit and plan ahead.
So when comparing proposals, compare the team shape and operating model, not just the monthly developer rate. Pasted text
When You Shouldn't Build an ODC
An ODC is a management commitment before it is a procurement decision.
There are situations where another model makes more sense.
If your roadmap has a clear finish line, consider a fixed-scope project.
If you need fewer than four people, staff augmentation may be simpler.
If your core team operates on US Pacific time and you will not fund an Indian evening roster, the overlap maths may make a nearshore model more practical.
Most importantly, if you cannot name someone on your side who can spend roughly half a day each week owning the relationship, an ODC is likely to struggle. Pasted text
The Bottom Line
The strongest Offshore Development Centres in India are not treated as collections of inexpensive developers.
They operate like a second engineering office.
The client owns the roadmap. The engineering team builds domain knowledge. Governance is written down. Code stays in the client's environment. Timezone coverage is planned rather than promised.
When those foundations are right, offshore stops being primarily about geography.
It becomes about building a stable engineering capability that can compound over years.
Read full blog

What ISO 27001 Really Costs an Indian Software Company

Sanjay Katariya — Wed, 30 Sep 2026 13:45:32 +0000

When companies budget for ISO 27001, they often focus on one number: the certification body’s fee.

That is usually not the biggest cost.

The real investment is the time your engineering, security, management, and operations teams spend building an Information Security Management System (ISMS), closing control gaps, collecting evidence, and preparing for audits.

For a mid-sized Indian software company, understanding that internal effort before starting can prevent a major budgeting mistake.

The Five Costs Behind ISO 27001

ISO 27001 certification costs generally fall into five areas:

Gap assessment
This identifies where your current security practices fall short of ISO 27001 requirements.
Building the ISMS
Policies, risk assessments, access controls, supplier reviews, incident processes, secure development practices, and other controls need to be documented and operational.
Tooling
ISO 27001 does not require specific software. However, gaps may require better asset management, centralised logging, endpoint controls, or access-review systems.
Stage 1 and Stage 2 audits
This is the certification body's direct cost. ISO/IEC 27006-1:2024 determines audit time based largely on the effective number of people within scope.
Surveillance audits
Certification runs on a three-year cycle, with surveillance audits after the initial certification.

A useful rule: ask the certification body for the audit-day count before asking for the final price.

The Cost Most Proposals Leave Out

The biggest hidden cost is your own team’s time.

ISO/IEC 27001:2022 contains 93 Annex A controls. Each needs to be considered and justified through the Statement of Applicability.

For a software company with roughly 60–150 employees, our working model estimates:

Scoping and gap assessment: 5–10 person days

Risk assessment and treatment: 10–15 days

Policies and procedures: 20–30 days

Engineering and control-gap remediation: 30–60 days

Evidence collection: 10–20 days

Internal audit and corrective actions: 5–10 days

That puts the internal workload at roughly 80–145 person days, spread across the implementation period.

For many companies, that internal effort can cost more than the certification audit itself.

What Makes ISO 27001 More Expensive?

The biggest variable is scope.

A company certifying one product and its supporting delivery team will usually face a smaller implementation than one putting every department, office, application, and employee into scope.

Other major cost drivers include:

Headcount: More people within scope generally means more audit time.

Multiple offices: Additional locations can increase audit complexity.

Cloud vs on-premise infrastructure: Cloud providers may already provide evidence for certain infrastructure controls, while on-premise environments put more responsibility directly on your organisation.

Existing processes: Companies already performing access reviews, change management, incident logging, backups, and supplier assessments have less work to build from scratch.

Narrowing scope can therefore reduce cost—but it should be done deliberately. The certification scope appears on the certificate, and enterprise procurement teams can check whether it actually covers what they are purchasing.

How Long Does ISO 27001 Take?

For a first certification with a meaningful scope, nine to twelve months is a realistic planning window.

The reason is not simply documentation.

Stage 2 examines whether controls are actually operating. Auditors need evidence such as access-review records, training records, incident logs, supplier reviews, internal audits, and management reviews.

You cannot create months of operational evidence overnight.

That is why adding more consultants does not necessarily turn a nine-month implementation into a three-month one.

ISO 27001 vs SOC 2

Both help customers evaluate security, but they work differently.

ISO 27001 results in certification against an international information-security management standard. It uses 93 Annex A controls and includes Stage 1, Stage 2, surveillance, and recertification audits.

SOC 2 produces an auditor's report under AICPA standards. Organisations define controls against selected Trust Services Criteria, and a Type 2 report examines their operation over a defined period.

Which one matters more depends heavily on what your customers and procurement teams actually request.

Doing both simply because they are well-known security frameworks can consume substantial engineering time without necessarily helping sales.

What ISO 27001 Does Not Solve

ISO 27001 is an information security management system certification.

It is not CERT-In empanelment.

It also does not automatically establish Indian data residency.

If a tender specifically requires an audit by a CERT-In empanelled organisation, ISO 27001 does not replace that requirement.

Similarly, data residency depends on your hosting architecture and contractual requirements—not simply whether your organisation holds an ISO certificate.

Should a Mid-Sized Software Company Pursue It?

Start with your sales pipeline rather than the certificate.

Look at your last 8–12 enterprise opportunities.

How many were delayed or lost because of a security certification requirement, security questionnaire, or procurement requirement?

If ISO 27001 repeatedly appears as a buying requirement, certification can become a commercial enabler.

If customers are not asking for it, committing nine months and potentially more than 100 internal person days deserves much closer scrutiny.

Accucia’s Current Position

Accucia is currently implementing an ISO 27001 information security management system.

An auditor has been appointed, with certification targeted for Q1 2027. Accucia is not ISO 27001 certified today, and ISO 9001 is also currently in progress.

That distinction matters.

ISO 27001 should not be treated as another logo for a website footer. It is an operating system for information security—and the largest investment is often not the certificate.

It is the work required to make the organisation ready to earn it.

Read full blog

One Elevator Service ERP. Three Gulf Markets. No Local Office.

Sanjay Katariya — Tue, 29 Sep 2026 12:41:58 +0000

What we learned rolling out ElevatorPlus across the UAE, Saudi Arabia and Bahrain—from Pune.
Most software case studies start with a percentage.
“40% faster.”
“30% more productive.”
“50% fewer errors.”
We are not doing that here.
We cannot evidence those numbers for these three operators to a standard we would defend in front of their customers.
What we can show is what actually changed during the rollout—and what the field forced us to change.
Three operators. Three countries. One platform.
The same elevator service platform now supports:
EPIC ME Technical Works LLC in the UAE
Triolift in Saudi Arabia
Gulf Integrated Vertical Solutions in Bahrain
Accucia delivered the platform from Pune, India. We have no Gulf office, trade licence or local delivery team. Pasted text
That made the implementation question more interesting:
Can one system support technicians, AMCs, breakdowns and service operations across three different Gulf markets remotely?
Yes—but the software itself was not the hardest part.
The difficult part was adoption
The platform creates one operational record around each lift.
That includes the asset register, AMC and warranty details, complaints, technician scheduling, spare parts, preventive maintenance and customer-facing job status. Pasted text
But a good feature list means very little if technicians do not use it.
We therefore trained supervisors first using real jobs from their own operation. Those supervisors then trained their technicians.
That produced much more useful feedback than sending an outside trainer into the field. Pasted text
We deliberately ran two systems for a month
For the first month, the old and new processes ran together.
Paper job cards and spreadsheets stayed active alongside the app.
It was slower. It created duplicate work. Nobody particularly enjoyed it.
But it exposed problems before the old system disappeared.
By week three, the field had already forced three important changes. By week six, spreadsheets were retired from daily work. Pasted text
Three things technicians changed

We simplified the reason codes. The original closure screen used a long dropdown written in engineering language. Technicians often selected the first available option. We shortened it, rewrote it in plain language and used mandatory photos instead of relying heavily on free text.
We made job cards offline-first. Machine rooms are often in basements or roof plant rooms where mobile signal is unreliable. The app now stores the job locally and syncs when the device reconnects.
We moved final closure confirmation to supervisors. The technician marks the work as done. The supervisor confirms closure. That made the complaint-to-closure history more trustworthy. Pasted text None of these changes were in the original scope. That became one of the biggest lessons from the rollout: When implementing field-service software, budget for a change window in month one. Treat field feedback as part of the build, not rework.

Then came the Gulf working-week problem
Running one platform across the Gulf does not mean running one calendar.
Saudi Arabia operates Sunday to Thursday. Bahrain makes Friday the weekly rest day while the second rest day can depend on the employer. UAE private-sector companies can also set their own working arrangements within applicable rules.
So we stopped thinking in terms of a “Gulf working week.”
The calendar is configured per client, not simply per country. Pasted text
Timezone overlap helps too.
A Pune team working 9:30 AM–6:30 PM overlaps with 8:00 AM–5:00 PM in Dubai and 7:00 AM–4:00 PM in Riyadh and Manama.
Sunday requires a separate on-call arrangement because it is a working day for Saudi and many Bahrain operations while being a weekend day in India. Pasted text
So what actually changed?
Not a marketing percentage.
Something more concrete.
Asset records: branch spreadsheets → one register keyed to each lift.
Complaints: phone calls and WhatsApp → timestamped job cards with reason codes and photos.
Preventive maintenance: manually prepared schedules → generated from AMC records.
Stock: month-end reconciliation → parts issued and returned against jobs.
Renewals: price-only conversations → service history available for each lift. Pasted text
The lesson we would carry into the next rollout
We would build offline-first job cards from day one.
And we would migrate one branch completely before expanding to the others.
Because the biggest implementation risks were not hidden inside the code.
They were in basements with no signal, spreadsheets with duplicate lift records, technician habits, different working calendars and workflows that looked perfectly reasonable until someone actually tried to use them. Pasted text
That is what implementing field-service software actually looks like.
Not installing software. Changing how the work moves.
Read full blog

Software Maintenance and Support: What Happens After Go-Live?

Sanjay Katariya — Mon, 28 Sep 2026 12:09:22 +0000

The software is live. The build team has moved on. Now, who owns it?
The riskiest point in a custom software project may not be launch.
It may be month seven.
The warranty has expired. The delivery team is working on something else. Nobody has clearly decided who owns the live system.
Nothing has failed yet.
That is what makes it dangerous. Pasted text
Maintenance Is More Than Fixing Bugs
Software maintenance keeps a working system working.
Corrective maintenance fixes discovered problems. Adaptive maintenance keeps the system compatible as browsers, operating systems, APIs, SDKs and other dependencies change. Perfective and preventive work improve the system or address issues before they surface. Pasted text
Your software can need maintenance even when nothing appears broken.
Which Support Model Fits?
There are four common approaches:
Warranty — Covers defects against the agreed scope for a fixed period after launch.
AMC — Provides ongoing corrective fixes, dependency updates and agreed minor changes.
Retained hours — Gives you a monthly engineering block that can be directed toward fixes or improvements.
Managed service with SLA — Adds monitoring, incident response, on-call coverage and contractual response and restoration targets. Pasted text
The simplest test is downtime tolerance.
If four hours offline is inconvenient, an AMC may be enough.
If four hours offline stops invoicing, orders or field operations, you need clearly defined SLA coverage. Pasted text
What Should an SLA Actually Tell You?
A useful SLA should define severity in business language.
S1 Critical: Core operations cannot continue.
S2 High: A core process is seriously degraded.
S3 Medium: A secondary function fails, but work can continue.
S4 Low: Cosmetic issues, questions or minor changes.
And one distinction matters:
Response is not resolution.
A response means an engineer has acknowledged the incident and started work. Resolution means the service has actually been restored, potentially through a workaround. Pasted text
AI Needs Another Layer of Support
Traditional application support asks:
Did the software run?
AI operations must also ask:
Was the answer right?
An AI application can be technically healthy while producing the wrong output. That means monitoring needs to extend beyond uptime and error rates to output quality, evaluation results, fallback rates and model behaviour. Pasted text
The Question to Ask Before the Build Team Leaves
Whatever support model you choose, clarify ownership.
Keep documentation current. Maintain incident runbooks. Have a named engineer who understands the system—and a named backup who can step in. Pasted text
Because the biggest post-launch risk is not always broken software.
It is software that still works, but nobody owns.
At Accucia, that is why we prefer defining warranty, corrective maintenance, adaptive maintenance and new feature work separately instead of hiding everything inside one support line item. Pasted text
How does your organisation handle software ownership once the original build team moves on?

read full blog

Your Company Has Plenty of Data. The Problem Is Knowing What Matters.

Sanjay Katariya — Tue, 22 Sep 2026 12:03:41 +0000

When spreadsheets, exports and monthly reports stop helping, a BI dashboard can turn scattered numbers into decisions.

Most companies do not have a data problem.

They have data everywhere.

Sales numbers in the CRM. Financial data in the ERP. Customer activity in databases. Operational information in SaaS tools. And, inevitably, several spreadsheets maintained by different people.

The real problem is getting all of that information into a form that someone can actually use to make a decision.

That is where a Business Intelligence (BI) dashboard becomes useful.

A dashboard is more than a collection of charts

A BI dashboard brings important metrics and KPIs from multiple sources into one interactive view.

Instead of waiting for somebody to export data, update a spreadsheet and prepare a monthly report, teams can work with live or near-live information and drill into the numbers when something changes.

But there is an important distinction.

The dashboard is only the visible layer.

Behind it sit the databases, APIs, data pipelines, warehouse and BI tools that make those numbers trustworthy. A beautiful dashboard built on unreliable data is still an unreliable dashboard.

When do spreadsheets stop being enough?

Usually, the warning signs appear before anyone formally asks for a BI system.

Your engineering team is repeatedly running SQL queries for management.

Someone exports CSV files every week.

Two departments produce different numbers for the same KPI.

Leadership is making decisions using reports that are already several days old.

Or your spreadsheet has simply become too complicated to maintain confidently.

These are signs that reporting has become an operational process of its own.

At that point, the question is not whether Excel or Google Sheets are useful. They are.

The question is whether they are still the right place to run your company's decision-making.

Not every dashboard should look the same

An operations manager needs to know what is happening now.

An analyst may need months of historical data to identify a pattern.

A CEO may only need a small number of metrics showing revenue, growth, acquisition cost and churn.

Those are three different jobs, and they should not automatically become one enormous dashboard.

The best dashboards start with the decisions people need to make—not with a list of every metric the company can technically display.

And sometimes you do not need a dashboard

If your reporting requirements are simple and infrequent, spreadsheets may still be enough.

If you are an early-stage company still validating assumptions, building a full BI layer may be premature.

And if your underlying data is inconsistent, building a dashboard first can make things worse by giving unreliable numbers a more convincing interface.

The question we prefer to ask

Instead of starting with:

“Which BI tool should we buy?”

Start with:

“Which decisions are taking too long because the information we need is scattered across different systems?”

That question changes the project.

Because the goal of Business Intelligence is not to put more charts on another screen.

It is to give the right person a trustworthy answer while there is still time to act on it.

Read full blog -

The UAE ERP Cost Most Buyers Miscalculate Before the Project Starts

Sanjay Katariya — Mon, 07 Sep 2026 12:40:51 +0000

When a UAE company evaluates an offshore ERP or software vendor, the conversation usually starts with features, integrations, timelines and development cost.

But two questions deserve to come much earlier:

What happens to VAT?
And where will our data actually sit?

Getting either one wrong can distort the vendor comparison before the technical evaluation has even started.

The 5% VAT that may not be a real cash cost

One misconception we still encounter is a UAE buyer adding 5% VAT directly to the price of an offshore software build.

For a taxable UAE business importing relevant services, Article 48 applies the reverse-charge mechanism. The overseas supplier does not charge UAE VAT; the UAE recipient accounts for it. Where the buyer has full input-tax recovery, the output VAT and recoverable input VAT offset each other.

Take a simple AED 100,000 software project:

Offshore vendor invoice: AED 100,000
Reverse-charge VAT at 5%: AED 5,000
Input VAT recovered: AED 5,000
Net VAT cash cost: AED 0

That does not mean VAT can be ignored. Businesses making exempt supplies may have restricted recovery, in which case part of the VAT can become a genuine cost.

But for a business with full recovery, adding another 5% to an offshore vendor's commercial price can create the wrong comparison.

The second question is data

Once the commercial position is clear, the next conversation should be about where the system and its data will live.

Cross-border transfers of personal data are governed by Article 23 of the UAE's federal PDPL. Depending on the circumstances, transfers can involve adequacy or safeguards such as contractual protections and other permitted grounds.

This makes several questions worth asking every offshore vendor:

Where will production data be hosted?
Which subprocessors can access it?
In which countries are those subprocessors located?
What happens to the data when the contract ends?
What are the breach-notification obligations?

For healthcare, the conversation is different again. UAE health data is subject to a stricter localisation regime, with defined exceptions rather than a general permission to host patient data offshore.

Ask before you shortlist, not after

Tax and data questions should not be paperwork left for the final procurement meeting.

They affect the real project cost, architecture, hosting model, contracts and sometimes the vendor shortlist itself.

For UAE businesses considering an ERP build with an offshore development team, the commercial position can be more straightforward than expected. Accucia's UAE ERP guidance similarly explains its offshore delivery model and reverse-charge approach.

The better vendor evaluation question is therefore not simply:

“How much will you charge to build our ERP?”

It is:

“What will this arrangement actually cost us, where will our data sit, and what protections are written into the contract?”

For a deeper breakdown of UAE VAT, PDPL, offshore ERP delivery, hosting and procurement considerations:
Read full blog -

AI Agent Development Company: How to Choose One in 2026

Sanjay Katariya — Mon, 31 Aug 2026 11:03:44 +0000

What an AI agent development company actually does

An AI agent development company builds software that decides and acts, then proves it acted correctly. A chatbot returns text. An agent reads a purchase order, checks stock in your ERP, raises a requisition and leaves an audit trail. Write access is where projects come apart.

Gartner predicted on 25 June 2025 that "over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls". It also estimates only about 130 agentic AI vendors are genuine among the thousands using the label. Anushree Verma, Senior Director Analyst at Gartner, said most such projects are "early stage experiments or proof of concepts that are mostly driven by hype and are often misapplied".

Benchmarks agree. In TheAgentCompany, which sets agents realistic tasks inside a simulated software firm, the most competitive agent completed 30% of tasks autonomously. Scope accordingly: one narrow job, done well, with a human check.

Three kinds of agent, priced very differently

Most buyers ask for "an AI agent" and mean one of three different things. The gap comes from permissions, not cleverness.

Agent type	What it does	Relative build cost	Main risk	Time to first production use (our delivery experience)
Read-only assistant	Answers questions over your documents and reports. No writes.	Lowest	A wrong answer, contained because no record changes	3 to 6 weeks
Workflow agent	Runs a defined process and writes back into ERP or CRM	Middle	A bad write, plus the work to reconcile it	8 to 16 weeks
Autonomous agent with approval gates	Plans multi-step work, pausing at checkpoints for a named approver	Highest	Silent drift across many small decisions	4 to 8 months, after a workflow agent is stable

A read-only assistant is the right first project for almost everyone. It hands you retrieval quality, access control and adoption in one go, with no risk of a wrong ledger entry. A vendor who pushes you straight to autonomy is selling, not advising.

The nine questions to ask an AI agent development company

Send these to every shortlisted vendor in writing. The answer you want is under each one.

Which model are you using, and what happens when it changes?

Wanted: the model sits behind an internal interface and is swappable, chosen per task rather than per brand, with the evaluation set rerun on every version change. Vendors locked to one model bill you for a rewrite later.
How will the agent reach our systems?

Wanted: documented, permissioned interfaces, preferably Model Context Protocol servers or existing APIs, with a named owner per connection. Not screen scraping, not direct database writes, not a shared admin credential.
How do you prove accuracy before go-live?

Wanted: a fixed set of real cases from your business with known correct outputs, a scoring method, a pass threshold agreed before build, and a rerun on every change. "We tested it manually" is not an evaluation method.
What do the guardrails block, and where are they enforced?

Wanted: hard limits in code, not in a prompt. Value caps, allowed record types, allowed actions, allowed hours, blocked fields. Prompt instructions are guidance, not control.
Where does a human stay in the loop?

Wanted: a named role approves defined classes of action, the approval is logged with the approver's identity, and the agent stops when approval times out. The India AI Governance Guidelines, released by MeitY in November 2025, state that "humans should, as far as possible, have final control over AI systems".
What gets logged, and for how long?

Wanted: every input, tool call, decision, output and approver, stored in your tenancy, queryable by your team, for a retention period you set. The same guidelines recommend "regular monitoring and testing, audit trails, and reporting protocols". Logs held only by the vendor leave you unable to investigate an incident.
Who owns the code, the prompts and the evaluation set?

Wanted: you own all three, on a written assignment, delivered into your repository from week one. Prompts are the product in agent work. A vendor who keeps them is keeping the part you paid to learn.
What is the exit plan?

Wanted: a documented handover covering repository access, environment variables, deployment runbook, evaluation instructions and a training session for your team. Agree it at contract stage, not at exit.
Who supports this in month seven?

Wanted: a named support model with response times, a change budget for model and API drift, and one person from the build team. Month one is easy. Month seven is when an upstream API changes and nobody remembers why a rule exists.

[Diagram: Agent connected to ERP, CRM and Document Store through a middle MCP layer. See Inline Media Notes for the generation prompt.]

Integration is the real cost, not the model

Model calls are a small line item. The work sits in reaching your systems safely, and in the state of the data you find there.

Model Context Protocol, released by Anthropic on 25 November 2024, is an open standard for connecting AI systems to the places data lives. It turns integration into a reusable server per system: build one MCP server for your ERP, and every future agent, and every model you swap in, reaches it the same way. In December 2025 it was donated to the Agentic AI Foundation under the Linux Foundation, with reported figures of over 97 million monthly SDK downloads and 10,000 active servers.

For most Indian mid-market buyers this is the cheaper route: keep the ERP you already paid for and add a controlled interface on top. We set that out in MCP for ERP, and we run MCP integration separately from agent build.

Data quality is the other half. If your item master holds four spellings of the same part, the agent will not fix that. It will act on all four. Retrieval has the same problem, which is why enterprise RAG work starts with document cleanup, not model selection.

AI agent development cost: what actually moves the number

We do not publish price bands, because a band quoted without your system list is a number you will be angry about later. Here are the variables instead. See our cost page.

Six things drive ai agent development cost, roughly in order of impact.

Systems touched. One system is a project. Four systems is four integration projects plus coordination, each with its own auth model, rate limits, sandbox availability and internal owner.

Read versus write. Read access needs correctness. Write access needs correctness, reversibility, approval design, reconciliation and a rollback path. Adding writes to a working read-only agent is a second project, not a change request.

Data quality. Clean masters and consistent formats make retrieval cheap. Scanned PDFs, inconsistent naming and eight years of free-text notes do not. This is the most common reason a quote moves after discovery.

Evaluation depth. Fifty test cases cost less than five hundred. Five hundred is what you need when a wrong output carries financial or regulatory consequence. Decide that depth deliberately, not in production.

Compliance review. Where the agent touches personal data, the Digital Personal Data Protection Rules, 2025, notified on 14 November 2025 with an eighteen month phased compliance period, govern how you handle it. Where a CERT-In empanelled audit is required, the client commissions the auditor and we implement every finding, which takes calendar time.

Support commitment. A three month warranty costs less than a twelve month retainer with a change budget for model and API drift. The retainer is usually the better buy, because agents degrade quietly when upstream systems change.

Engagement models, and what each one suits

Model	What it is	Best for	Watch out for
Fixed scope pilot	One agent, one process, agreed evaluation threshold	A first project needing board approval	Scope creep. Freeze the process definition first
Retained squad	A standing team running several agents against a roadmap	Three or more processes queued, with an internal owner	Paying for capacity you cannot feed. It needs a real backlog
Build and transfer	Vendor builds, documents, trains your team, hands over ownership	In-house engineers who want the capability	A handover on paper only. Put the training sessions in the contract

Most first-time buyers should take a fixed scope pilot on a read-only assistant. It is the cheapest way to find out whether your data is ready.

Red flags

Accuracy claimed with no evaluation set. "It is 95% accurate" means nothing without the test cases, the scoring method and who wrote them.

No rollback plan. If the agent writes to a system of record, there must be a defined way to reverse what it wrote.

Refusal to hand over prompts. Prompts and the evaluation set hold your process knowledge. Withholding them is lock-in, and the second project gets priced that way.

Pricing per agent rather than per outcome. That rewards a vendor for splitting one workflow into five agents. Price the outcome and the systems in scope.

A demo on the vendor's own data. Ask for it on your documents, with your terminology and edge cases. A refusal means the demo does not generalise.

How we work

Accucia Softwares was founded in Pune in 2018, so there are eight years of delivery behind this, most of it ERP, workflow and integration work rather than AI demos. Full scope is on our AI agents service page. Our own product Sellora is the working proof: one agent reading and acting on real HR data through MCP, in production.

On hosting, we deploy in-region on request, on AWS, Azure or GCP with the region chosen to meet your requirement and infrastructure billed to you at cost, or on your own on-premise servers. Our sub-processors are AWS, Azure, GCP and client on-premise infrastructure, and nothing else.

On certifications we will be exact. We do not hold ISO 27001. Implementation is underway, an auditor has been appointed, and we are targeting certification for Q1 2027, January to March. We do not hold ISO 9001. That is in progress. Where a CERT-In empanelled audit is required, you commission the auditor. We are not empanelled ourselves.

Accucia's view

Most organisations asking for an AI agent should buy a data cleanup and a read-only assistant first, and we say so even when it costs us the larger project. We have declined write-access scope on first engagements more than once, because the client's master data could not support it and shipping anyway would have produced a wrong ledger entry with our name on it.

Second, integration standards matter more than model choice. Pick MCP or documented APIs, keep the model swappable, and you still own something useful in three years. A proprietary connector layer is a rewrite you have not scheduled.

Third, if a vendor will not give you the evaluation set, the prompts and the logs, the price does not matter. You are renting a black box that touches your systems of record. If you want to argue the point, talk to our team and bring your system list.

Frequently Asked Questions

What does an AI agent development company do?

It builds software agents that act inside your business systems, not just answer questions: process definition, integration to ERP or CRM, guardrails, an evaluation set with a pass threshold, logging and support. Integration and evaluation usually cost more than the model work.

How is an AI agent different from a chatbot?

A chatbot returns text. An agent acts: it reads records, calls tools, writes updates into systems and leaves an audit trail. That write capability is the whole difference in cost and risk. A wrong chatbot answer wastes time. A wrong agent write creates reconciliation work.

What drives ai agent development cost?

Six factors: how many systems the agent touches, whether it writes or only reads, master data quality, how many evaluation cases you need, whether a compliance audit is required, and the length of the support commitment. Write access and data quality move it most.

How long does an AI agent take to build?

In our delivery experience, a read-only assistant reaches production in three to six weeks. A workflow agent writing into ERP or CRM takes eight to sixteen weeks. An autonomous agent with approval gates takes four to eight months, and only after a workflow agent is stable.

Do we need MCP to build an agent?

No, documented APIs also work. Model Context Protocol is worth choosing when several agents reach the same system, because you build one server per system instead of custom plumbing per agent. Anthropic released it in November 2024 and it moved to the Agentic AI Foundation in December 2025.

Who should own the code and the prompts?

You should, in writing, from week one, including prompts and evaluation cases, delivered into your own repository. Prompts encode your process knowledge and the evaluation set your definition of correct. A vendor who retains either is building a switching cost you will pay for later.

How do you measure whether an agent is accurate enough?

With an evaluation set: real cases from your business with known correct outputs, a defined scoring method and a pass threshold agreed before build starts. Rerun it on every change, including model version changes. Any accuracy figure quoted without those three things is not verifiable.

Should an agent be allowed to write into our ERP?

Only after a read-only version has run in production with stable evaluation scores, and only with hard limits enforced in code, an approval step for defined action classes, full logging and a tested rollback path. Start with the lowest-value, highest-volume transaction type.

What happens when the agent makes a mistake?

A properly built agent logs every input, tool call, decision and approver, so you can find the mistake, see what caused it, reverse the write using the rollback path and add that case to the evaluation set. No reversal answer means no production readiness.

Can the agent run on our own servers in India?

Yes. We deploy on your own on-premise servers, or in-region on AWS, Azure or GCP with the region chosen to meet your requirement and infrastructure billed to you at cost. Data residency is decided before build starts, not changed afterwards.

What is the right first agent to build?

A read-only assistant over a document set or reporting layer that a real team uses daily. It surfaces your retrieval quality, access control and adoption problems within weeks, with no risk to a system of record. Pick a high-volume process with clear correct answers.

How do we avoid being one of the cancelled projects?

Gartner predicts over 40% of agentic AI projects will be cancelled by the end of 2027 due to escalating costs, unclear business value or inadequate risk controls. Counter all three: scope one process, agree an evaluation threshold before build, and price the support year upfront.

Read Full blog