DEV Community: Kapil Singhal

A Pre-Production Checklist for LLM Agents: 30 Checks Before You Ship

Kapil Singhal — Tue, 03 Nov 2026 04:46:27 +0000

A prototype agent that works in a notebook is a long way from one you can leave running against real users and real systems. The gap is rarely the model. It is everything around it: evaluation, tool permissions, failure handling, observability and the boring operational work.

This is the checklist we use before an LLM agent goes to production. It is model-agnostic and framework-agnostic. Copy it into your repo as PRODUCTION_READINESS.md and tick it off honestly.

1. Scope and contract

[ ] One-sentence job description. "The agent classifies inbound support emails and drafts a reply for human approval." If you can't write it, you can't test it.
[ ] Explicit non-goals. List what the agent must not attempt, and make sure the system prompt and the tool list enforce them.
[ ] Input and output schemas. Structured outputs (JSON schema, typed tool arguments) for anything another system consumes. Validate them, and reject or retry on failure.
[ ] Success metric agreed with the owner. Pick one, such as task success rate on the eval set, escalation rate or handling time, with a baseline.

2. Evaluation

[ ] A versioned eval set in the repo: real (anonymised) inputs, expected outputs or grading rubrics, and edge cases. Start with 50–100 cases and grow it from production failures.
[ ] Automated scoring in CI. Use exact match or schema checks where you can, and rubric-based LLM grading where you can't, spot-checked by a human.
[ ] Regression gate. A prompt, model or tool change that drops the score below the threshold fails the build.
[ ] Adversarial cases. Prompt injection in user input and in retrieved documents, off-topic requests, empty and huge inputs, and other languages.
[ ] A pinned model version. Don't point production at a floating "latest" alias. Upgrade on purpose and run evals first.

# .github/workflows/agent-evals.yml (sketch)
on: [pull_request]
jobs:
  evals:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -r requirements.txt
      - run: python evals/run.py --set evals/cases.jsonl --min-score 0.90

3. Tools and permissions

[ ] Least privilege per tool. Read-only credentials unless the tool must write. Give the agent its own scoped service account, never a developer's token.
[ ] Human approval for side effects. Anything that sends a message, changes a record, moves money or deletes data waits for an approval step until the eval data justifies removing it.
[ ] Idempotent tool calls. Retries happen. Use idempotency keys so a retried "create refund" doesn't run twice.
[ ] Argument validation server-side. Treat tool arguments from the model as untrusted user input.
[ ] Allow-lists over block-lists for URLs, file paths, SQL tables and email domains the agent can touch.
[ ] Step and loop limits. Cap the number of tool calls per task and stop on repeated identical calls.

4. Failure handling

[ ] Timeouts on every model and tool call, with sensible retries and backoff.
[ ] A fallback path. When confidence is low, validation fails or limits are hit, hand off to a person with the context attached. Don't fail silently.
[ ] Provider outage plan. Decide whether to queue, degrade to a simpler flow, or switch to a secondary model, and test it.
[ ] Graceful user messaging. The user should know when a human is taking over.

5. Observability

[ ] Trace every run. Inputs, the prompt version, model and version, every tool call with arguments and results, the final output, latency and token usage, all tied to one trace ID.
[ ] PII handling in logs. Redact or hash sensitive fields before they reach your log store, and set retention.
[ ] Dashboards for success rate, escalation rate, latency (p50/p95), error rate by tool, and cost per task.
[ ] Alerts on spikes in errors, escalations, latency or spend.
[ ] A feedback loop. Human corrections and approvals are captured and turned into new eval cases.

6. Cost and rate limits

[ ] Per-task and per-day budgets enforced in code, not just watched on a billing page.
[ ] Rate limiting per user and per tenant to stop runaway loops and abuse.
[ ] Caching for repeated retrieval and deterministic sub-steps where it is safe.

7. Security review

[ ] Prompt injection mitigations. Separate system instructions from retrieved content, don't let retrieved text grant permissions, and re-check authorisation on every tool call.
[ ] Secrets in a secret manager, never in prompts, code or logs.
[ ] Data residency and processor list documented for your security and legal teams.
[ ] Threat model written down: what could a malicious user or poisoned document make the agent do, and what stops it? The OWASP Top 10 for LLM Applications is a good starting list.

