MODEL A
Fixed-price build
A defined agent, a known number, delivered and handed over. Best when the Sprint produced a clear, bounded scope and you want budget certainty.
- Billing
- Milestone-based
- Exit
- Increment boundaries
Most people who decide they want this don't know what actually happens next, or who inside their own organisation they need to involve. This page is the whole path — what we do, what you provide, who joins, and where the exits are.
Open a stage for the detail your project manager will want.
We've already read the workflow you described when booking, so this isn't a discovery interview. We ask what breaks, what you've already tried, and what would have to be true for this to be worth your team's time. Then we tell you whether a Sprint makes sense.
Roughly one in four of these calls ends with us saying not yet — usually because the knowledge isn't written down, or the volume doesn't justify integration. You get that answer in twenty-five minutes rather than after a procurement cycle.
The only paperwork before this is a mutual NDA — no master agreement, no purchase order, nothing through procurement. That's deliberate: it means the technical question gets answered before the commercial machinery starts, rather than after you've spent six weeks on contracts for something that might not be worth building.
If your security policy won't permit sandbox access this quickly — and at many enterprises it won't — we run against a synthetic dataset whose shape you define. Weaker demo, identical workflow map and estimate.
Full Sprint detail →Two shapes, and we'll recommend one. A fixed-price build when the scope is clear and bounded — you know the number before anything starts. A retained engineer when automation is ongoing rather than a single deliverable — one person inside your team, month to month.
Every quote itemises reused components against new work. On a typical build about seventy per cent comes from the registry, and you should be able to see exactly which thirty per cent you're paying a premium for.
Assumptions are listed explicitly, because an estimate without them is a guess with a decimal point. If an assumption turns out wrong during the build, we say so at that increment rather than in a change order at the end.
Nobody enjoys this stage and every vendor understates it. At an enterprise it runs two to four weeks, occasionally longer, and it is almost always the longest single item on the path — not the engineering.
Three documents typically: a master services agreement, a data processing agreement, and your security questionnaire. We keep completed answers to the standard frameworks on file, so a questionnaire usually comes back in three to five working days rather than a month.
Start this in parallel with the Sprint if you can. The single biggest thing you can do to compress the timeline is send us your questionnaire early — we'll complete it while the technical question is still being answered, at no cost and no obligation.
What your security team will ask →Every two weeks there's a working demo, not a status deck. That cadence exists so that if the thing is going wrong you find out in week two rather than week eight — and so you can stop at an increment boundary having received working software for what you've paid.
The people who will use the agent join at least two of these demos. That isn't a courtesy: their corrections are what makes the thing accurate, and their early involvement is what makes them use it later. We learned that expensively.
The deployment that taught us →Launch is staged, never a switch. Shadow mode first, where the agent works silently and you measure it against what your people actually did. Then assist, then approve. Many clients stop at approve, and that's a legitimate end state rather than a failure to finish.
Handover is a working session with your engineers, not a document dump. Source is already in your repository, deployed to your infrastructure, documented so your team can maintain it without us. Then you decide about ongoing support — and no, declining it doesn't leave you stranded.
What ongoing support looks like →The most common reason an engagement stalls isn't budget — it's that nobody identified who signs the security questionnaire until week six.
| Role | Needed for | Time commitment | Identify by |
|---|---|---|---|
| Workflow owner | Every stage — this is the one that matters | 2 hrs a fortnight | Before the first call |
| Practitioners | Sprint days 1–2, plus two build demos | ~6 hrs total | Before the Sprint |
| IT / systems contact | Sandbox access, API credentials, deployment target | 3–4 hrs total | Before the Sprint |
| Security / legal | NDA, then questionnaire, DPA and MSA | Their own process | Now — this is the long pole |
Table 1 — Roles required, and when to have them lined up
A defined agent, a known number, delivered and handed over. Best when the Sprint produced a clear, bounded scope and you want budget certainty.
A dedicated automation engineer inside your team, in your standups and your tools, shipping against your backlog. Our specialist bench sits behind them.
A multi-person squad for a programme rather than a single agent. Drawn from IndiaNIC's 700 engineers, scaled up and down by quarter.
We don't charge licence or per-seat fees for the agents themselves, and there's no platform subscription. You pay for engineering time, in one of these three shapes. What gets built is yours, and if you stop working with us it keeps running.
None of them involve us working faster. They all involve removing waiting.
We'll complete it during the Sprint week at no cost. This alone typically saves two to three weeks, because contracting and discovery stop being sequential.
Not "someone in legal." A person with a calendar. Most stalls we see are a document sitting in an unowned inbox for eleven days.
Read-only access to non-production data with realistic shape. If that takes your IT team three weeks to provision, start it when you book the first call.
The fastest route to a second agent is a first one in production. Scope growth between proposal and contract is the most common self-inflicted delay we see.
IntegrateX is the AI agent practice of IndiaNIC Infotech Limited, which has been operating since 2000. Depending on your location you'll contract with the Indian entity, the UAE entity, or our US entity in California. Your procurement team can have audited financials, insurance certificates and references for whichever applies.
On a fixed-price build, an overrun caused by our estimate being wrong is ours to absorb. An overrun caused by something outside the stated assumptions — an API that turns out not to exist, data that isn't in the shape we were shown — is raised at the increment where we find it, with options, before any additional work happens. You will not receive a surprise change order at the end.
Yes, and some clients have. The findings pack carries no clause preventing you taking the workflow map to another vendor for a competing quote. If someone else can do the same work better or cheaper, you should know that — and if our estimate only wins when nobody else sees the requirements, we haven't earned it.
Delivery runs from Ahmedabad and Dubai with a US presence in California, so we cover European, Gulf and US-East hours comfortably and US-West with some overlap. We commit to a named window of hours that overlaps your working day, written into the engagement — not "we're flexible."
Usually not. Most AI tooling in enterprises today sits inside a single application — a support suite's own assistant, a CRM's built-in features. What tends to be missing is the layer that works across systems. If there genuinely is overlap, the Sprint will surface it and we'll say so rather than build a duplicate.
No procurement, no paperwork, no budget conversation. One call with the engineer who'd run your Sprint, and an honest answer about whether this is worth pursuing.