A CTO of a $50mn+ company told me that his company had 12 ongoing AI pilots with different teams at different stages.

During the conversation, he admitted the success rates to be low with 8 projects failing, 2 underperforming. Only 2 showed meaningful results.

And this story is not unusual. As per MIT, 95% of AI initiatives are failing in organizations. Teams are starting their own experiments, each chasing different idea, with predictable results: scattered efforts, shallow investments, and almost non-scalable. The management eventually questions AI’s potential in delivering results.

The answer to making AI projects successful is not more pilots. It’s focus.

That’s why I use what I call a 2+2 rule:

• 2 long-term pilots aimed at organization wide impact (efficiency, cost, or EBITDA)

• 2 short-term pilots (2-3 months) focused on individual productivity

Anything more and results spread too thin. I don’t even start new pilot discussions until one of the four closes. This has enabled me to do far more successful projects.

At one of the companies, we picked two long-term problems as:

1. How do we grow 5x without growing the QC team linearly

2. How do we solve pricing for different teams

Both were transformational - tied directly to EBITDA and scale. At the same time, the short-term pilots were much narrower: improving developer productivity and boosting employee engagement.

By limiting to four, each pilot got resources, focus, and accountability. And instead of waiting to see if “one out of twelve” worked, all four moved forward with clear goals.

The companies succeeding with AI projects are the ones starting with high-impact problems and going deep before starting a new project.

In AI, Breadth is cheap. Depth is what compounds.

Know someone who’d value this? Forward it.

👥 Want to suggest an exec to feature? Hit reply or message me on LinkedIn.

You’re reading Model in Motion - where modern leaders make sense of AI, without the noise.

Subscribe now

This week, I want to talk about something that doesn’t get enough attention: how dependent your systems are on AI partners, and what happens when that dependency breaks.

At my last organization, we built a speech-to-text solution for our 5000 member+ call center that became the core platform for analytics and performance assessment.

We partnered with a provider whose core algorithm was fine-tuned on our data, while we developed our use cases on top.

One day, we were informed that the company was getting acquired and would end service in 30 days. During that month, they proposed to serve only 20% of our traffic.

The assessment showed replacement would take 6 months and a full rebuild.

And this isn’t rare. In AI, companies are frequently acquired or shutdown, partners change their pricing & services, or a better technology emerges. These create three categories of risk: ownership, commercial, and technology.

Recently, when Windsurf and ScaleAI were acquired by Google and Meta, clients faced the same.

Changing providers isn’t the problem. The real risk is an unswitchable system - a software so tightly coupled that replacement demands massive effort and sometimes a full rebuild.

Most tech leaders admit they’ve faced this more than once, yet their teams repeat the mistake. In AI, the cost of lock-in is even higher.

I use a principle called ‘Design for Exit’ whenever I design an AI solution with third party providers, even using OpenAI or Gemini or Claude’s APIs.

The key components of the framework are:

• Start with 2 partners: Even if only one is live, architect as if second can be added without much rework.

• Design data yourself: Data should always be designed and stored at your end. The data from partner’s solution should be reprocessed and then stored.

• No hardwiring to backend: All integrations should be done using middleware so that backend remains independent.

• Fallback: Design the system in such a way that if services don’t work, the core system remains operational. AI should assist the process but never be the process.

• 30-day replacement rule. Design every partner integration under the assumption that you could replace it within a month without crippling operations.

Think of it as building emergency exits into your architecture. You hope you’ll never need them, but you’ll be grateful they’re there when things break.

Design for Exit won’t stop partners from changing, but it will make sure those changes don’t take your systems down with them.

Know someone who’d value this? Forward it.

👥 Want to suggest an exec to feature? Hit reply or message me on LinkedIn.

You’re reading Model in Motion - where modern leaders make sense of AI, without the noise.

Subscribe now

I nearly made a $100K mistake with an AI project - the same one I now see across multiple orgs & AI initiatives. If you’re planning to launch an AI initiative, here’s what to remember…