8. Deployment and rollback

[ ] Prompts and configs versioned alongside the code, deployed through the same pipeline.
[ ] Staged rollout. Run in shadow mode first (the agent drafts, humans act), then send a small share of traffic, then more.
[ ] Feature flag or kill switch that turns the agent off and routes everything to the human path in one step.
[ ] Infrastructure as code for queues, workers, vector stores and secrets, so environments are reproducible.

If your platform basics such as CI/CD, environments and monitoring aren't in place yet, sort those first. An agent amplifies weak operations. Our notes on DevOps and SRE services cover the foundations we look for.

9. Handover

[ ] Runbook: how to deploy, roll back, rotate keys, update the eval set and respond to each alert.
[ ] Ownership: a named team on call for the agent, with access to traces and dashboards.
[ ] Everything in the client's or team's repo: code, prompts, eval sets, IaC and docs. No knowledge stuck in one person's head.

We use a broader version of this in our software project handover checklist, which applies to any system, not just agents.

Using the checklist

You won't tick every box on day one, and that is fine for a pilot, as long as the gaps are written down and the risky ones (permissions, approvals, kill switch) are closed. The checklist works best as a pull-request template: each change to prompts, tools or models has to say which items it affects.

If you are scoping a first agent and want the evaluation and guardrails designed in from the start, our AI agent development team works this way by default.

What would you add? I'd like to hear which checks have saved you in production.

Kapil Singhal, Director, Axentis Technologies

About Axentis Technologies: https://axentis.tech | Axentis on LinkedIn: https://www.linkedin.com/company/axentis-technologies

Aranyix: https://aranyix.tech | Aranyix on LinkedIn: https://www.linkedin.com/showcase/aranyix/

Designing a data model for geo-tagged tree plantation records

Kapil Singhal — Tue, 03 Nov 2026 04:45:32 +0000

Canonical / originally published at: https://aranyix.tech/resources/geo-tagged-tree-plantation-csr-india

Tree plantation looks like a field problem, but most of the trouble I see shows up later as a data problem. A company plants 10,000 saplings for a CSR project or a green belt condition, and a year later someone asks a simple question: how many are alive, and where? If the records were never designed to answer that, nobody can.

This post walks through the data model we use for plantation records at Aranyix. It isn't the only way to do it, but it holds up when auditors and reviewers start asking questions.

Start with the unit you will resurvey

The first decision is the unit of record. There are three common choices:

Unit	Good for	Trade-off
Individual tree	Avenue planting, high-value species, small sites	More capture effort per sapling
Plot (fixed polygon or point + radius)	Dense block planting, green belts	Survival is a sample estimate
Site boundary only	Early-stage reporting	Cannot support survival claims

Choose the unit you will come back to. If resurveys will be done by plot, the plot is your primary key, not the site.

The core entities

A minimal schema has five tables:

site: id, owner organisation, programme (CSR, EC condition, CAMPA, etc.), boundary geometry (WGS84 polygon), start date.
unit: id, site_id, geometry (point or polygon), species, planted_count, planted_at, captured_by.
observation: id, unit_id, observed_at, status (alive/dead/replaced/missing), alive_count, photo_ref, device location, accuracy_m.
activity: id, unit_id or site_id, type (watering, fencing, weeding, gap-filling), done_at, notes.
evidence: id, linked entity, file hash, captured_at, location.

The important part is that observation never overwrites unit. Planting-day counts are immutable. Every resurvey is a new row. Survival at any date is then a query, not a number someone typed into a report.

Capture rules that save you later

Location and time come from the device at capture. Don't accept gallery uploads with typed coordinates for the planting-day record. Store the reported GPS accuracy too. A point at Â±40 m is not the same evidence as one at Â±5 m.
Hash the photo on capture. Storing a content hash with the timestamp makes it easy to show later that the image hasn't been swapped.
Use stable IDs printed or tagged in the field for tree-level programmes, so the resurvey team can match records without guessing.
Keep geometry in WGS84 (EPSG:4326) for storage and exchange. Reproject only for area calculations.

Survival as a query

With the model above, survival for a unit at date D is:

latest observation at or before D: alive_count / planted_count Ã— 100

