DEV Community: sagar jain

The Second Version Is Always Smaller

sagar jain — Thu, 06 Aug 2026 08:00:39 +0000

Every time I've rebuilt a system I understood well, the second version came out smaller than the first. Less code, fewer files, fewer special cases. This surprised me the first few times. Now I expect it, and when a rewrite comes out bigger, I treat it as a warning sign.

The clearest case I remember was a billing module. The first version ran around 2,000 lines, full of branches for edge cases we thought we'd hit. The rebuild, done two years later by someone who'd supported the original in production, came in near 700 lines and handled more real scenarios. Nothing clever happened. We just finally knew which branches were fiction.

The first version is mostly guessing

The first time you build something, you don't fully know what it needs to do. You know what you were told, and you know what you can imagine, but you don't know what's real yet.

So you hedge. You add a config flag because someone might want to turn this off. You add an abstraction because there might be a second case someday. You handle an input that can't actually happen, because you aren't certain it can't. Every one of these is a reasonable bet made under uncertainty.

A year later, most of those bets have resolved. The config flag was never flipped. The second case never came. The impossible input stayed impossible. All that code is still there, still maintained, still confusing the next person, and all of it is compensation for uncertainty that no longer exists.

Understanding is what shrinks it

The second version is smaller because you're building with answers instead of guesses. You know which cases are real. You know which flags mattered. You know the actual shape of the data because you watched it move through production for a year.

This is why I'm careful about who should rewrite something. The person who understands the current system deeply will make it smaller. The person who just finds it ugly will make it bigger, because they'll re-add every hedge from scratch under the same uncertainty the first author had.

There's a trap worth naming. Ugliness and complexity look the same from the outside. A senior engineer learns to ask whether an ugly piece of code is bad, or ugly because the problem is genuinely messy and the code is being honest about it. Those two need opposite treatments.

Before anyone rebuilds a component at Shanti Infosoft, the first question is whether we understand why the current one is shaped the way it is. If we can't explain the weird parts, we aren't ready to replace them. The weird parts are usually load-bearing.

Smaller is the evidence, not the goal

I want to be careful here. Small code isn't automatically good code. You can compress something until nobody can read it, and that's worse than the verbose version. Shrinking isn't the target.

Smaller is the symptom of understanding. When the second version comes out dramatically simpler, it usually means we finally understood the problem. When it comes out bigger and more clever, it usually means we didn't, and we hid that from ourselves behind abstraction.

So I don't chase line count. I chase understanding, and I read the line count as a signal for whether we got there.

That's really a governance point, and we made the fuller argument in why writing code was never the bottleneck.

When you last rebuilt something, did it come out smaller, and if it didn't, are you sure you understood the original?

The AI Feature Is Cheap to Build and Expensive to Run

sagar jain — Tue, 04 Aug 2026 09:00:18 +0000

The quote everyone remembers is the build cost. The number that decides whether an AI feature survives is the monthly one, and it tends to show up in month two, right when the trial credits run dry and real traffic arrives.

I budget AI features the way I'd budget a delivery van. Buying it happens once. Fuel, insurance, and the driver run forever. Here's where the fuel actually hides.

Where the money goes

Tokens, including the ones you forget. Everyone counts the user's question. Fewer people count the system prompt, the retrieved context, the few-shot examples, and the model's own output, all billed on every call. A feature carrying a 3,000-token context that looked tiny in testing can run 10x the estimate once every request drags that prompt along.

Retries and retrieval. A retry on failure doubles the cost of that call. A RAG feature also pays to embed every document, store the vectors, and run a similarity search per query. The model bill is one line on a longer receipt.

The machinery around the model. Vector database hosting. Logging and observability, which for AI features is not optional. Egress. The cache you'll add later to stop paying twice for the same answer.

Humans in the loop. If a person reviews flagged outputs, that review time is a running cost of the feature and belongs in the budget, even though no vendor ever invoices you for it.

How we actually budget it

We estimate a cost per action before a line of the feature exists. Average tokens in, average tokens out, times the model's price, times expected volume. It's back-of-envelope, and it usually lands close, because the inputs are knowable.

Then we pick the cheapest model that passes evaluation, not the highest one on the leaderboard. A smaller model that's good enough on your real task can cut the bill 5 to 10x. We send the easy 80% of requests to the cheap model and escalate only the hard ones. Caching repeat queries shaves off another slice.