Last quarter, we took a very complex problem for our production team. Our plants were seeing productivity and leakage issues related to raw material and we wanted a tech solution for the same.

We started building a video-based AI system that would capture all material that got pushed into the conveyers, identify the bad items in real time and improve downstream productivity. It sounded obvious and doable.

We got the budgets approved, hired a product manager, and onboarded an international partner to work on the problem statement. The MVP was supposed to come in 3 months for 1 plant. Everything seemed on track.

During a weekly review, about 7 weeks into the project, I started seeing the results not aligning. The tests kept failing. The results were poor even with our regular scenarios.

I asked the team how many images they processed, and the answer was about 2000.

Not an answer I expected!

To give you an idea, on a realistic basis, we would be processing over 1 million images per day from across our 10 warehouses. And we had processed only 2000 images for training.

That’s when the team realized they did not have data. Neither the volume, nor the format. We were nowhere close to making a successful product.

We got into a war mode for the next 10 days. We built a data collection tool, deployed cameras in the conveyer areas, and aligned ops teams to manually tag the data for the project.

It took us about 20 days to get enough data to be able to build something substantial. Then too, it was not a production ready project.

We eventually succeeded but not before almost failing.

and that’s not just us.

The same happened at a large D2C brand trying to automate their customer support. Their team didn’t have both the historical data and the access to live data. No wonder the chatbot gave bad customer experience.

Across companies, data is the biggest challenge. AI projects not delivering results. Not because of poor tech or team, but because of lack of data.

But what’s the way out?

Today, I get my teams to spend over 50% energy into getting the right data. Here’s the COAT framework that we follow while designing AI solutions:

The COAT framework to get the AI data into shape:

1. Collect Data (current data sources, new streams, etc)

2. Organize data (clean, label, structure it)

3. Analyse the Data (identify patterns, gaps, edge cases)

4. Train the models (build intelligence & automation)

Remember, in any AI development, training the models and building solution is the 4th step. Skip any of the first three, and the fourth step will fail. No matter how good your team is.

💬 Leadership Signal

“The people closest to the problems have the best ideas to solve the problems. If coding is the main thing holding them back, Just start building (using AI).”

• Amjad Masad, CEO - Replit

Know someone who’d value this? Forward it.

👥 Want to suggest an exec to feature? Hit reply or message me on LinkedIn.

You’re reading Model in Motion - where modern leaders make sense of AI, without the noise.

AI has created a strange new battlefield in hiring: Recruiter Bots vs Candidate Bots.

Candidates now use GPTs to personalize resumes, insert JD keywords, and apply to as many roles as possible. Some tools have automated the entire discovery to resume personalization to the application process.

The recruiters are getting more applications than ever. As per LinkedIn, every minute, over 11000 job applications are being submitted. Obviously, recruiters are resorting to AI tools that filter out irrelevant candidates. And yet, most recruiters say the same thing: “All the resumes look the same.”

Is this good or bad? I don’t know, but one thing is clear: Great candidates are still getting rejected while hiring managers still have to take more interviews.

I worked with recruiters to solve this and always found a simpler solution than using expensive AI tools and revamping the entire HRMS & ATS process.

The Non-Negotiables + ChatGPT- Things that don’t show up in the JD but matter most.

Examples:

• One of the last two experiences must be in supply chain or e-commerce.

• Should have spent over 3 years in one of the last 3 stints.

• Should be from a product-based company rather than service

• The candidate should strictly be in a specific location set. Relocation reduces probability to join.

LLMs are great at understanding resumes and filtering the candidates basis requirement, be it from JD or the non-negotiables. Providing ChatGPT with resumes, the JD, and non-negotiables outperformed most AI tools we’d used.

Non-negotiables improved hiring process by over 3X in my last company. Recruiters were able to find relevant resumes, hiring managers were taking right interviews, and were able to close positions faster. We achieved this without switching the HR tools. Without expensive AI bots. and without much technical work.

The thing is that AI is as good as the inputs provided. Better boundaries in, better results out.

🔍 Strategic Signals This Week