At site level you aggregate across units, and you report the share of units that actually have an observation in the window. A 92% survival figure from 20% of plots is a different claim from 92% across all of them, and your output should make that visible.

Gap-filling is an activity plus a new planted batch, not an edit to the original count. Otherwise replanting quietly inflates survival.

Between field visits

Field resurveys are expensive, so most programmes do them two or three times a year. Satellite and trend monitoring fills the gaps. It won't count saplings, but a sharp drop in a vegetation index over a plot is a good trigger for an unscheduled visit. Store these signals as observations of a different type (source = satellite) so they never get mixed up with ground counts.

Exports reviewers can use

The output that matters is usually a table plus a map: per unit, planted count, latest alive count, observation date, and an evidence link. Add the site boundary as KML or GeoJSON. We call this audit-prep evidence. It's what a reviewer needs to check the claim, not a verdict on it.

What I'd do differently next time

Agree the resurvey calendar and the unit of record before planting day, in writing, with whoever does the fieldwork. Almost every messy dataset I've inherited started with a planting drive that was organised as an event, not as the first observation in a multi-year record.

The field-side version of this, including the minimum GPS, photo and time record for planting day, is in our guide to geo tagging in tree plantation.

Kapil Singhal, Director, Axentis Technologies

aranyix.tech | axentis.tech

Aranyix on LinkedIn | Axentis Technologies on LinkedIn

Owning Your Stack After an Outsourced Build: A Software Project Handover Checklist

Kapil Singhal — Wed, 07 Oct 2026 06:42:08 +0000

Originally published at https://axentis.tech/software-project-handover-checklist/.

Most companies discover whether they really own their software at the worst possible moment: a vendor relationship ends, a key engineer leaves, or an investor's technical due diligence asks who can deploy to production tonight. If the honest answer involves "we would need to ask the agency", you have a handover problem, and it is far cheaper to solve at the start of an engagement than at the end.

This software project handover checklist is written for CTOs and founders in the US, UK, Canada and Australia who work with an outsourced team, including an India-based partner like us. It covers ownership of accounts and credentials, reproducible environments, the documentation worth insisting on, the contract basics, and how to run a handover session that proves your team can operate the system without the vendor in the room.

Why handover gets planned too late, and what that costs you

Handover is usually treated as the last line of the project plan. By then, the decisions that make it easy or painful have already been made: whose account the cloud resources sit in, whether environments were built by hand, and whether anything was written down. Typical consequences of a late handover include:

Nobody on your side can deploy, roll back or rotate a credential.
Production runs in an account billed to the vendor, so moving it becomes a migration project.
Key knowledge lives in two engineers' heads, and the next team spends its first weeks reverse-engineering decisions.
Domains, app store listings or payment accounts are registered to the wrong legal entity.

None of these are dramatic on day one. All of them become expensive the day you need to move quickly.

Ownership from day one: repositories, cloud accounts, domains and credentials

The simplest rule: anything your product depends on should be created in your company's name, with the delivery team added as collaborators whose access you can remove.

Asset	Who should own it	What to check
Source code repositories	Your organisation	Vendor engineers are members you can remove; no "real" copy lives elsewhere.
Cloud and hosting accounts	Your company, on your billing	At least two people on your side have administrator access.
Domains and DNS	Your company's registrar account	Renewal contact and payment are yours.
App store developer accounts	Your legal entity	A mobile MVP release slice is distributed through your own TestFlight or Google Play Console account.
Third-party services (email, payments, analytics, error tracking, AI model providers)	Your company	API keys are issued from your accounts, not shared from the vendor's.
Secrets and credentials	Your secrets manager or vault	Nothing sensitive in code, chat history or CI logs.
CI/CD pipelines	Your organisation	Pipeline definitions live in the repository, not only in a vendor-run tool.

If you inherit a project where this was not done, the first handover task is moving each asset into your ownership, one at a time, with a rollback plan for each move.

Infrastructure as code and reproducible environments