The last step is a hard spend cap wired in before launch. Per user, per day, per feature. A runaway loop or a scraper pounding your endpoint should trip a limit and page a human, not keep billing until the card declines.

Give the client the real number

When we scope AI work, the client gets both numbers. Build once, and run monthly at your expected volume, with the assumptions written down beside them. A client who signed off on a $600-a-month running cost stays calm when the bill reads $600. A client shown only the build price feels ambushed, and they're right to.

That conversation is unglamorous, and it's the one that stops a project from souring six weeks in. The team at Shanti Infosoft treats the running-cost estimate as part of the quote, not a thing we discover together later, and you can see how we scope it at https://shantiinfosoft.com.

We break the running-cost math down further in the automation trade-off nobody quotes you on.

What did an AI feature actually cost you to run each month, and how far off was the first estimate?

The AI Feature Is Cheap to Build and Expensive to Run

sagar jain — Tue, 04 Aug 2026 08:01:17 +0000

I budget AI features the way I'd budget a delivery van. Buying it happens once. Fuel, insurance, and the driver run forever. Here's where the fuel actually hides.

Where the money goes

The machinery around the model. Vector database hosting. Logging and observability, which for AI features is not optional. Egress. The cache you'll add later to stop paying twice for the same answer.

Humans in the loop. If a person reviews flagged outputs, that review time is a running cost of the feature and belongs in the budget, even though no vendor ever invoices you for it.

How we actually budget it

Give the client the real number

We break the running-cost math down further in the automation trade-off nobody quotes you on.

What did an AI feature actually cost you to run each month, and how far off was the first estimate?

A Flaky Test Is More Expensive Than a Failing One

sagar jain — Sun, 02 Aug 2026 08:00:28 +0000

A failing test tells you something is broken. You fix it, the bar goes green, everyone moves on. That test did its job.

A flaky test is different. It passes, then it fails, then it passes again, and nothing in your code changed. It's the test that cost my team more hours last year than any real bug we shipped.

Here's what makes it worse than a normal bug. A normal bug is visible. It fails, you see red, you fix it. A flaky test hides in plain sight, because half the time it agrees with you. It's the coworker who's right often enough that you stop questioning them, and wrong exactly when it matters.

What flaky tests train people to do

The real damage from a flaky test isn't the failed run. It's what it teaches your engineers to do.

The first time a test fails for no reason, someone re-runs the pipeline. It goes green. Lesson learned: red doesn't always mean broken. The second time, they re-run it without even reading what failed. By the tenth time, the whole team has quietly agreed that a red build is a suggestion, not a fact.

That's the expensive part. You didn't just lose ten minutes per re-run. You lost the thing the suite was supposed to give you: the ability to trust green. Once nobody trusts the suite, a real failure slides through, because the muscle memory is to hit retry and move on.

Where flakiness usually hides

Most flaky tests I've dug into come from a small set of causes. A test that depends on timing and assumes an async operation finishes in 100ms. A test that shares state with another test and only fails when they run in a certain order. A test that hits a real network or a real clock instead of a controlled one.

None of these are exotic. Every one is the test author borrowing reliability from something they don't control. The fix is almost always to stop borrowing: freeze the clock, isolate the state, mock the boundary, wait on a condition instead of a fixed duration.

The worst one I chased took a week. A test passed alone and failed in CI, only on Tuesdays. A different test was writing a date-based cache key and never cleaning it up, and the collision only happened on certain weekdays. The bug was never in the code under test. It lived in the test next door.

At Shanti Infosoft we treat a flaky test as a real bug with its own ticket, not a nuisance to retry past. If it can lie to us, it's broken, even when it's green.

Quarantine, then fix or delete

When we find one we can't fix in the moment, we don't leave it in the main suite poisoning trust. We move it to a quarantine group that runs separately and doesn't block the build. Then it gets a deadline.

Here's the part people resist. If a quarantined test sits unfixed past its deadline, we delete it. A test that never runs and never gets fixed isn't protecting anything. It's guilt in the repo with a green checkmark. A smaller suite you trust completely beats a large suite you argue with.

The goal was never a big number of tests. The goal was to look at a green checkmark and believe it.

It's the same instinct behind the QA layer we add when AI writes most of the code: a green check you can't trust is worse than no check at all.