📰 DeepSeek has data privacy concerns; Banned in Germany & Italy already

A German official has recently asked Google and Apple to remove DeepSeek from their app stores in Germany. As per him, DeepSeek did not provide convincing evidence that users’ data was protected according to EU laws. Just so you know, Italy has already banned DeepSeek from their app stores citing similar reasons.

Why it matters for CXOs:

The concerns related to Data Privacy and compliance are real as AI companies are doing everything to get more access to data. If you are planning to use any AI tool inside the company, make sure to understand the data privacy terms.

📰 Over 40% CIOs do not intend to start AI projects before 2026.

As per research, less than 25% leaders have implemented AI project while have already decided to pursue once the hype settles down.

Why it matters for you:

Tech leaders know that jumping in the trend and splurging their already tight budgets may not result in org value. Better to wait and watch.

The best in AI is yet to come. Leaders should spend some time and efforts into understanding business problems; process flows where AI can be implemented.

💬 Leadership Signal

“AI allows you to do any job. Because it allows you to be a passable UX designer, a decent SFX animator, and so on. But it doesn’t necessarily mean you can do that job well, as a specialist is often needed for polish..”

• Balaji Shrinivasan - founder, Network School

📬 Know someone who’d value this? Forward it.

👥 Want to suggest an exec to feature? Hit reply or message me on LinkedIn.

You’re reading Model in Motion - where modern leaders make sense of AI, without the noise.

Share

Opening Insight: Serve the information stored inside the org and powerup your teams

Information, if served right can make orgs faster and efficient. Most teams and leaders struggle in getting the right information in right time. With AI, this became simpler.

AI understands context, can process vast knowledge bases, and deliver specific, useful output. This shift - from Search to Serve - is a foundational change. A change that promises to reboot the org processes with faster turnaround.

Two examples:

McKinsey built an inhouse AI assistant called ‘Lilli’ consolidating their entire knowledge base. This chatbot today helps over 75% of their employees with the historical learning.

As per Erik Roth, a senior partner at McKinsey:

Lilli aggregates our knowledge and capabilities in one place … allowing us to spend more time with clients activating those insights and recommendations and maximizing the value we can create.

At my previous org, the policy and compliance teams used to get hundreds of queries from different business units. Each query used to take over 2 days and a lot of manual vetting. We created a simple GPT (without any coding) feeding it with our internal and external policy documents. The tool became a go-to place for all policy document with other teams requesting for their solutions as well.

Where to start?

Ask yourself: Where is information available & used - but not served?

Such as repeated questions, heavy research, or document-heavy approvals. Start looking for No-code simpler tools that can be quickly started and implemented.

🔍 Strategic Signals This Week

📰 Bootstrapped, 8-membered Base44 sells for $80m to Wix

Wix has acquired Israel-based Vibe Coding platform Base 44 on an all-cash $80m deal. This deal becomes significant as AI code assistants are gaining popularity. Cursor, the leader in this space, recently raised $900m on a $9B valuation.

Why it matters for CXOs:

AI is making engineers extremely productive. If you’re still wondering if you should get your team's access to Cursor or Copilot, please don’t. The productivity boost it gives far compensates for the costs. And it’s a great selling point for hiring.

💬 Leadership Signal

“We stopped chasing AI capabilities and started mapping out business problems. That’s how the wins came.”

• CTO, B2B SaaS company (Interviewed last month)

🟢 Takeaway: Your org doesn’t need more AI capability. It needs better problem framing.

Know someone who’d value this? Forward it.

👥 Want to suggest an exec to feature? Hit reply or message me on LinkedIn.

You’re reading Model in Motion - where modern leaders make sense of AI, without the noise.

Executive Summary

Choosing the right AI model is often the first — and most strategic — decision when building an AI solution. The choice between open-source models and prebuilt enterprise models isn’t just technical. It’s a call on data ownership, speed to market, cost structure, and long-term advantage.