An environment that was built by clicking through a cloud console can only be rebuilt by the person who clicked. Ask for infrastructure defined as code (Terraform, OpenTofu, Pulumi or the cloud provider's own templates), committed to your repository and applied through a pipeline.

Alongside that, expect:

Environment configuration kept in code, with secrets referenced from your vault rather than pasted in.
A README that gets a new engineer from a fresh laptop to a running local copy, including seed or sample data.
Automated tests and build steps that run in CI on every change.
Separate staging and production environments, created from the same definitions.

The real test is simple: can an engineer who has never seen the project stand up a working staging environment using only the repository and the docs? If you want help reaching that standard, it is core work for our DevOps and SRE services.

Documentation that matters: architecture notes, runbooks, decision logs

Long documents nobody reads are not the goal. Short, current documents that a new engineer actually uses are.

Architecture overview

One or two pages: the main components, how data flows between them, external dependencies and where each piece is hosted. A simple diagram is enough.

Runbooks

Step-by-step instructions for routine and stressful tasks: deploying, rolling back, rotating a secret, restoring a backup, scaling a service and responding to the most likely alerts.

Decision log

Brief records of significant technical decisions and why they were made. These save the next team from undoing choices that had good reasons.

Known issues and technical debt

An honest list of open bugs, shortcuts and areas that need attention. A partner who hands this over freely is a partner you can trust.

For AI features, add the prompts and configuration, model versions, the evaluation set, the design of the human review and approval step, and the usage limits in place. That mirrors what we recommend in how to scope an AI pilot.

Code ownership in outsourced development: the contract basics

Technical ownership needs a legal match. Before work starts, confirm with your own counsel that the contract covers:

IP assignment of work product to your company on payment, or on terms agreed in writing.
Pre-existing vendor components, such as internal libraries, and the licence you receive to keep using them.
Open-source dependencies, with an inventory of licences so there are no surprises in later due diligence.
Exit terms: what the vendor delivers at the end, how access is revoked and what happens to any copies of your data.

This is a checklist, not legal advice. The point is to raise these terms before kickoff, not after a disagreement.

The handover session: walkthroughs, a supervised first deploy, open issues

Documents are necessary but not sufficient. Knowledge transfer from an outsourcing vendor should include hands-on proof that your team can operate the system:

Recorded codebase walkthrough. The vendor's tech lead walks your engineers through structure, key flows and tricky areas, and the recording is stored with the docs.
Supervised first deploy. An engineer from your side runs a production deploy while the vendor watches and only advises.
Rollback and restore rehearsal. Roll back a release and restore a backup to a non-production environment, following the runbooks.
Credential rotation. Rotate shared secrets and remove access that is no longer needed.
Open issues review. Walk through the known-issues list and agree who handles what.
Support window. Agree a short, defined period in which the vendor answers questions after handover.

Software project handover checklist

Area	Done when
Repositories	Owned by your organisation; vendor access removable.
Cloud, domains, app stores, third-party services	All in your company's name and billing.
Secrets	In your vault; rotated at handover.
Infrastructure	Defined as code; staging rebuilt from the repository.
Documentation	Architecture overview, runbooks, decision log and known-issues list are current.
Contract	IP assignment, vendor components, open-source licences and exit terms confirmed.
Operation	Your engineer has deployed, rolled back and restored a backup.
Support	Post-handover support window and contact agreed in writing.

If any row is incomplete, you have not finished handover yet.

Scaling after handover: in-house, extended engagement or hybrid

A clean handover gives you real choices. You can take the product in-house, extend the engagement with another scoped piece of work, or run a hybrid where your engineers own the core and a partner delivers defined workstreams. Our comparison of staff augmentation vs project outsourcing can help you pick the model for the next phase.

How Axentis builds handover into a Launch Pilot

We design every Launch Pilot to end with the checklist above already satisfied: client-owned repositories and accounts from day one, infrastructure as code where the scope includes environments, short practical documentation and a handover session in which your team runs the deploy. That is why a pilot is a useful test of any partner; our guide to paid pilot projects explains what else to watch. The same standard applies to our custom software development engagements.

FAQ

When should handover planning start?

At kickoff. Account ownership, infrastructure as code and documentation habits are set in the first week. Leaving them to the end turns a routine handover into a migration project.

What should knowledge transfer from an outsourcing vendor include?

An architecture overview, runbooks, a decision log, a known-issues list, a recorded codebase walkthrough and a supervised deploy by your own engineer, followed by a short, defined support window.

How do I avoid vendor lock-in with an outsourced team?

Own every account and credential from day one, require infrastructure as code, put IP assignment and exit terms in the contract, and rehearse a deploy and rollback by your own team before the engagement ends.

Who should own the app store accounts for a mobile MVP?

Your company. Create the Apple Developer and Google Play Console accounts under your legal entity and add the vendor as users, so tester builds and any later public release stay under your control.

Ready to start with handover built in?

If you want an outsourced build that ends with your team holding the keys, discuss a Launch Pilot with Axentis. We will scope one bounded outcome with you privately and agree the handover standard before any code is written. If you are taking over an existing codebase and want a second opinion first, talk to an expert.

If you are planning a first engagement, see how a scoped Launch Pilot from Axentis works, or read more product and engineering notes on the Axentis blog.

How to Scope a Fixed-Scope MVP Without Change-Order Chaos

Kapil Singhal — Wed, 07 Oct 2026 06:36:43 +0000

Originally published at https://axentis.tech/how-to-scope-a-fixed-scope-mvp/.

Most fixed-scope MVP disputes are not really about code. They start with a scope document that let the founder and the delivery team picture two different products, and they surface weeks later as change orders, a slipped date and a strained relationship. If you are a founder or CTO in the US, UK, Canada or Australia preparing to brief an outside engineering team, the way you write the scope will shape your cost and timeline more than any line on the proposal.

This guide shows how to scope a fixed scope MVP that both sides can deliver against: one core user journey, explicit in-scope and out-of-scope lists, written assumptions, testable acceptance criteria and change control that stays flexible. It also covers when fixed scope is the wrong model, and the cost drivers to understand before you ask anyone for a number.

Why fixed-scope MVPs fail: moving targets and fuzzy "done"

When a fixed-scope MVP goes wrong, the warning signs are usually visible in the original brief:

"Done" was never defined. "Users can manage their orders" can mean a read-only list or a full editing workflow with audit history. Both sides sign, then discover the gap at acceptance.
The scope is a feature list, not a journey. Forty bullet points with equal weight give nobody a way to decide what matters when time runs short.
Assumptions stayed in people's heads. Who supplies designs? Is the payments sandbox available? Does the partner API actually support the call you need? Unwritten assumptions become change orders.
No single decision-maker. If three stakeholders can add requirements and nobody can say no, scope grows by default.
The estimate came before the thinking. A firm figure produced from a two-paragraph brief is either padded for risk or quietly ignoring it.

Fixed scope vs time and materials: choose deliberately

Fixed scope is not automatically safer. It works when the outcome can be described precisely in advance; it fights you when the main job is discovery. Use this as a rough guide:

Your situation	Better fit	Why
One clear user journey, known integrations, designs largely settled	Fixed scope	The outcome is testable up front, so a fixed boundary protects both sides.
Problem understood, solution still being explored with users	Time and materials	You want to change direction weekly without renegotiating a contract.
Your own engineering lead will direct the day-to-day work	Time and materials or staff augmentation	You are buying capacity, and you own the prioritisation.
New partner, real but bounded outcome, trust not yet established	A short fixed-scope pilot first	You test delivery on real work before choosing a longer model.

Many teams combine the two: a fixed-scope first release, then time and materials or a sequence of fixed slices once the product is in users' hands. If you are still deciding who should direct the engineering, our comparison of staff augmentation vs project outsourcing walks through that choice by stage.

Start from one core user journey, not a feature list

The most useful scoping question is: what is the one thing a real user must be able to do, end to end, for this MVP to be worth releasing? Write it as a short narrative. For example, for a B2B operations tool: "An operations manager signs in, uploads a CSV of orders, sees rows with errors flagged, corrects them in the browser and exports a clean file."

Every candidate feature is then judged against that journey. Sign-in, upload, validation, inline editing and export are in. Team invitations, saved templates, a reporting dashboard and SSO are valuable, but they are not required for the journey, so they wait. This turns arguments about preferences into a single question: does this step serve the journey?

The same logic applies across lanes. A mobile MVP should be a release slice: one core job working on real devices, distributed to testers through TestFlight or Google Play internal testing, with a public store launch planned as a separate step. Our mobile app development work is scoped that way. If the MVP includes an AI feature, keep it assistive, with a person approving outputs before they take effect, and scope it with the same discipline we describe in how to scope an AI pilot.

Write in scope, out of scope and assumptions explicitly

A good MVP statement of work has three lists, and the second and third matter as much as the first.

In scope

List each journey step and what it includes, plus the non-functional basics: supported browsers or devices, the sign-in method, the environments that will exist (for example staging and production), and any security or accessibility requirements that apply to this release.

Out of scope

Name the things people tend to assume are included: an admin panel, more than two user roles, payments, email or push notifications, localisation, SSO, data migration from an old system, public app store submission, and ongoing support after handover. Writing "not in this release" next to each one prevents most acceptance-day surprises.

Assumptions and dependencies

Record what the delivery team is relying on: API access and sandbox credentials by a given date, whether designs are supplied or included, who provides copy and test data, how quickly your product owner will answer questions, and which third-party accounts will be created in your company's name. When an assumption breaks, the conversation is about the assumption, not about blame.

What actually drives MVP cost and timeline

Rather than comparing quotes in isolation, understand the factors that move effort up or down. Most of them are scoping decisions you control:

User roles and permissions. Each additional role multiplies screens, rules and test cases.
Integrations. Every third-party API brings its own documentation quality, sandbox limits and failure modes. Unknown APIs deserve a short technical spike before the estimate is fixed.
Platforms. Web only, web plus one mobile platform, or web plus iOS and Android are very different builds.
Design maturity. Finished, tested designs reduce rework; "we'll figure out the UX as we go" belongs in time and materials.
Data migration and quality. Importing messy legacy data is often its own project.
Compliance and security requirements that change architecture, hosting or audit logging.
Decision speed on your side. Slow answers and late feedback stretch timelines as much as any technical problem.

A partner who gives a firm figure without asking about these is either pricing the risk in or not seeing it.

Acceptance criteria both sides can test

Acceptance criteria turn "done" from an opinion into a check. Write them before any code, tied to journey steps. A simple format works:

Given a signed-in operations manager, when they upload a CSV with missing order IDs, then those rows are highlighted with a reason, and the export button stays disabled until they are fixed or removed.

Also agree who accepts each item, how many business days they have to review it, what happens if they do not respond, and the difference between a defect (the build does not meet a written criterion) and a change (a new or different criterion). That last definition removes a lot of friction.

Change control that stays flexible without blowing up the scope

New ideas will appear, especially once you see working software. That is healthy. The goal is to absorb them without destroying the date:

Park first. New ideas go into a visible "next release" backlog by default.
Swap, don't stack. If something must come in now, something of similar size comes out, agreed in writing by your named product owner.
Price the change. Anything that cannot be swapped gets a short change note stating its effect on effort and date before work starts.
Review weekly. A short scope check during the weekly walkthrough of work in progress keeps drift visible while it is still small.

From a scoped MVP to the next release

A fixed-scope MVP should end with a handover, not a cliff. Your company should already own the repositories, cloud accounts and credentials. You should receive setup notes, deployment steps and a list of known issues. Then use real usage to reprioritise the parked backlog and decide the next model: another fixed slice, time and materials, or bringing the work in-house.

How Axentis scopes a fixed-scope MVP

Our Launch Pilot follows the structure in this guide: private scoping around one outcome, written in-scope and out-of-scope lists, acceptance criteria agreed before build, client-owned repositories from day one and a clear decision at the end. Delivery runs as a Product Build Sprint with short cycles and regular walkthroughs of working software, across custom software, mobile release slices, assistive AI and DevOps. For the wider reasoning behind starting small, read our guide to paid pilot projects.

FAQ

What is a fixed scope MVP?

It is a first product release with a written boundary: a defined user journey, explicit in-scope and out-of-scope items, documented assumptions and acceptance criteria. Changes go through an agreed process instead of being added informally.

Is fixed price or time and materials better for an MVP?

Fixed scope suits a clearly defined journey with known integrations. Time and materials suits exploratory work where you expect to change direction often. Many teams use a fixed-scope first release and switch models once the product is in users' hands.

How can I judge MVP cost before I get a quote?

Look at the drivers: number of user roles, integrations, platforms, design maturity, data migration, compliance needs and how quickly your team can make decisions. Reducing any of these in the first release usually reduces effort and risk.

What should happen when a new idea comes up mid-build?

Park it in the next-release backlog by default. If it must be included now, swap out work of similar size, or agree a written change note covering the effect on effort and date before anyone starts on it.

Ready to scope your MVP?

If you have a core user journey in mind and want it scoped with clear boundaries before you commit, discuss a Launch Pilot with Axentis. We will review your brief privately, help you separate the first release from the backlog and agree acceptance criteria before any build starts. Prefer to start with a conversation? Talk to an expert.

If you are planning a first engagement, see how a scoped Launch Pilot from Axentis works, or read more product and engineering notes on the Axentis blog.

How to Evaluate an India Software Development Partner: A CTO's Due-Diligence Checklist

Kapil Singhal — Wed, 07 Oct 2026 06:35:53 +0000

Originally published at https://axentis.tech/evaluate-india-software-development-partner/.

Choosing an India software development partner looks simple until delivery starts. Proposals read alike, and sales calls rarely show how ownership, communication and cadence will feel six weeks in. If you are a CTO, founder or VP of Engineering in the US, UK, Canada or Australia deciding how to choose an offshore software development company, use one due-diligence scorecard on every shortlist candidate — including us.

This checklist covers outcome definition, company and contract checks, team continuity, delivery cadence, IP and security, references, red flags, and why a pilot-first engagement beats a long commitment made on slides.

Start with the outcome, not the vendor

Most evaluation processes start with vendor outreach. Flip that. Before you talk to anyone, write down:

The outcome. What should exist when the first engagement ends? A feature, an integration, a mobile MVP release slice, an assistive AI workflow with human approval, or a DevOps improvement?
The owner on your side. Who will answer questions, accept work and make trade-off calls? Without a named product owner, even a strong partner will stall.
Success criteria. How will you know the work is done? Prefer testable statements over vague quality language.
Constraints. Stack preferences, compliance needs, time-zone overlap windows and hard dates.

That brief becomes the filter. Vendors who cannot respond to a clear outcome with a clear scope are not ready for a serious evaluation. If you are still choosing between engagement models, read our guide on staff augmentation vs project outsourcing before you shortlist.

Company checks: entity, contract, IP and data handling

Ask for paperwork early. You are buying a commercial relationship, not a portfolio of slides.

Legal entity. Confirm the registered company name, jurisdiction and who signs the master agreement. Match invoice details to the contracting entity.
IP assignment. The contract should assign work product and related IP to you on payment (or as otherwise agreed in writing). Resist any setup where the partner retains exclusive ownership of code written for your product.
Subcontracting. Ask whether work can be subcontracted, and whether you get written notice and approval rights if it is.
Data handling. How will they access your systems and data? Where do environments live? What happens to copies of data at the end of the engagement?
Confidentiality and security baselines. NDAs, access logging, MFA on shared tools, and a clear rule that secrets never live in source code.

If a vendor postpones these topics until “after we kick off,” treat that as a signal, not a scheduling quirk.

Team checks: who actually writes the code

Sales teams and delivery teams are not the same people. Your due diligence should find the people who will touch your product.

Named roles. Ask for the roles on the proposed team (tech lead, engineers, QA, designer if needed) and how many hours of overlap they can commit to your time zone.
Continuity plan. What happens if someone leaves mid-engagement? How is knowledge documented, and how quickly is a replacement briefed?
Same people after the pilot. If you start with a scoped pilot, confirm that the pilot team is the team you would scale with, not a temporary “best foot forward” cast.
Working style. Prefer written updates, clear questions and demos of work in progress your product owner can follow — not résumé claims about fluency.

For US, UK, Canadian and Australian teams working with India, agree the overlap window in writing. Morning IST often suits Australia; late afternoon and evening IST often cover UK and US East Coast mornings. Exact hours matter less than showing up for them.

Delivery checks: estimation, acceptance criteria and cadence

Delivery due diligence is about how work becomes visible and how “done” is defined.

Estimation method. Ask how they break work down, what assumptions they surface, and how they handle uncertainty. Vague ranges with no assumptions are a warning.
Acceptance criteria before code. Insist on written, testable criteria and an explicit out-of-scope list. This is the same discipline we describe for a paid pilot project.
Cadence. Agree a weekly rhythm: planning, written progress notes, a demo of work in progress, and a short risk list. You should not need to chase status.
Visibility. You should see the task board, repositories you control, and builds as they happen — not only a polished end-of-sprint show.
Change control. New ideas go to a backlog or swap against something else. Unlimited “while you’re in there” work destroys both schedule and trust.

Match the delivery shape to the outcome type. A custom software feature, a mobile MVP release slice, an assistive AI/ML workflow with human approval, or a DevOps and SRE readiness improvement each needs different acceptance tests — but the same transparency rules apply.

Ownership checks: repositories, clouds and credentials from day one

Vendor lock-in rarely starts with a hostile clause. It starts with code sitting in accounts you do not control.

Client-owned repositories from day one, with your organisation as the owner and the partner as collaborators.
Cloud and hosting accounts in your name, or transferable with a documented process you have rehearsed.
Credentials and secrets stored in your vault or account, rotated on handover, and never shared in chat.
Documentation that travels. Architecture notes, setup steps, runbooks and decision logs short enough that a new engineer on your side can continue the work.

A partner who is confident about handover will welcome this setup. A partner who resists it is telling you something important about the relationship they want.

Security and references without theatre

Security due diligence does not require a multi-day audit for a first engagement, but it does require basics you can verify:

Who has access to production and staging, and how that access is revoked.
Whether secrets are kept out of repositories and CI logs.
How dependency updates and vulnerability triage are handled during the engagement.
What happens to your data copies when the engagement ends.

On references, ask for buyers who ran a comparable engagement. Did the people on the call match the people who delivered? How did they handle bad news? Was ownership clean at the end? Treat vague praise as soft evidence; treat specific, mixed feedback as useful. Do not treat public code portfolios as proof of delivery quality — process and ownership under your acceptance criteria matter more.

Red flags that should stop or slow a deal

Walk carefully — or walk away — if you see several of these:

Refusal to put IP assignment, ownership of repositories or data-handling terms in writing before kickoff.
A team that will not name who does the work, or that swaps people without notice.
No willingness to write acceptance criteria or an out-of-scope list.
Status only available in sales meetings, with no access to work in progress.
Pressure for a long exclusive commitment before any shared delivery experience.
Vague claims about AI acting without human approval. Prefer assistive designs where people review and approve external actions.
Time-zone overlap promised in the pitch and missing in the first two weeks.

One missed item can be fixed. A pattern of evasion usually cannot.

Test the relationship with a pilot-first engagement

The highest-signal due-diligence step is simple: run a small, paid, scoped engagement before a long contract. A pilot lets you judge communication, estimation honesty, engineering hygiene and handover on real work — not on a pitch.

At Axentis, that structure is Launch Pilot: private scoping, written acceptance criteria, client-owned repositories from day one, agreed overlap for US, UK, Canadian and Australian teams, and a clean decision at the end (scale, adjust or stop). For AI work, use the same discipline as how to scope an AI pilot: one workflow, a baseline, human approval and a go / extend / stop gate. Apply this checklist to Axentis the same way you apply it to anyone else.

FAQ

What should I ask an offshore software development company first?

Start with outcome, ownership and process: What exactly will be delivered, who owns the repositories and IP, how will acceptance criteria be written, and what overlap hours will the delivery team keep with your time zone?

How long should due diligence take before signing?

Long enough to complete company, team, delivery and ownership checks, plus at least one reference conversation. Many teams then run a short paid pilot as the final filter rather than stretching paper diligence indefinitely.

Is a paid pilot better than a long fixed contract for a first engagement?

Usually yes, when you have not worked together before. A pilot bounds cost and risk while testing real collaboration. A longer contract makes more sense after you have seen delivery, not before.

What if the partner is in India and my team is in the US, UK, Canada or Australia?

Agree overlap hours in writing, lean on async written updates and recorded walkthroughs for everything that does not need a live call, and judge the partner on whether blockers get raised early rather than overnight silence.

Ready to run this checklist with Axentis?

If you are shortlisting an India engineering partner and want a bounded first outcome rather than a leap of faith, talk to an expert. We will walk through your brief against this same checklist and, if there is a fit, scope a Launch Pilot around your acceptance criteria and timeline.

If you are planning a first engagement, see how a scoped Launch Pilot from Axentis works, or read more product and engineering notes on the Axentis blog.