When your build goes red, does your team read the failure, or reach for retry?

Production-Ready AI: The Checklist We Run Before Launch

sagar jain — Fri, 31 Jul 2026 09:20:20 +0000

A model that answers correctly in a Jupyter notebook has cleared maybe 20% of the work. I've watched teams treat a good demo as the finish line, ours included in the early days, then spend the next two months finding everything the demo quietly skipped. Empty inputs. A user pasting 40 pages into a box built for one sentence. The model returning valid-looking JSON that's missing a field the code assumes is always there.

'Production-ready' turned vague the moment every framework started shipping a chatbot template. Here's the checklist we actually run before an AI feature gets near real users.

The checklist we actually use

It fails on purpose, safely. Every model call has a timeout, a retry with backoff, and a defined behavior when the provider returns a 500 or a rate limit. If OpenAI or Anthropic has a bad ten minutes, the feature degrades to a polite message instead of a stack trace.

Outputs get validated, never trusted. We schema-check every response before it touches the database or the screen. A model asked for a category that returns something off-list gets caught, not stored.

There's a logged trail. Prompt version, input, output, latency, tokens, and cost, per call. When a user says it gave them something strange on Tuesday, we can actually find Tuesday.

Cost has a ceiling. A per-user and per-day cap that trips before the invoice does. I've seen one retry loop turn a $40-a-day feature into a $900 surprise by morning.

Someone can switch it off. A flag that disables the AI path and falls back to the old flow with no redeploy. If the model starts misbehaving, the fix should take thirty seconds.

The part nobody demos

Evaluation is where 'ready' is won or lost. Before launch we build a set of 50 to 200 real inputs with known-good answers, and every prompt change runs against it. We do this because without it, 'I improved the prompt' is just a feeling. A tweak that helps one case often breaks three others, and skipping the eval means your users are the ones who find out.

We also decide, out loud, what the model may never do alone. Send money, delete records, email a customer. Those stay behind a human click. A confident wrong answer is the default failure mode of these systems, so the blast radius has to be small by design.

Ready means you can walk away

The AI features I trust in production are the ones I can stop watching. They log everything, cost a predictable amount, fall into a safe fallback, and keep a human on the actions that matter. None of that shows up in a demo, which is why demos oversell.

At Shanti Infosoft most of our launch delays come from this list, not from the model. The model was usually fine in week one. Making it safe to leave running unattended is the other six weeks. We write more about how we ship AI at https://shantiinfosoft.com.

The demo-to-production gap is the whole story in why a working AI demo is the problem, not the finish line.

What's the one item on this list your last AI launch skipped, and did it come back to bite you?

We Chose Boring Technology on Purpose

sagar jain — Fri, 31 Jul 2026 06:16:17 +0000

There's a specific kind of excitement on an engineering team when someone suggests a new database. The demos look great. The benchmarks are stunning. Someone has a blog post about how it scaled to a billion writes. For about a week, it feels like the answer to every problem you have.

I've learned to be suspicious of that feeling.

Most of the systems I've built that are still running, still boring, still not paging anyone at 3am, sit on technology that was already old when I picked it. Postgres. A plain job queue. A monolith that does one thing. None of it is interesting. All of it works.

The cost nobody prices in

Every new tool comes with a bill you don't see at selection time. Not the license. The knowledge.

When you pick Postgres, you inherit twenty years of Stack Overflow answers, battle-tested backup tools, and the fact that every engineer you hire has probably used it. When you pick the exciting new database, you inherit its documentation, its Discord channel, and whatever three people on earth have hit your exact edge case.

The first time that new tool fails in production, you aren't debugging a problem. You're debugging a problem nobody has written about yet. That's a lonely place to be at 2am with a customer waiting.

I've lived that night. A queue library we picked for its throughput numbers started dropping jobs under a burst pattern we hadn't tested. There was no Stack Overflow answer, no known fix, just us reading library source at midnight while orders piled up. The boring queue we replaced it with was slower on paper and has never once done that.

Boring means predictable, not bad

People hear 'boring technology' and assume I'm arguing against learning or against quality. I'm not. Boring means the failure modes are known. When something breaks, the path from symptom to cause is short, because someone has walked it before.

I want my interesting problems to be the actual product, the thing customers pay for. I don't want my interesting problems to be why our message broker loses data under one specific load. That's not the problem I'm trying to be good at.