Open-source models offer control, customizability, and potential cost advantages at scale — but come with higher upfront complexity. Prebuilt models like ChatGPT or Claude offer speed and ease of integration but raise concerns around data exposure and platform dependency.

The right choice depends on four factors: data sensitivity, speed, cost, and strategic importance.

If you’re building: A core product using proprietary data and targeting large-scale deployment — lean toward open-source (e.g., LLaMA, DeepSeek). A support tool for operational improvements or enabling teams with AI capabilities — start with prebuilt models (e.g., ChatGPT, Claude) for speed and simplicity.

⸻

“Should we use DeepSeek instead of ChatGPT and train on our own data?”

I hear this question often from executives shaping their AI strategies. And it’s a valid one — the answer influences everything from hiring and infrastructure to delivery timelines.

The recent rise of DeepSeek brought this question to the forefront. Trained at a cost of just ~$6 million, it showed that building capable models doesn’t always require billion-dollar budgets. It helped push open-source adoption into the enterprise spotlight by making the cost equation visible.

⸻

Quick Overview: The Model Landscape

Open-source leaders : LLaMA (Meta), Mistral, DeepSeek. Meta’s LLaMA has been downloaded over a billion times and is leading the push for democratized AI infrastructure.

Enterprise leaders: GPT (OpenAI), Claude (Anthropic), Gemini (Google). These are backed by heavy funding and offer robust APIs, plugins, and toolchains.

Enterprise models lead on reliability, reasoning, and ecosystem readiness. But open-source is rapidly catching up, especially for fine-tuned, domain-specific deployments that require tighter control.

⸻

What Leaders Often Get Wrong

1. “Open source is free”

It’s not. You’ll need GPU resources, MLOps infrastructure, and engineering talent. Cost appears over time, not upfront.

1. “We can just plug it in”

Open-source models often need fine-tuning, prompt engineering, or retraining. They’re flexible — but not plug-and-play.

1. “All use cases are equal”

You must ask:

• Is this AI powering a customer-facing feature?

• Or automating an internal task?

• Or just improving existing workflows?

Overthinking leads to delays. Misunderstanding leads to poor outcomes.

⸻

I’ve helped numerous organizations design their AI strategies and have observed that each case is unique and different basis organization capability, product complexities, and impact. Building these solutions led me to a particular framework that works well while deciding the models.

The 4-Factor Framework for Choosing a Model

1. Data:

Is the data proprietary, regulated, or highly sensitive? If yes, open-source offers more control, compliance, and confidentiality.

Example: At a travel aggregator, we built an in-house model for review sentiment and support automation using internal data — but let marketing use external tools like GPT for content and research.

2. Strategic Role

Is this solution part of your long-term product roadmap or customer offering? If yes, invest in a custom solution. If not, speed matters more than control.

3. Cost

Open-source has higher setup and talent costs. But as scale increases, marginal costs drop. Compare build-vs-buy carefully — especially for sustained usage. Just for example, DeepSeek required NVIDIA- H100 GPUs which cost about $2/hour. In this cost, 60 ChatGPT licenses can be purchased.

4. Speed

Prebuilt APIs win on time-to-market. Open-source models take weeks (or months) to tune and deploy.

My usual advice:

start with a prebuilt model, test value and workflow fit, then scale into open-source if the impact is proven.

For example, a mid-size SaaS company wanted to automate their support ticket triage- categorizing issues, tagging urgency, and suggesting next actions. They started with Claude via API. Required minimum setup, instant results, and quick iterations. They improved response time by 30% using this. Once the value was validated, they trained a Mistral Model hostel privately on GPUs. Saved costs extensively and were able to control the responses and results.

Best way is to Start Small. Scale Smart.

⸻

Bottom Line

• Core + Proprietary = Open-source

• Support + Speed = Prebuilt APIs

Make the strategic choice — not just the technical one.

I would love to hear how you implemented and scaled AI in your organization. Drop a mail to ayush@modelinmotion.com and let’s chat.

Thanks for reading Model in Motion - No jargon AI strategies for leaders! This post is public so feel free to share it.