At Shanti Infosoft we keep a rough rule: you get a small budget of novelty per project. Spend it on the part that's actually your differentiator, and buy everything else off the shelf, old and proven.

When new is the right call

This isn't a blanket no. Sometimes the boring option genuinely can't do the job, and the new tool solves a problem you have today, in production, not one you're imagining for a scale you haven't reached.

The test I use is simple. I have to be able to name the specific thing the old technology can't do for us right now. If that's a real, measurable limit we're hitting, we evaluate the new thing seriously. If it's 'it would be cleaner' or 'it's more modern,' that isn't a reason. That's a feeling.

Choosing boring is a discipline, not a limitation. It's a bet that your time is better spent on the problem only you can solve than on rediscovering why mature tools got mature.

The best compliment I can give infrastructure is that I forgot it was there. It just ran, for a year. Boring technology is how you earn that.

For the flip side of this, we wrote about how the build-vs-buy line keeps moving: most 'let's build our own' calls are novelty wearing a business case.

When you last reached for a shiny tool, was it solving a problem you actually had, or one you hoped to have?

The Questions Clients Ask Us Most About AI Projects, Answered

sagar jain — Tue, 14 Jul 2026 07:00:14 +0000

Over many AI projects, the same questions come up again and again in early conversations - and they are good questions. Here are the ones clients ask us most often at Shanti Infosoft, answered as plainly as we can. If you are weighing up an AI project, this is roughly the conversation we would have on a first call.

How long will it take?

It depends on scope, but the useful answer is that we work in small, visible steps rather than one long silence. A proof-of-concept to test an idea is usually about two weeks. A focused first version of a real feature is often a matter of weeks, not months. Big-bang projects that disappear for half a year are exactly what we try to avoid, because they carry the most risk.

How much does it cost?

There is no honest single number, but there is an honest method. We break estimates down to the feature level so you can see where the cost sits and make trade-offs - shipping the core first and moving ambitious extras to a later phase. The biggest cost driver is usually not the AI itself but the surrounding work: integrations, data preparation, and the interface your team will actually use.

Who owns the code and the data?

You do. We build so that what you pay for is yours to keep and run, with or without us. Your data stays your data. We are happy to put this in writing, and we would encourage you to ask any vendor the same question before you sign anything.

Is my data safe?

It should be designed in from the start, not bolted on later. If your project involves personal, financial, or regulated data, tell us early and it shapes how we store and handle everything. We keep access scoped to what the solution actually needs, and we are transparent about where data goes.

How accurate will the AI be?

Honestly, it varies by task - and any vendor who promises perfection is overselling. What we can do is measure it. A proof-of-concept gives you a real accuracy number on your own data before you commit. For most business tasks, the right design is not "fully automated" but "the AI drafts, a person approves," which captures most of the time savings while keeping mistakes in check.

What happens when it gets something wrong?

It will sometimes get things wrong, so we design for that. That means a human-review step where it matters, clear handling when the AI is unsure, and logging so you can see what happened. A good AI system is judged not only by how often it is right, but by how gracefully it handles being wrong.

Do we need a huge dataset to start?

Usually not. Modern AI can do a lot with a modest, representative sample - including your messy, real-world cases. We would rather start with a realistic slice of your actual data than wait for some perfect, complete dataset that never arrives.

What happens after it launches?

Software is never truly finished, and AI features benefit from ongoing tuning as real usage reveals new cases. We are clear up front about what maintenance looks like and what it costs, so support is a planned part of the relationship rather than an afterthought. Models improve over time, your business changes, and the data the agent sees evolves - a small, steady amount of attention after launch is what keeps a good feature good, and we would rather agree that plan with you on day one than surprise you with it later.

Still have a question?

These are the common ones, but yours might be specific to your business - and those are the most useful to talk through. Send us your question and we will give you a straight answer, no obligation.

About Shanti Infosoft
Shanti Infosoft is a CMMI Level 5 AI development company that has delivered 700+ projects across 16+ industries. We help teams move from AI ideas to dependable, production-grade software. Learn more at https://www.shantiinfosoft.com or explore our AI development services (https://www.shantiinfosoft.com/services/ai-development-company/).

Related reading: 10 Questions to Ask an AI Development Company Before You Hire (https://www.shantiinfosoft.com/blog/10-questions-to-ask-an-ai-development-company/) - AI App Development Cost: UK & US 2026 Price Guide (https://www.shantiinfosoft.com/blog/ai-app-development-cost-2026/)

Written by Team Shanti Infosoft, the AI development team at Shanti Infosoft (https://in.linkedin.com/company/shantiinfosoft).

How We Keep AI Projects On Time and On Budget: Our Delivery Process

sagar jain — Mon, 13 Jul 2026 07:00:18 +0000

Software projects rarely go over time and budget because of one big disaster. They drift - a little vagueness here, a missed assumption there, a change nobody priced - until the original plan no longer resembles reality. Keeping an AI project on track is mostly about a handful of unglamorous delivery habits. Here are the ones we rely on at Shanti Infosoft.

We start from a clear, costed scope

On-time delivery begins before any code is written. We start every project from a written scope that says what we are building, broken down to the feature level with the assumptions spelled out. When everyone agrees on the plan in advance, there is far less room for the "but I thought it would also do X" conversations that quietly blow up timelines.

We work in short cycles, not long silences

We build in short, focused cycles that each produce something you can see. This keeps the project honest: instead of disappearing for months and hoping the final reveal matches what you imagined, we surface progress continuously. Small cycles also mean problems show up early, while they are still cheap to fix.

We demo working software regularly

A demo is the most honest status report there is. Rather than a slide that says "80% complete," we show you the actual feature working on real data. Regular demos let you course-correct while it is still easy - a tweak in week two is trivial; the same change after launch is expensive. Seeing the real thing keeps expectations and reality aligned.

We handle change openly

Requirements change - that is normal, and a good process expects it rather than resisting it. What matters is handling change in the open: when something new comes up, we are clear about what it costs in time and money, and you decide whether it is worth it or whether something else moves to make room. Change is fine; unpriced, invisible change is what wrecks budgets.

We keep one clear line of communication

Confusion is expensive. We keep a single, clear point of contact and a steady rhythm of updates, so you always know where things stand and who to ask. You should never have to chase us to find out how your project is going - and we should never have to guess what you need. Most overruns trace back to a communication gap, so we close that gap on purpose.

We protect the core scope

The fastest way to miss a deadline is to let the "wouldn't it be nice" ideas creep into version one. We are disciplined about shipping the core first and parking good-but-non-essential ideas for a later phase. That is not us saying no to your ideas - it is us making sure the thing you actually need ships on time, with the extras following in a planned second round.

We build in the safety net as we go

Testing and quality checks are not a phase we tack on at the end and then run out of time for. They are part of each cycle. Catching issues as we build means the finish line is a real finish line - not the start of a long, unbudgeted bug hunt that pushes the launch back.

The result

None of this is a secret formula. It is consistency: a clear plan, short cycles, honest demos, open handling of change, and steady communication. Done together, they are what let us deliver AI projects that arrive when we said they would, for what we said they would cost.

If predictability matters to you as much as the end result - and for most businesses it does - that is exactly how we work. Tell us about your project and we will show you what an on-time, on-budget plan looks like.

About Shanti Infosoft
Shanti Infosoft is a CMMI Level 5 AI development company that has delivered 700+ projects across 16+ industries. We help teams move from AI ideas to dependable, production-grade software. Learn more at https://www.shantiinfosoft.com or explore our custom software development services (https://www.shantiinfosoft.com/services/software-development-service/).

Related reading: The 5 Things AI Projects That Don't Get Cancelled Do Differently (https://www.shantiinfosoft.com/blog/5-things-ai-projects-that-dont-get-cancelled-do/) - AI App Development Cost: UK & US 2026 Price Guide (https://www.shantiinfosoft.com/blog/ai-app-development-cost-2026/)

Written by Team Shanti Infosoft, the AI development team at Shanti Infosoft (https://in.linkedin.com/company/shantiinfosoft).

From Pilot to Production: Rolling Out an AI Agent Smoothly

sagar jain — Sun, 12 Jul 2026 07:00:05 +0000

There is a wide gap between an AI agent that works in a pilot and one your team relies on every day. Crossing it is where a lot of promising projects stumble - not because the technology fails, but because the rollout is rushed, opaque, or sprung on people who were never brought along. Here is how we move from pilot to production at Shanti Infosoft without turning your operation upside down.

Start where the stakes are low

We do not switch an agent on across the whole business at once. We pick a contained starting point - one team, one workflow, or a slice of the volume - where a mistake is easy to catch and easy to recover from. Real production use teaches you things no pilot can, and it is far better to learn them on 10% of the workload than on all of it.

Keep a human in the loop before you take them out

For the first stretch in production, the agent usually drafts and a person approves. This does two things: it keeps mistakes from reaching customers while everyone builds trust, and every approval or correction becomes evidence of how well the agent is really doing. Once the numbers justify it, you can widen its autonomy deliberately - rather than hoping it is ready.

Bring the team along, not around

The people whose work the agent touches need to understand what it does, what it does not do, and how to step in. We involve them early, show them the agent on real cases, and make it easy to give feedback. An agent that is imposed on a team gets quietly worked around; one that is introduced as a tool that removes drudgery gets adopted. The difference is almost entirely in how the rollout is handled.

Watch it closely in the early days

When an agent first goes live, we keep a close eye on it: tracking how often it succeeds, where it struggles, and what real inputs look like compared to the pilot. Real-world data is always messier than test data, and the first weeks surface cases nobody anticipated. Watching closely means we catch and fix those quickly, before they become a pattern.

Make sure there is always a way back

Good production rollout includes a plan for when something goes wrong: a clear way to pause the agent, fall back to the old process, and fix the issue without drama. Knowing there is a safe fallback is what lets a team adopt something new with confidence instead of anxiety. The fallback is not a sign of doubt - it is what makes moving forward responsible.

Scale once it has earned it

Only after the agent has proven itself on the contained slice do we widen it - more volume, more teams, more autonomy - one deliberate step at a time. Each expansion is a smaller risk than the last because the agent has already shown it can handle the real world. Scaling becomes a series of confident decisions rather than one nervous leap.

Treat launch as a beginning

Going live is a milestone, not the finish line. Usage reveals new cases, your business changes, and the agent should keep improving. We plan for that ongoing tuning from the start, so production is the point where the agent starts getting genuinely good - not the point where attention stops.

If you have an AI pilot that works and you are wondering how to roll it out safely, that transition is one of the most important parts of the whole project. Talk to our team about getting your agent into everyday use without the disruption.

Related reading: Your AI Demo Works. That's the Problem (https://www.shantiinfosoft.com/blog/ai-demo-works-thats-the-problem/) - 40% of AI-Agent Projects Will Be Dead by 2027. Which Side Are You On? (https://www.shantiinfosoft.com/blog/ai-agent-projects-dead-by-2027/)

Written by Team Shanti Infosoft, the AI development team at Shanti Infosoft (https://in.linkedin.com/company/shantiinfosoft).

How to Choose the Right AI Development Partner (Beyond the Sales Pitch)

sagar jain — Sat, 11 Jul 2026 07:00:55 +0000

Choosing who builds your AI project matters more than almost any technical decision you will make. The right partner turns a vague idea into working software and tells you the truth along the way. The wrong one ships a polished demo, then disappears when it meets real users. The hard part is that both look identical in a sales meeting.

Here is how we suggest looking past the pitch - the same things we would want a client to check about us.

Listen for honesty, not just enthusiasm

A good partner will sometimes tell you no. They will say a feature is not worth the cost, that your timeline is unrealistic, or that the data is not ready. That can feel less exciting than a vendor who says yes to everything - but a partner who never pushes back is a partner who will let you walk into expensive mistakes. Candour early is a sign of candour later.

Ask how they handle the unglamorous parts

Anyone can demo a happy path. The real question is what happens when the AI gets something wrong, when a deadline slips, or when requirements change mid-build. Ask how they handle errors, testing, and the human-review layer that catches mistakes before your customers do. Vendors who only talk about the exciting features and never the safety net are telling you what they neglect.

Check how they communicate, not just what they build

You will spend weeks or months working with this team. How they communicate is part of the product. Do they demo working software regularly, or do they go quiet for weeks and resurface with surprises? Do they explain trade-offs in plain language, or hide behind jargon? A partner who shows you progress often, in terms you understand, is one you can course-correct with.

Find out who actually owns the result

Be clear, before you sign anything, about who owns the code, the data, and the trained models when the project ends. A trustworthy partner builds so that you are never locked in - you should be able to take what you paid for and run it, with or without them. If ownership is vague or the answer is evasive, treat that as a warning.

Look for relevant judgement, not just a logo wall

Impressive client logos are nice, but what you really want is evidence of judgement on problems like yours. Ask how they decided what to build and what to leave out on a past project, and how they handled something that went wrong. The answer reveals far more than a list of names. You are hiring how they think, not who they have worked with.

Mind the red flags

A few signals are worth taking seriously: a quote with no breakdown, so you cannot see what you are paying for; promises of certainty about something that is inherently uncertain; reluctance to start with a small, low-risk first step; and pressure to commit to a large scope before anything has been proven. None of these are automatically disqualifying, but each one deserves a direct question.

Start small to test the relationship

The best way to evaluate a partner is to work with them on something small first - a proof-of-concept or a contained first phase. A short engagement tells you more about how a team actually delivers than any number of reference calls. If the small project goes well, scaling up is easy. If it does not, you have learned that cheaply.

At Shanti Infosoft we would rather earn a long relationship through a small, honest first project than win a big contract on a promise we are not sure we can keep. If you are evaluating partners for an AI build, talk to us - and hold us to every point above.

About Shanti Infosoft
Shanti Infosoft is a CMMI Level 5 AI development company that has delivered 700+ projects across 16+ industries. We help teams move from AI ideas to dependable, production-grade software. Learn more at https://www.shantiinfosoft.com or explore our AI consulting services (https://www.shantiinfosoft.com/services/ai-consulting/).

Related reading: 10 Questions to Ask an AI Development Company Before You Hire (https://www.shantiinfosoft.com/blog/10-questions-to-ask-an-ai-development-company/) - AI Development Outsourcing vs In-House (https://www.shantiinfosoft.com/blog/ai-development-outsourcing-vs-in-house/)

Written by Team Shanti Infosoft, the AI development team at Shanti Infosoft (https://in.linkedin.com/company/shantiinfosoft).

Before You Build: A Data and Access Readiness Checklist

sagar jain — Fri, 10 Jul 2026 07:00:44 +0000

The fastest AI projects we run have one thing in common: the client did a little homework before the build started. The slowest ones almost always stall in the same place - waiting on data that nobody could find, or access that nobody was authorised to grant. None of it is hard. It just needs to happen before, not during, development.

Here is the readiness checklist we walk through with clients at Shanti Infosoft before we write a line of code.

Know where your data actually lives

An AI feature is only as good as the data behind it. Before you build, locate the data the solution needs: which system holds it, what format it is in, and how far back it goes. "It is in the CRM somewhere" is not an answer that lets a project start. A clear inventory - even a rough one - saves days.

Gather a representative sample, including the messy cases

We do not need all your data to start, but we do need a sample that looks like reality. That means including the awkward records: the half-filled forms, the unusual tickets, the documents in odd formats. A model that only ever sees clean examples will fall over on the first real one. The messy cases are the most useful thing you can hand us.

Sort out access and permissions in advance

This is the single most common cause of delay. If the solution needs to read from your database, send email, or post into a tool, someone has to grant that access - and in many organisations that takes approvals. Identify who owns each system early and start those conversations before the build, not on day three when development is blocked.

Decide who owns the decision

Every project hits moments that need a yes or no: which option to take, what is good enough to ship, whether a trade-off is acceptable. Decide up front who that person is. Projects with one empowered decision-maker move quickly; projects where every choice goes to a committee crawl.

Be clear about sensitive data

If your data includes personal information, health records, financial details, or anything regulated, say so at the start. It shapes how we design, store, and handle everything - and it is far easier to build the right safeguards in from the beginning than to retrofit them later. There are no awkward surprises if the rules are on the table from day one.

Define what success looks like

Agree, in advance, how you will judge whether the finished feature is working. A target accuracy, a time saved, a reduction in manual steps - something concrete. Without it, "is this good enough" becomes an endless, subjective debate. With it, you have a clear finish line.

Line up the people who know the work

The best AI features are shaped by the people who do the job today. Identify the one or two team members who understand the workflow inside out and can spare a little time to answer questions and review early output. Their knowledge is worth more than any amount of guesswork.

The payoff

None of this is glamorous, but it is the difference between a project that starts moving in week one and one that spends a month waiting. Walk through this list before you engage anyone, and you will get more value from every hour of development that follows.

Working through this and not sure how your project measures up? Send us where you are and we will help you fill the gaps before the build begins.

About Shanti Infosoft
Shanti Infosoft is a CMMI Level 5 AI development company that has delivered 700+ projects across 16+ industries. We help teams move from AI ideas to dependable, production-grade software. Learn more at https://www.shantiinfosoft.com or explore our AI consulting services (https://www.shantiinfosoft.com/services/ai-consulting/).

Related reading: The 5 Things AI Projects That Don't Get Cancelled Do Differently (https://www.shantiinfosoft.com/blog/5-things-ai-projects-that-dont-get-cancelled-do/) - Custom AI Development: How ML Is Transforming Business Software (https://www.shantiinfosoft.com/blog/custom-ai-development/)

Written by Team Shanti Infosoft, the AI development team at Shanti Infosoft (https://in.linkedin.com/company/shantiinfosoft).

How We Scope an AI Project: From First Call to a Signed Plan

sagar jain — Wed, 08 Jul 2026 07:00:22 +0000

The riskiest moment in any software project is the gap between "we want to build something with AI" and "here is exactly what we are building, for how much, by when." Scoping is how you close that gap before money is on the line. Done well, it is the cheapest insurance you can buy. Here is how we do it at Shanti Infosoft.

The first call is about the problem, not the solution

Our first conversation is deliberately not about models or tech stacks. We want to understand the problem in plain language: what is slow, expensive, or error-prone today, who feels that pain, and what "better" would actually look like. If a client opens with a solution - "we need a chatbot" - we gently walk it back to the underlying job to be done. The best scope starts from the outcome, not the feature.

We separate the must-haves from the someday list

Every project has a wish list, and every wish list is too long for version one. We work with you to sort requirements into three buckets: what the first release must do to be useful, what can wait for a second phase, and what is genuinely out of scope. This single exercise prevents the slow scope creep that sinks most AI projects.

We map the data and the integrations early

AI lives or dies on data and access. So before we estimate anything, we ask the practical questions: where does the data live, what shape is it in, who owns it, and what systems will the solution need to read from or write to. A feature that sounds simple can become a month of work if it depends on an undocumented legacy system - and it is far cheaper to discover that during scoping than during delivery.

We write it down as a scope of work

Conversations get forgotten and misremembered. So we turn the agreed plan into a written scope of work: the modules to be built, what each one does, the user roles involved, the integrations, the assumptions we are making, and what is explicitly excluded. It is written to be readable by your business team and precise enough for our developers to build against. If a detail is fuzzy, we flag it as an open question rather than papering over it.

We estimate in features, not vague phases

A single number for a whole project hides too much. We break the estimate down to the feature level, so you can see where the effort - and the cost - actually sits. That transparency lets you make trade-offs: maybe one ambitious feature can move to phase two so the core ships sooner and cheaper. You are in control of the scope because you can see what each piece costs.

We agree on how we will work together

Finally, scoping sets the rhythm of delivery: how often we demo, who your point of contact is, how change requests are handled, and how decisions get made. Getting this clear up front avoids the awkward mid-project moments where nobody is sure who can approve what.

Why this matters

A good scope is not paperwork for its own sake. It is the document that keeps everyone honest - it protects you from surprise costs, and it protects us from building the wrong thing. When delivery starts, there are no nasty surprises because the hard conversations already happened on paper.

If you are weighing up an AI project and want a clear, costed plan before you commit, that is exactly what our scoping process delivers. Start a conversation with our team and we will help you turn a rough idea into a scope you can confidently approve.

About Shanti Infosoft
Shanti Infosoft is a CMMI Level 5 AI development company that has delivered 700+ projects across 16+ industries. We help teams move from AI ideas to dependable, production-grade software. Learn more at https://www.shantiinfosoft.com or explore our AI consulting services (https://www.shantiinfosoft.com/services/ai-consulting/).

Related reading: The 5 Things AI Projects That Don't Get Cancelled Do Differently (https://www.shantiinfosoft.com/blog/5-things-ai-projects-that-dont-get-cancelled-do/) - 10 Questions to Ask an AI Development Company Before You Hire (https://www.shantiinfosoft.com/blog/10-questions-to-ask-an-ai-development-company/)

Written by Team Shanti Infosoft, the AI development team at Shanti Infosoft (https://in.linkedin.com/company/shantiinfosoft).