Post #1 was about thinking clearly under extreme uncertainty i.e. deciding when the signal is weak & the stakes are high. Post #2 was about the mindset upgrade this era demands. Post #3 was about finding real use cases, not AI theatre. Post #4 was about what actually changes when intelligence enters a workflow. Post #5 was about the organisational posture i.e. the Skunk Team. Each of those posts assumed something. That you had the vocabulary. The mental models. The map. Lets build one in this post.

Prologue - The Maze Has New Walls

Balaji Srinivasan coined the concept of the Idea Maze i.e. the insight that good founders do not just sprint toward an entrance; they deeply study the history of the maze, the dead ends others have already hit, and the walls that technology will move.

His exact framing: “A good founder is capable of anticipating which turns lead to treasure and which lead to certain death.”

Here is the thing that has changed. In 2025, AI is actively redrawing the walls of every maze i.e. weekly. The relational database wall moved. The 50-person engineering team wall moved. The 18-month product roadmap wall moved.

The question for the Building in the Middle founder is not just how to navigate this maze. It is: do you even understand how the new walls are built?

There are two kinds of people building with AI right now. Tourists. And founders.

Tourists learn the surface layer. They use ChatGPT. They add “AI-powered” to the pitch deck. They bolt a GPT wrapper onto an existing workflow and call it a product. They move fast and build nothing that lasts.

Founders go deeper.

They understand why the reasoning changes. They know the vocabulary well enough to catch bad assumptions in a product review. They have mapped the history so they are not fooled by the hype. They build on conviction, not novelty.

The gap between the two is not intelligence. It is not funding. It is not even time.

It is a deliberate decision to upgrade the most important hardware they own. Their mind.

The hardest part of building VidyaAI at ExtraaEdge was not the engineering. It was not the sales. It was this: upgrading my own mental model fast enough to keep up with what we were actually building. The ground moves like light.

Curricula expire. Best practices shift quarterly. The founder who mapped the AI Idea maze in 2023 has an outdated map.

Post #6 is the practical field guide for skilling up and staying skilled up when the ground refuses to hold still.

Part 1 - Why This Is Not “Learning New Software”

Every time a new tool category emerged i.e. CRM, ERP, Workflow Automation, analytics, no-code platforms founders learned the surface layer & moved on.

You did not need to understand how Salesforce stored data to sell with it.

AI is different. Here is why.

In SaaS, the software did what you told it. Deterministic input → Deterministic output. Your database returned exactly what you queried. In AI, your system approximates what you meant.

Same prompt, variable output. WTF. A model that works 95% of the time fails 1 in 20 queries and in an EdTech admissions workflow, that 1 in 20 is not a rounding error. It is a counsellor trusting bad output. A student getting wrong scholarship information. A follow-up that never happened.

This is not a tooling shift. It is a reasoning shift. The tourist treats it like a tooling shift. Learns the prompts. Moves on. The founder understands the reasoning shift. And builds differently because of it.

You cannot spec an AI product the way you spec a SaaS feature. You cannot QA it the same way. You cannot price it the same way. You cannot explain it to a customer the same way. You cannot hire for it the same way.

The founder who upgrades their mental model first may thrive. The tourist will wonder why the moat never forms & is designed to fail.

Part 2 – The SaaS-to-AI Translation Table

Every SaaS concept you already know has an AI-era equivalent. The logic is different enough to cause expensive mistakes if you conflate them. Tourists conflate them. Founders know the difference.

The sentence to anchor everything else on:

In SaaS, your database did what you told it. In AI, your model approximates what you meant.

Every product decision i.e. architecture, pricing, hiring, go-to-market flows from understanding that gap.

Part 3 – The History You Must Know Before the Tools

Tourists jump straight to tools. Founders learn the story first. Understanding where AI came from prevents you from building on sand.

Three books. Three different lenses. All essential.

📖 The Coming Wave – Mustafa Suleyman (2023)

Your macro lens.

Suleyman co-founded DeepMind & is now CEO of Microsoft AI.

The book argues that AI & synthetic biology represent a wave of technology that cannot be contained and that the tension between proliferation and control will define the next decade.

Not hype. Not doom. Systems-level thinking. For founders building in EdTech – selling to universities & institutional buyers i.e. the “containment problem” is not abstract. It is the first objection in every sales call. Understanding Suleyman’s argument is not academic preparation.

It is sales preparation.

What to take from it: Technology comes in waves. Founders who understand the physics of the wave ride it. Those who don’t get knocked down by it.

📖 AI Snake Oil – Arvind Narayanan & Sayash Kapoor (2024)

Your calibration lens.

Two Princeton computer scientists who cut through the hype with precision.

They distinguish between AI that genuinely works, AI that sort of works, & AI that does not work but gets sold aggressively.

For EdTech founders: the admissions AI space is full of snake oil. “AI-powered” tools that are mostly keyword filters with a GPT wrapper. Knowing the difference protects you from building it & from being out-competed by someone who builds it correctly.

Tourists cannot tell the difference. That is the vulnerability.

What to take from it: Before you build it, ask is this actually a hard AI problem or a workflow problem with AI branding? The honest answer changes your architecture, your pricing, & your defensibility.

📖 Empire of AI – Karen Hao (2025)

Your power dynamics lens along with the fundamental history of AI as we know today.

Symbolic AI → Neural Networks → Deep Learning → Attention → Foundation Models → Agents

An investigative account of OpenAI based on years of inside access & 260+ interviews. It traces the economics of compute, data labour, & energy that underpin the entire industry.

What to take from it: Only a handful of companies compete at foundation model scale. Your job as a founder building in the middle is not to build the next OpenAI. It is to build the application layer on top of it intelligently. Understand the power structure. Know what not to fight. That is where your leverage lives.

Now, there are several great books out there & many will be written in the future too. However, these 3 are great starts to build the learning map to navigate the freaking AI maze.

Part 4 – The Vocabulary You Must Own

You do not need to write the code. But you need the fluency to:

• Judge tradeoffs in a product review

• Ask the right questions in a hiring conversation

• Hold your ground in an investor Q&A

• Educate your Skunk team when they are in Analysis Pralysis

Tourists scroll the vocabulary. Founders own it. Here is the minimum viable stack in two tiers.

Tier 1 vocab → so know these cold. These are the terms that will come up in every technical conversation, every board meeting, every customer pilot.

Tier 2 –> Founder Depth. Know the tradeoffs. These are the decisions that will make or break your product roadmap & pricing model.

Part 5.1 – What to Learn, From Where, From Whom

One rule: learn from practitioners who have shipped, not academics who have theorised. There are many out there doing aamzing work but I am biased for action & people who have built stuff.

The crazy thing is most of the stuff is Free to view. However, I have personally benefited from are Maven Paid Courses Lenny List, AI Engineer Youtube Sessions & CodeAcademy 101s on GenAI & AI to name a few.

Here Andrej Karapathy is the OG & worth checking on what he writes, builds & says.

He’s here - Karpathy Universe

Part 5.2 - The Five Voices Worth Following

These are not people to passively scroll. Each one is a mental model provider i.e. sharpening a different dimension of how you think. Also, its my bias & subjective opinions on folks I have benefieted from. Add ones that you found useful.

Andrej Karpathy : Follow for first-principles AI literacy. His “Software 2.0” essay from 2017 called this entire transition years early.

Swyx (Shawn Wang) : Follow for technical ground truth. The most plugged-in independent voice on what AI engineers are actually building.

Lenny Rachitsky : Follow for the product & growth layer. His Maven list rotates quarterly & is the clearest signal of what the product community is paying to learn right now.

Kyle Poyar : Follow for AI pricing strategy. His framework – access → work → outcomes – is the clearest pricing lens available. Have that conversation before you build, not after.

Michael Seibel & Dalton Caldwell (YC) : Follow for startup operating context. The closest thing to a free manual for early-stage AI companies.

Part 6 – The Recipe for Building a Good AI-First Product

You have the vocabulary. You have the history. You have the people to follow. Here is how you mix it into something that works.

The ingredients are known. The craft is in the ratios & sequencing. Tourists skip to the recipe without reading the first four sections. That is why their products feel like AI theatre.

Ingredient 1 –> Start with a real workflow problem, not an AI problem

AI products that survive are not built around “where can we use AI?” They are built around “what workflow is broken, and can AI fix it better than anything else?”

At ExtraaEdge, Vidya AI starts with the broken admissions workflow: missed follow-ups, the scholarship PDF buried in email, and the counsellor managing 300 students across scattered Excel sheets. Not with “let’s use LLMs for EdTech.”

AI Snake Oil makes this argument without mercy. The workflow comes first.

Ingredient 2 –> Own your data

The moat in AI is not the model. It is the data.

Every conversation, outcome, & correction your users make is training signal. Design your product to capture it from day one.

Ingredient 3 –> RAG before fine-tuning

Start with RAG it’s cheaper, faster to update, easier to debug. Fine-tuning comes later when you have labelled data & a clear performance gap RAG cannot close.

Ingredient 4 –> Evals from day one

Ship with a measurement system, not just a product. Define what “good” looks like. Build a small eval set. Run it with every release. Ship without evals = ship without tests.

Ingredient 5 –> Price around outcomes, not features

Kyle Poyar’s framework: seats → usage → outcomes.

For EdTech: per successful placement, per admission cycle completed, or per counsellor hour saved. Have the pricing conversation before the architecture conversation.

Ingredient 6 – Feedback loops baked into UX

Thumbs up & down. Correction flows. Usage heatmaps. These are not nice-to-haves. They are the compounding engine. Customers who give feedback are training your system.

Part 7 – The Continuous Learning System

The AI landscape moves faster than any curriculum can track.

Lenny Rachitsky noted in late 2025 that his Maven course list shifted from “how to use AI to write PRDs” to “how to build reliable agentic systems” — in a single quarter.

That is not drift. That is a wall moving. Tourists read a few newsletters and feel current. Founders build a system.

Weekly

• One Latent Space episode – what AI engineers are building right now

• One AI Engineer YouTube video – what researchers at Anthropic, Google & OpenAI are shipping

• One Kyle Poyar newsletter – what AI is doing to pricing & growth

Monthly

• One MIT OCW lecture or Karpathy video – keep the technical foundation sharp

• Two to three AI Engineer Summit talk abstracts – track what problems the field considers important

• Review your product’s eval benchmarks against current best models

Quarterly

• Check Lenny’s updated Maven course list – enrol in one if a skill gap is obvious

• Revisit your pricing model against Poyar’s latest thinking

• Re-read one chapter of AI Snake Oil – recalibrate hype versus what has actually shipped

Annually

• Read one foundational book. The Coming Wave, AI Snake Oil, Empire of AI — rotate with new releases each year.

The meta-rule:

You are not trying to become an ML engineer. You are developing the literacy to ask sharper questions, catch bad assumptions early, & make product bets with higher confidence. The goal is judgment. Not depth.

Epilogue – The Maze does not wait

I came back from a Ranchi visit recently thinking about this.

Growing up in a small town, you learn to read environments fast i.e. the ones with real opportunity & the ones that look like opportunity but are actually dead ends. It is survival literacy.

Building in the AI era demands the same thing. Not panic. Not hype-chasing. Clear mapping. Disciplined updating. Courage to act on what the new map shows.

The Building in the Middle series has always been about the same thing: what it takes to build with clarity when the conditions are genuinely hard.

Most people in your position are tourists. They are not lazy. I used to be a tourist & maybe you are too. They are just moving too fast to go deep.

The founder who builds this skill stack studies the maze, is a student of AI history, navigates deeper, slowly & then fastly. Goes deeper when its essential & skims the surface when needed. Builds something that has the potential to endure.

When the reasoning shifts, so does everything else.

Here’s to building like founders with discipline, depth & the courage to keep upgrading.

If you’re building in the middle, you’re not alone. Let’s figure this out together.

Abhi Ballabh is the co-founder and CEO of ExtraaEdge & VidyaAI the Intelligent Admission Growth Platform for the Education Industry, building through the AI transition from the trenches. Building in the Middle is his attempt to think out loud about what it takes to navigate platform shifts without losing your mind or your company.

The Number That Should Stop You Cold

Midjourney did $200M in revenue with 11 people. Cursor crossed $100M ARR in 21 months with 20. Bolt.new went from zero to $20M ARR in two months with 15.

Read those again. Slowly. Now, here’s the question those numbers don’t answer: **what does this mean for you?**

You’re not building Midjourney. You’re not a greenfield AI startup with no legacy, no customers, no team to manage, and a single moonshot bet. You’re running a SaaS company. You have 70 people. Live customers. A product that works. Contracts that renew. A team that trusts you. An engineering codebase that took four years to build.

You can’t fire everyone and start fresh. You can’t go recruit 15 AI researchers from IIT or Stanford. You can’t press pause on the core business while you “figure out AI.”

But you also can’t ignore what’s happening. So what do you actually do?

You carve. You carve out a team from the body you already have i.e. small enough to move fast, skilled enough to ship AI, and connected enough to the core product to not build something irrelevant. You create a contained unit with a clear mission, a direct line to the CEO, and permission to operate differently from the rest of the company.

In the AI era, you don’t need a bigger team. You need a *different* team.

A skunk team.

A Lesson from 1954

Before we go anywhere else a little walk down the history.

In 1954, Kelly Johnson led a team at Lockheed that built the U-2 spy plane in 8 months. Fewer than 50 engineers. Operating out of a rented circus tent near the main factory. Isolated from corporate bureaucracy. Direct access to one decision-maker. No layers.

Johnson codified his operating principles into what became known as the Skunk Works rules.

Rule : ”The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people.”

That was 1954. The principle hasn’t aged a day.

The Skunk Works wasn’t about secrecy. It was about *clarity*. When you have 6 people and one mission, there are no politics. No handoffs. No “let me check with my team.” There’s just: what are we building, why does it matter, and who does what today.

That’s the energy. That’s what you need to carve out.

Part 1: The Evidence – Tiny Teams, Massive Output

Let me show you the hard numbers first. Because this isn’t a philosophical argument – it’s a structural shift in how software gets built.

Compare this to traditional SaaS: $150K–$250K revenue per employee is considered healthy. AI-native companies are doing $2M–$3M+. Per person.

Gartner predicts 80% of organizations will evolve large software engineering teams into smaller, AI-augmented units by 2030. That prediction is already happening. Right now. This quarter.

But here’s what nobody tells you and this is the part that actually matters for Building in the Middle readers.

Every company in that table was AI-native from birth. Born in the LLM era. No legacy product. No existing customer base to protect. No SaaS muscle memory to fight.

The harder, more instructional question is: what about companies like yours?

Here’s what that looks like in practice.

Intercom → Fin AI Agent. Des Traynor and his co-founders took a 15-year-old SaaS company and rebuilt it for AI. Fin now resolves over 1 million conversations a week across 7,000 customers. On track for $100M in revenue. The org structure itself changed to accommodate this. Des said it plainly: ”Our org structures themselves changed in order to accommodate all of this.”* Support team structure changed. Product teams changed. The entire company adapted.

Freshworks → Freddy AI. AI-related ARR more than doubled year-over-year. They launched vertical AI agents for e-commerce, fintech, travel, and logistics. The key insight from their transition: simplicity as a differentiator. Not the most powerful AI. The simplest AI that works for the workflow.

Palantir’s → Forward Deployed Engineers.The original skunk team model, before AI was even a mainstream conversation. A couple of FDEs could do in days what hundreds of IT service professionals took months to accomplish. The power wasn’t in the headcount. It was in the combination of technical depth + customer proximity + decision authority. Sound familiar?

ExtraaEdge → VidyaAI. And then there’s us the transition we’re living in real time & it’s still very early days. The team carving exercise isn’t theoretical for me. It’s Monday morning. It’s the conversation I had last week. It’s the decision I make every sprint cycle about where the best minds go i.e. core SaaS or AI skunk team.

The AI-native numbers are aspirational. The SaaS-to-AI transitions are instructional.

Post #5 is about the latter.

Part 2: Why the Skunk Team Model Isn’t Optional

The Skunk Works must be run by a small number of good people. A small, elite team of highly skilled engineers can achieve more, faster, than a large, bureaucratic organisation.

Kelly Johnson, Lockheed Skunk Works. This isn’t nostalgia for 1954. It’s the architecture for 2026.

Here’s how Kelly Johnson’s principles translate:

Why is this model *mandatory* and not just a nice-to-have for SaaS-to-AI transitions? Three reasons.

Model velocity → LLMs and tooling change every 2–4 weeks. A 30-person team with 3 layers of approval cannot keep up. A 6-person team that ships daily can. The physics of AI product development require small surface area and fast feedback loops. This is not an organizational preference. It’s a technical constraint.

Eval over spec → AI products cannot be fully specified upfront. You build, evaluate, iterate. The traditional SaaS model i.e. write a spec, design, build, QA, ship breaks when you’re working with probabilistic models. You need people who can context-switch between building and judging. That requires a small, generalist team, not a siloed department.

Cultural gravity → Your existing SaaS team has four-plus years of muscle memory for deterministic software. Test cases. Regression suites. The logic of: “if input A, then output B, always.” The skunk team needs to think probabilistically — “for input A, output B 87% of the time, and that’s the goal.” That mindset can only form in isolation first. Then it diffuses outward, when the skunk team proves what’s possible.

Small teams aren’t a luxury. They’re the new physics of AI software.

Now – the archetype.

Part 3: Six Roles, One Unit

This is the heart of it. Not a headcount number. Not an org chart. An archetype.

Six roles. Each one essential. Each one distinct. And if you have the right six people – in my experience, you have almost everything you need to ship something real.

Role 1: The Founder (CEO) — The Pattern Recogniser

Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.

-Margaret Mead

This is your role. And I want to be honest with you about what it actually requires because it’s different from what founding a SaaS company required. You are not the smartest coder in the room. You are not the deepest AI researcher. You are not the best designer.

You are the fastest learner. The clearest thinker under pressure. The person who reads the model landscape on Monday, rewrites the product thesis on Tuesday, and unblocks the designer on Wednesday. The person who holds the “Commander’s Intent” not the spec, not the feature list, but the *outcome*.

For us at ExtraaEdge, the Commander’s Intent for VidyaAI is specific: autonomous, workflow-native intelligence for Indian higher education admission teams that helps counselors spend time with students instead of spreadsheets. Not “we’re building AI.” Build *what*, for *whom*, solving *which specific friction* i.e. that’s the intent. Everything else is a decision tree that flows from it.

What this role demands in practice:

→ You set the Commander’s Intent – not the spec, but the outcome. The team executes to the outcome, not the prescription.

→ You make the resource allocation calls between core SaaS and the AI skunk team every week. Not every quarter. Every week. The balance shifts as you learn.

→ You personally demo every weekly build to at least one customer. Not to pitch. To learn. To hear where the confusion is, where the delight is, where reality diverges from assumption.

→ You absorb the uncertainty. The team can’t function if they’re paralyzed by ambiguity. Your job is to convert uncertainty into direction – even when that direction isn’t perfect.

The mindset this requires differs from the SaaS-founder mindset in one critical way: you must be comfortable killing last week’s feature because this week’s model made it obsolete.

That kind of nimbleness is hard for founders who spent years building careful, deliberate roadmaps. It feels like instability. It isn’t. It’s the velocity that the AI era demands.

Read model release notes the week they drop. Talk to counselors in Pune about their daily calling workflow.

Try every AI feature personally before it ships. The new founder archetype is both maker and storyteller. They don’t “launch and leave.” They learn out loud. And they bring the team with them.

Role 2: The Engineering Lead – The Bridge Between Two Worlds

Good engineering must be direct, honest, and fast. Bad engineering hides behind procedure.

Kelly Johnson, Skunk Works

This person is the most structurally important hire in your AI skunk team – and the hardest to find, because you need two rare things in one person.

Deep SaaS engineering experience. And genuine belief in AI’s architectural promise.

Not a SaaS purist who thinks LLMs are hype. Not an AI evangelist who wants to rebuild everything from scratch. The bridge. The person who looks at your 4-year-old codebase and sees not a legacy burden, but a foundation to build on.

What this person actually does:

→ Architects the system so AI components plug into the existing SaaS without breaking it. This is harder than it sounds. The temptation is to build the AI layer in isolation, ship something impressive, and then figure out integration later. That path leads to a brilliant demo that can’t go to production.

→ Makes the “build vs. call API” decisions on LLM infrastructure. Do you fine-tune your own model or call GPT-4? Do you build RAG from scratch or use a managed vector database? These aren’t just technical decisions – they’re cost, latency, and dependency decisions with real business consequences.

→ Manages technical debt from the SaaS era while creating new AI-native modules. This is the tightrope. You can’t pause the SaaS product to rebuild for AI. You build alongside.

→ Ensures the skunk team’s code can eventually merge back into the main product. The skunk team is not forever. From Day 1, the engineering lead is thinking about re-integration.

The biggest risk in a SaaS-to-AI transition isn’t building bad AI. It’s building good AI that can’t connect to the product your customers already use.

The engineering lead is the bridge that prevents that.

Role 3: The QA Lead → Eval Lead – The Translator

We must not only use the brains we have, but all that we can borrow.

-Marie Curie

This is the most underestimated role in the entire AI stack. I’ll say it again: **the most underestimated.**

In traditional SaaS, the QA lead writes test cases. Input A → Output B. Pass/fail. Deterministic. Clean. The test suite either goes green or it doesn’t.

In AI, that framework breaks. The model doesn’t always produce Output B. Sometimes it produces Output B-prime, which is close but not identical. Sometimes it produces Output C, which is semantically equivalent but phrased differently. Sometimes it hallucinates – confidently generating Output D, which is plausible-sounding and entirely wrong.

So what does quality even mean in this context?

The Eval Lead answers that question. Every day.

→ They build eval pipelines i.e. not test suites. These measure semantic similarity, hallucination rate, factual consistency, tone adherence, and task completion accuracy. Not “does it work?” but “does it work well enough, reliably enough, for this workflow, in this context?”

→ They create the Reliability Scorecard i.e. a composite metric that can be reported to enterprise customers. “Our AI maintained 94% task accuracy across 10,000 calls this month” is a statement your Eval Lead makes possible.

→ They work hand-in-glove with the LLM engineer in a closed loop: prompt → output → eval → prompt refinement → output → eval. This loop is where quality is actually made. Not in the original build. In the iteration.

→ They own the quality bar. They decide whether an AI feature ships or goes back for another round.

Here’s the insight I want every SaaS founder reading this to sit with: **you almost certainly already have a QA lead.** And if they’re curious – genuinely, technically curious this is the role with the highest leverage re-skilling in your entire company.

The shift from test-writing to eval-building is learnable. The mindset shift i.e. from deterministic to probabilistic quality thinking – is the harder move. But for the right person, it’s also the most intellectually interesting move they’ll make in their career.

Invest in that person. The Eval Lead is your most valuable AI team member hiding in plain sight.

Role 4: The Designer – The Young Mind That Sees What You Can’t

Creativity is thinking up new things. Innovation is doing new things.

Theodore Levitt, Harvard Business School

I want to be careful here, because I’m going to say something that might sound like age bias it isn’t.

The designer you need for the AI skunk team is young. Not because older designers can’t design for AI. But because of a specific kind of *pattern exposure* that matters enormously right now.

If someone has spent the last three years as a daily user of Perplexity, Cursor, ChatGPT, Linear, Notion AI, and Claude i.e. they have something invaluable: an *intuitive feel* for what great AI-embedded UX looks like. They haven’t just read about it. They’ve lived inside it. That embodied understanding of AI-native interaction is something you cannot teach. You can only hire.

What this designer actually does:

→ Designs the interface where AI meets the workflow. Not a chatbot bolted onto the side of your CRM. Intelligence woven into the UI – surfacing the right information at the right moment, in the right form, without making the counselor think about the AI at all.

→ Reduces cognitive load in high-density enterprise screens. If you’ve ever looked at an admission CRM with 47 fields on a single page, you know what I mean. The designer’s job is to make that world simpler, not just prettier.

→ Creates visual hierarchy that signals “AI did this” vs. “You need to do this now.” This is one of the most nuanced design problems in AI product work – and it’s entirely unsolved at most companies.

→ Prototypes rapidly. Figma to code, not Figma to committee. In an AI skunk team, the design review doesn’t take two weeks. It happens in the same standup where the build happens.

In Post #4, we talked about how customers come for the AI but stay for the workflow.

The designer is the person who makes the “staying” happen. If the AI capability is the engine, the designer is the road.

Role 5: The Full-Stack Developer – The Glue

Alone we can do so little; together we can do so much.

-Helen Keller

Every skunk team needs someone who doesn’t care about the architecture debate and just ships. The full-stack dev is that person.

Front-end. Back-end. API. Deployment. They span the entire stack without needing to specialize. They can wire up any AI capability into a working product. They can turn the designer’s prototype into a shippable feature in 72 hours.

What makes this role essential isn’t glamour. It’s **execution continuity.**

When the LLM engineer is deep in prompt optimization, the full-stack dev handles the API layer. When the designer finishes the new counselor dashboard, the full-stack dev builds it out. When the integration with the college’s existing SIS needs to go live, it’s the full-stack dev holding the deployment together.

They also handle the unglamorous plumbing i.e. the CRM integrations, the WhatsApp connectors, the email parsing, the payment gateways, the data pipelines. None of this is exciting to talk about. All of it is critical to ship.

In India’s SaaS ecosystem, full-stack engineers are genuinely abundant. This is good news. The profile you need isn’t exotic. It’s curiosity, craft, and a tolerance for switching contexts ten times a day.

If the LLM engineer is the intelligence layer and the Eval Lead is the quality layer, the full-stack dev is the layer that actually makes it real.

Role 6: The LLM/AI Engineer – The Intelligence Layer

Applied research generates improvements, not breakthroughs. Great scientific advances spring from pure research.

Edwin Land, Polaroid founder

Let me dispel a hiring myth right now i.e. because I see Indian SaaS founders making this mistake consistently.

You do not need an ML engineer who can train a model from scratch. You do not need a PhD in machine learning. You do not need someone who can reimplement backpropagation on a whiteboard.

Here’s what Humanloop (one of the best teams building AI dev tools) says plainly:

“You probably don’t need ML engineers... LLMs come pre-trained with general knowledge. Much less sophistication is needed to use them. What you need is someone who can *orchestrate* intelligence. Not build it from scratch. Leverage it.”

→ They select the right model for each task – because “use GPT-4 for everything” is the same logic as “use a sledgehammer for every nail.” A constellation of models: one for extraction, one for reasoning, one for generation, one for evaluation. The right model in the right place.

→ They build RAG pipelines, prompt chains, and agent workflows. This is the actual engineering work of AI product development in 2026 – not training, but orchestrating.

→ They fine-tune for domain-specific accuracy. At ExtraaEdge, this means VidyaAI needs to understand Indian higher education terminology: DTE cut-offs, counselling rounds, NIRF rankings, the difference between a management quota seat and a merit seat. General models don’t know this. Domain fine-tuning is how you make the AI feel like it was built for your customer.

→ They stay current. This is the most important thing. Model capabilities change monthly. The LLM engineer is the team’s “model intelligence” — the person who knows which new capability could change the product’s approach and brings it to the team before the competition does.

Edwin Land’s insight cuts precisely here: pure research (using pre-trained LLMs, standing on the shoulders of OpenAI and Anthropic and Google) is what enables breakthroughs for Indian SaaS founders. You don’t need to do the science. You need to do the *application* i.e. with depth, curiosity, and domain specificity.

The Archetype of 6 at a Glance

Six roles. Each one essential. Each one distinct. And if you have the right six people – in my experience, you have almost everything you need to ship something real.

Part 5: The Intercom Lesson – What a 15-Year-Old SaaS Company Did

I want to spend some time on Intercom because of all the SaaS-to-AI transitions happening right now, theirs is the most instructional for Building in the Middle readers.

Des Traynor, co-founder, describes what it actually took.

On a Friday afternoon, Des spoke with CEO Eoin. By Monday morning, they had agreed: go all-in on AI. Scrapped existing roadmaps. Rebuilt the product thesis from scratch.

Fin started at a 25% resolution rate for customer support conversations. Today it’s around 70%. It resolves over 1 million conversations per week. Across 7,000 customers. On track for $100M in revenue from an AI feature alone.

But here’s the detail I keep coming back to: **the org structure changed.**

Not just the product. Not just the roadmap. The organizational structure changed to accommodate the AI transition. Support team structure changed. Product teams changed. The way they thought about pricing changed – from seat-based SaaS to outcome-based pricing. Des said it plainly: “If Fin succeeds, there will be fewer CS people. Seats will go down.”

That’s a founder who was willing to disrupt his own revenue model to build for where the world was going.

And how did they do it? Not by hiring an external AI team. Not by acquiring a startup. They rebuilt from within, with the urgency of a startup and the decisional authority of founders who were in the room every day.

Des’s prediction for the future is the one I’d print on the wall of every Indian SaaS CEO’s office: *”Product teams made up of builders who can design, prototype, write code, and shape strategy with AI filling in the gaps.”*

That’s your six-person team.

Part 6: The Founder’s Mindset – You Lead This or Nobody Does

The IBM 2025 CEO Study found that organizations are hiring for AI roles that didn’t exist a year ago. But for the Building in the Middle founder, you can’t just hire your way into this transition.

You have to learn your way in.

There are five mindset shifts that separate the founders who successfully transition from those who stay permanently stuck in the planning phase.

Here’s what the learning imperative actually looks like in practice:

→ Read model release notes the week they drop. Not a summary.

→ Talk to customers about how AI is changing *their workflow* i.e. not your product.

→ Personally try every AI feature before it ships. Not in a QA sense. In a “would I use this?” sense. Your intuition as a founder is a critical signal.

→ Be comfortable saying “I got this wrong and here’s what I learned.” Out loud. In front of the team. This is the single most important culture signal you can send. In an AI skunk team, learning velocity matters more than being right.

The Close: Small Team. Big Mission.

Let me return to the numbers I opened with.

Midjourney’s 11 people didn’t build a $200M company because they were 11. They built it because each of those 11 people knew exactly what they were building, why it mattered, and how their work connected to the whole.

The number isn’t the point. The *archetype* is the point. For the Indian SaaS founder moving to AI, you need six things in six people.

The pattern-recognizing founder who holds the Commander’s Intent and converts uncertainty into direction.

The bridge-building engineering lead who connects the SaaS foundation to the AI future without breaking either.

The quality-translating eval lead who makes probabilistic AI reliable enough to put in front of enterprise customers.

The young designer who sees what AI-native UX should feel like before they can fully articulate why.

The full-stack developer who ships everything, integrates everything, and keeps the whole system running.

The LLM engineer who orchestrates intelligence – not from scratch, but from the shoulders of the best models in the world, applied with domain specificity.

Six people. One mission. One weekly demo. That’s not a department. That’s not a committee. That’s a skunk team.

And in the AI era, building the right skunk team might be the most important organisational decision your company ever makes.

If you’re building in the middle, you’re not alone. Let’s figure this out together.

Abhi Ballabh is the co-founder and CEO of ExtraaEdge & VidyaAI the Intelligent Admission Growth Platform for the Education Industry, building through the AI transition from the trenches. Building in the Middle is his attempt to think out loud about what it takes to navigate platform shifts without losing your mind or your company.

The 8% Ghost Feature

AI features don’t die because the AI is bad. They die because the AI has no home.

There’s a category of this I’ve started calling Vanity AI.

Impressive in a demo. Applause in the room. Sharp in the product screenshot. And then i.e. 90 days after launch they sitting at 8% usage and falling. A ghost in the UI that nobody quite knows how to talk about in the roadmap review.

This pattern is more common than most teams admit. I am the first person I will admit, a SaaS CEO turned PM guilty of it. When my Co-founder Sushil pointed this out to me, my blood boiled. I was angry at myself. A lot.

Most GenAI pilots in B2B SaaS don’t reach production. Of those that do, a significant share get real engagement once in the demo, in the pilot and then decay. Features launch. Monetization doesn’t follow.

Vanity AI isn’t bad AI. It’s AI without a home.

It lives in a sidebar, a tab, a widget. The user has to remember it exists, navigate to it, craft a prompt that gives it enough context to be useful, and then act on the output themselves. It adds cognitive load to an already loaded day.

And so, quietly, it stops being used. The diagnosis is almost always the same: the feature was designed from the model backwards.

The question was “what can AI do?” when it should have been: “what specific step in this workflow is so painful, so repetitive, so data-rich that AI would remove real friction if it lived right inside it?”

In B2B SaaS, customers don’t buy AI.

They buy **work getting done** and **outcomes showing up**. AI is the engine. The workflow is the product.

In Post #1, we built the mental frameworks to survive the transition. In Post #2, we debugged the customer’s actual working day. In Post #3, we found which use cases are worth pursuing. Now we design backwards from workflow and outcome, inward to the AI. Let’s dive in, shall we.

The Ugly Duckling SaaS: Your Hidden Advantage

The narrative says: AI-native startups are winning. Model-first. Clean architecture. Leaner, faster, better-funded.

Your five-year-old SaaS is the slow incumbent. I think the narrative is wrong. And I keep coming back to one analogy to explain why.

In a world of satellites, drones, and cyber surveillance, intelligence agencies assumed that HUMINT i.e. human intelligence, the old practice of running human assets in the field would become obsolete.

Why manage a human source when you can read a country from orbit?

Actually the opposite happened. HUMINT became more valuable. Because no satellite captures intent. No algorithm sees the texture of how a decision gets made. No model understands the informal power structures in a room it was never in.

Your workflow knowledge is HUMINT i.e. human intelligence

The Swan in Disguise

Your “legacy” admissions CRM or sales CRM, or support ticketing system that looks like an ugly duckling next to a slick AI-native startup demo.

But look at what’s actually inside it.

End-to-end workflows encoded in stages, forms, and automations built over years of real use. Thousands of edge cases & not theoretical ones, real ones with names and timestamps i.e. already surfaced and patched. Institutional knowledge of why certain steps get skipped, why certain workarounds exist, which fields never get filled and which ones always do.

An AI-native startup entering your market has clean architecture and a well-trained model. They don’t have five years of watching what actually breaks.

BVP’s research on vertical AI states this clearly: the differentiated asset isn’t the model. Models are commoditising fast. The asset is domain depth workflow understanding, the specific context that makes a general model useful in a specific setting.

You have that context. They’re building it from scratch.

MCP, APIs, models etc. these are the surveillance layer. They operate on the data you feed them. They can’t know why your customers export to Excel two days before month-end. Or why the follow-up sequence always gets paused in week three.

You know that. That knowledge is HUMINT. And in an AI world, HUMINT becomes more valuable, not less.

Old is not dead. It gets reshaped to serve the new.

Work vs Outcomes – What Customers Actually Pay For

Strip away the product, the pricing, the features. Ask: what is the customer actually trying to accomplish?

Almost always, the answer lives in one of two categories.

WORK : activity the system or team performs:

1. - Deals updated, calls made & logged, emails sent

2. - Tickets responded to, campaigns launched, sequences triggered

3. - Applications reviewed, documents processed, reports assembled

OUTCOMES : the business results work is supposed to create:

1. - 200 leads qualified this week

2. - 45 complaints resolved before the SLA

3. - 250 RSVPs confirmed, payroll processed accurately

4. - 80% of enquiries answered before a counselor picks up the phone

WORK is the mechanism. OUTCOMES are the point.

SaaS, historically, sold access to do the work. The contract said: here is the surface area. The outcome is yours to achieve. AI changes this logic entirely.

When AI is embedded in the workflow, you can begin selling **outcomes delivered** not access to perhaps deliver them.

Outcome Mindset in the Market

This isn’t philosophy. It’s already showing up in how enterprise software gets priced.

Salesforce now talks about “Agentic Work Units” i.e. pricing tied to automated work executed, not seats provisioned. The buyer question is moving from “What features does it have?” to “Will this reliably get this job done for me?”

That second question cannot be answered by a feature. It requires a workflow.

Under the hood of every outcome is a workflow. Under the hood of every workflow, work happens.

Divide & Conquer – The Mechanics of Getting Work Done

The most common mistake in AI product strategy: treating a workflow as a single problem.

“Let’s add AI to our sales reporting.” Reasonable. Gets scoped, shipped. Eight percent usage. Because “generate monthly sales report” is not one step.

It’s a chain. Eight to ten links. Each with its own friction. Each with its own data richness. Each with its own owner. Most teams automate the final link. The first six links stay manual.

The sales report is rows seven and eight. The friction is in rows one through six.

AI on the output of a broken process produces faster broken outputs. AI inside the process i.e. in the steps where context is lost, where humans are slowest, where data is richest i.e. produces real outcomes.

Divide & Conquer as a Mental Model

Divide & Conquer: break a complex problem into independent sub-problems, solve each locally, combine. Classic algorithm design principle.

Applied to your product:

1 - Map the full workflow end-to-end. Every step the team actually runs i.e. not what your product assumes they run.

2 - Label each step: WORK (activity) or OUTCOME (result).

3 - Score steps on repetition, pain, data richness, time-sensitivity.

4 - Pick 2–3 high-friction WORK steps. Design AI there first.

On MCP: it’s the standard “hands” layer i.e. the mechanism by which a model executes steps in your system, calling tools, reading records, triggering actions. Essential infrastructure.

But hands without a brain do random work. The workflow map is the brain. The HUMINT is the brain. MCP is how you give it hands. Build the brain first.

Loving Pareto – Find the 20% of Workflow That Matters

Map the full workflow first. Then let Pareto tell you where to begin.

80% of delay, frustration, and errors in any workflow come from 20% of the steps. Find that 20%. Design your AI insertion points there.

The workarounds column is the most honest signal in the table. Not what customers say. What they actually do.

When customers export your data to process it somewhere else i.e. that’s the workflow telling you exactly where it’s failing them. Those Excel exports are a map. Follow them.

One Sharp Example @Freshworks documented a case where AI summarisation in customer support cut first-response time materially. The model wasn’t exceptional. The leverage came from removing one specific high-friction WORK step the manual reading and parsing of ticket history. Well we at ExtraaEdge using VidyaAI Summary are doing the same.

One step. Well-chosen. Measurable outcome. Real retention impact.One well-chosen step outperforms ten features designed in the abstract.

Bolt-On vs Workflow-Native : So where does AI Lives

This is the most important architectural decision you’ll make. Not the model. Not the stack. Not the infrastructure.

Where does the AI actually live, relative to the work?

Picture two versions of your product.

Version A — Bolt-On AI. The counselor opens a lead. She reviews the notes, qualifies the student, logs the call, decides on the next follow-up — all manually. Then, when she wants AI help, she opens a new tab. Pastes in context. Crafts a prompt. Reads the output. Comes back to the CRM. Executes the action herself.

The AI is a tool she uses. The work is still hers to carry.

Version B — Workflow-Native AI. The counselor opens the same lead. The qualification score is already there — generated from the call transcript and WhatsApp history. A draft follow-up is pre-filled, contextually aware, ready to edit. The next step is suggested based on where this student sits in the funnel.

She didn’t ask for any of it. It was already waiting. The AI is part of the work. Not adjacent to it.

Bolt-on AI adds a new cognitive task to an already loaded day.Workflow-native AI removes a step from the work the user was already doing.

These are fundamentally different product experiences. One adds friction. The other removes it. The 8% ghost feature? Bolt-on, almost always. The product your customers can’t imagine removing? Workflow-native, almost always.

Vertical AI – Companies That Got This Right

There’s no feature announcement in any of these rows.

Each one is a workflow redesign. The AI is the engine inside a process that was already real, already running, already valuable to the customer it serves. Every row is a company that started with workflow, then let AI become the engine.

Mental Models Cheat Sheet

These aren’t sequential. They’re concurrent lenses i.e. run them in parallel on the same workflow map.

HUMINT tells you which map to draw. Divide & Conquer is how you draw it.

Pareto tells you where to start. WORK vs OUTCOME tells you what you’re optimising for. Jobs-to-Be-Done keeps you honest about why. The Hook Model is how you build something that sticks. Progressive Delegation is how you earn the customer’s trust to let you go further.

The Metamorphosis of Ugly Duckling to White Swan

There are four kinds of AI.

AI we talk about is propaganda.

AI that solves a problem is useful.

AI we can build and defend is good.

AI that runs the workflow and delivers outcomes i.e. that customers can’t imagine removing & that’s the actual business.**

The ugly duckling of Workflow SaaS was always a swan. It contains the HUMINT no AI-native startup can replicate quickly. It knows the workflow. It knows the edge cases. It knows why the Excel export exists. It knows who skips which step and on which days.

Give it better hands.

Map the workflow. Label WORK vs OUTCOME. Run Pareto. Find the 2–3 steps where friction is highest and data is richest. Design workflow-native AI there — with MCP as the hands, your domain knowledge as the brain, outcomes as the only measure that matters.

Pick your most used, ugliest workflow. Decompose it. Label WORK vs OUTCOME. Run Pareto. Design workflow-native AI on the top 2–3 steps.

They’ll come for the AI. Stay for the Workflow & UI.

If you’re building in the middle, you’re not alone. Let’s figure this out together.

Abhi Ballabh is the co-founder and CEO of ExtraaEdge & VidyaAI the Intelligent Admission Growth Platform for the Education Industry, building through the AI transition from the trenches. Building in the Middle is his attempt to think out loud about what it takes to navigate platform shifts without losing your mind or your company.

Not All AI Is Created Equal

Let me give you a framework before we go anywhere else.

There are four types of AI being built right now. Most founders are building the wrong kind. I was a victim & maybe you are too.

Founders building from the middle should only settle for the fourth kind i.e. Type 4. Everything else is preparation. It may take time but that’s the only goal.

Most founders I talk to, see & observe are building Type 1, hoping it looks like Type 4. Some are building Type 2 which is honest & useful, but wondering why growth feels sluggish. Very few have found Type 4.

In all honesty, I think I am still at Type 2, i.e. AI that solves a problem, but navigating my way to move to Type 4.

The ones who have? They didn’t start with AI. They started with a question.

What is the single biggest moment of friction in my customer’s day?

In Post #1, I wrote about thinking clearly under extreme uncertainty about using OODA loops & mental models to make decisions when the SaaS playbook stops working.

In Post #2, I wrote about the founder upgrade about resetting your skill stack, changing how you show up, becoming the kind of CEO an AI-native company needs.

This post is about where you point all that energy. The answer isn’t in your roadmap. It’s in your customer’s day. Let’s dive in shall we !

Part 1: The Observer’s Mindset - What Mindfulness & the Stoics Taught Me About Customers

There’s a practice in mindfulness and the Stoics refined it into a discipline i.e. called detached observation.

The idea is simple: step back from your immediate reaction and observe it instead of becoming it. You don’t say “I am angry.” You say “I notice I am experiencing anger.”

That subtle distance between you and the experience is where clarity lives.

Marcus Aurelius didn’t just react to events. He watched his reactions to events. He trained himself to see thoughts the way you watch weather passing through, not defining you.

Neuroscience now confirms what the Stoics practiced. Mindfulness meditation builds meta-awareness: the ability to notice what your mind is doing, to refocus, to resist the pull of automatic response. Researchers call it a “neural brake” on impulsive decisions.

So what does this have to do with finding AI use cases? Everything.

Most founders approach their customers in one of two modes.

The pitcher: “Here’s what we built so do you like it?”

The interviewer: “What features do you want next?”

Both modes are broken. The pitcher hears validation. The interviewer hears opinions. Neither sees behaviour.

The observer mindset is different.

You sit with your customer’s day. You watch. You don’t pitch. You don’t ask for feedback yet. You don’t come in with an agenda. You just observe the workflow.

Rob Fitzpatrick wrote the manual on this. The Mom Test is three rules:

1. Talk about their life, not your idea.

2. Ask about specifics in the past, not opinions about the future.

3. Talk less. Listen more.

The corollary for AI discovery: when a customer says “We love AI,” don’t automatically believe them. Observe do they actually use the AI feature? How often? For what?

When a customer says “We don’t need AI,” don’t reject the signal. Observe, where are they spending three hours on something that could take three minutes?

Trust behaviour. Not beliefs.

What people do at 3 PM on a Tuesday is more honest than what they say in a 30-minute discovery call.

The Stoics trained themselves to treat impressions with what they called the “discipline of assent” i.e. don’t automatically approve or reject an impression, observe it first. Your customer’s feedback deserves the same discipline. Observe the weather. Don’t become the storm.

When was the last time you spent a full day watching how your customer actually uses your product not asking them about it, not demoing to them, just watching? The answer may be Never in last 6 months? Well get your s*#t together fast.

Part 2: Schrödinger’s Use Case — You Have to Lift the Hood (And Filter What You Find)

You know the thought experiment.

Schrödinger’s cat is sealed in a box i.e. both alive and dead simultaneously, in quantum superposition. Until you open the box and observe, both states are equally real.

Your customer’s best AI use case exists in exactly the same state. It is simultaneously valuable and worthless. A product-defining insight and a dead end. Until you open the box, you cannot know which.

The act of observation collapses possibility into reality.

You cannot discover the right AI feature by thinking about it in a conference room. You cannot find it in a customer satisfaction survey or a conference in Goa like some of our incumbent competitors do. You definitely cannot find it in your competitors’ product announcements.

You have to open the box. Lifting the hood looks like this in practice. It means watching session recordings, not just reading NPS scores.

It means sitting on 10 customer calls in a single week, not reading call summaries. It means shadowing a counselor during peak admission season. Watching what they alt-tab to. What they copy-paste. Where they pause. Where they sigh. The micro-moments of friction that never make it into a product request.

It means instrumenting your product so deeply that you can see every click, every hesitation, every drop-off.

Here are the tools that let you see inside the box:

Schrödinger’s insight was that observation changes the system. In product, observation changes the founder.

Once you’ve watched 50 session recordings really watched them, you cannot unsee what your users actually do. The gap between what they tell you in a call and what you see in those recordings is often the exact gap where your best AI use case lives.

Part 3: Signal vs. Noise — The Mom Test for AI Discovery

Here’s the uncomfortable truth about customer feedback.

Most of it is noise.

Customers report symptoms, not causes. “This feature is confusing” is noise. “I tried to do X but the system thought I wanted Y” is signal.

The loudest customer gets your attention. The most recent escalation gets your priority. Meanwhile, a quiet issue affecting hundreds of users one nobody escalates because they’ve just learned to work around it never surfaces at all.

Claude Shannon defined signal this way: information that reduces uncertainty. Everything else is noise.

Most customer feedback doesn’t reduce your uncertainty. It substitutes one opinion for your own.

Fitzpatrick’s three Mom Test rules, reframed for AI use case discovery:

Once you have raw observation, run it through this filter.

Not every customer problem is an AI problem. Here’s how to tell if it is:

1. Is it repetitive? AI thrives on pattern. One-off problems don’t qualify.

2. Is it data-rich? AI needs input to generate output. Vague problems produce vague results.

3. Is it time-sensitive? AI’s speed creates disproportionate value when timing matters.

4. Is the current solution actively painful, not just “good enough”? Only real pain drives adoption.

5. Would the user trust an AI to do this? Trust is adoption. Without it, nothing else matters.

Run every use case hypothesis through all five. If it passes, you have signal worth pursuing.

Part 4: What I/We Learned by Debugging Our Customer’s Day

This section is not a product case study. It’s a kinda messy debugging story.

ExtraaEdge has been in education admissions for over ~6+ years. 500+ institutions. Thousands of counselors. We’ve seen every version of the process i.e. the chaos, the hustle, the counselors juggling 10 apps to answer one question on a call.

When we decided to build AI, we didn’t ask: “How do we add AI to our product?”

We asked: “What is the single biggest moment of friction in our customer’s day?”

So we watched. We sat with counselors during peak admission season. We shadowed them. We watched session recordings.

Here’s what we observed that not what anyone told us:

Counselors were spending 60–70% of their time answering the same 50 questions. Eligibility. Fees. Deadlines. Documents. Same questions, dozens of times a day, every day of admission season.

Inquiry abandonment was running at 70%. Students dropping off at 11 PM because no one was there to answer. Every counselor on a call alt-tabbing between four screens just to respond to one question.

Nobody ever filed a support ticket about this. They just lived with it.

We didn’t start with “Let’s build an AI product.” We started with “Why are 70% of prospective students dropping off before they even talk to a counselor?” The observation was the question. VidyaAI was the start of an answer.

VidyaGPT lives in two places: on the college website as a student-facing assistant, and inside the CRM as a counselor co-pilot i.e. surfacing answers in real time so counselors stop alt-tabbing. VidyaWabaGPT extends this to WhatsApp, where Indian students actually are.

Are we Type 4 yet? Time will tell. We’re not claiming the user can’t imagine going back. What we know is we started with observation, not with a model, not with a roadmap item and built something that solves a problem we first had to see.

That’s the only honest way to begin. When observation meets execution, use cases that stick get built.

Part 5: Be the Whisperer & the Surveyor

Two roles. One observer.

The Whisperer is the ears of the buyer. They sit close. Listen for what’s unsaid the hesitation before an answer, the thing someone starts to say and then pulls back.

For founders: be present in buyer conversations, not reading deal summaries two days later. Tools like Granola or Wispr Flow aren’t just productivity tools used deliberately, they become observation instruments. Record your own calls. Run them through AI. Across 50 transcripts, the recurring signals become impossible to ignore.

The Surveyor is the eyes on the end user. They map terrain before building. They don’t assume the ground is flat.

For founders: instrument your product obsessively — Clarity, PostHog, Mixpanel — and read the data with a beginner’s mind. No agenda. No hypothesis to confirm. Just see what’s there.

The most powerful AI use cases emerge from behaviors users never report. The silent friction. The workaround so ingrained they’ve forgotten it’s a workaround.

That’s the signal. One tells you what to build. The other tells you where it fits.

Part 6: Forward-Deployed Engineers — Your Reconnaissance Soldiers

Palantir built something that most SaaS companies have never even considered.

They called them Forward Deployed Engineers i.e. FDEs. Software engineers embedded directly inside customer organizations, working on-site, solving the customer’s most pressing problems in real time.

At one point, Palantir had more FDEs than traditional software engineers.

The FDE’s mandate was not “implement our software.” It was: understand the exact details of the customer’s problem, get the data, build a solution, demo it on-site, and find the smallest unit that creates end-to-end value.

Think about that model for a moment.

In the military, reconnaissance soldiers don’t fight the main battle. They go ahead of the army. They observe terrain. They report enemy positions. They assess conditions. They see before the army moves.

FDEs are your recon soldiers.They go into the customer’s world. They watch. They observe. They build light. They come back with intelligence the core team could never get from a conference room.

At Palantir, FDEs work alongside Deployment Strategists — people who bridge the gap between technical capability and operational priority. That’s your product person. The FDE sees the use case. The product person translates it into something buildable & defensible.

The companies that figured this out early are winning entire categories.

The pattern is identical across all . They didn’t start with a model. They started with an observation.

Part 7: The POC Is the New Product-Market Fit Test

In SaaS, you could build a feature, ship it, and measure adoption over quarters.

In AI, that timeline doesn’t work.

The proof-of-concept is the moment of truth. Not the roadmap item. Not the sprint. The POC i.e. built in days, put in the customer’s hands immediately — is where you find out whether the use case is real.

Can the agent actually do the job? Does the customer trust it?

Does it save real time i.e. not theoretical time, but actual, measurable, felt-in-the-workday time?

The FDE runs this loop:

Observe → Hypothesize → Build POC (days, not months) → Put in customer’s hands → Watch what happens → Iterate or kill.

This is the OODA loop from Post #1, applied to product discovery. Orient, Observe, Decide, Act i.e. but now it’s the loop your field engineers run with customers, not just the loop you run in your own head.

The speed of this cycle is your real competitive advantage i.e. not your model, not your data, not your funding.

Bret Taylor put it clearly: “We think outcome-based pricing is the future of software. With AI, we finally have technology that isn’t just making us more productive — but actually doing the job.”

When a POC proves that the AI can do the job, you have your immediate business opportunity.

A proven unit of value, demonstrated in the customer’s own workflow. That’s the only Type 4 AI worth building.

Part 8: The Observer’s Debugging Kit — A Checklist

Print this. Put it somewhere you’ll see it. I have done it & still trying to build a discpline around the same.

The Weekly Observer Practice

• [ ] Spend 2 hours watching session recordings (Clarity/PostHog) with no agenda just observe

• [ ] Sit on 3 live customer calls as a silent observer i.e. not as presenter, not as seller

• [ ] Shadow one end user for a half-day: literally watch them work

• [ ] Review the top 10 support tickets this week i.e. what’s the recurring pattern?

• [ ] Ask one customer: “Walk me through your last Tuesday, 9 AM to 6 PM”

• [ ] Run one Mom Test conversation: talk about their life, not your product

• [ ] Log observations in a “Debug Diary” — date, what you saw, what surprised you

The Monthly Signal Review

• [ ] Pick ONE use case. Build a POC with your FDE team within 2 weeks.

• [ ] Test it with 3 customers. Watch, don’t ask & if they use it again tomorrow.

The Quarterly Reflection

• [ ] Which POC became a product? Which died? Why?

• [ ] What did you learn about your customers in the last 90 days that you didn’t know before?

• [ ] Are you still observing or have you slipped back into pitching?

The Only Viable Path

Let me bring it home.

AI that founders talk about on stage is mostly propaganda. AI that solves a customer’s problem is useful and underrated. AI that you can build & defend is strategic.

But AI that sells, gets used, and becomes part of your user’s life i.e. that’s the only immediate business opportunity worth your time as a builder from the middle.

The competitive advantage isn’t the model. It isn’t even the data. It’s the depth of observation that leads you to the right use case before anyone else finds it.

Intercom with FinAI didn’t win because they had better AI. They won because they understood —before anyone else acted on it that 80% of support queries were repetitive & pattern-matchable.

Palantir didn’t win because of Foundry. They won because FDEs sat inside customer workflows and surfaced problems that customers themselves couldn’t articulate.

In Vipassana, the instruction is elegantly simple: observe. Don’t react. Don’t judge. Don’t intervene. Just observe.

The clarity that follows isn’t intellectual it’s experiential. It comes from contact with reality, not with your assumptions about reality.

Building AI products is the same.

The founders who win aren’t the ones with the best pitch decks or the most sophisticated models. They’re the permanent debuggers of their customer’s day.

They observe without agenda. They trust behaviour over belief. They collapse Schrödinger’s use case by opening the box. The only way to find potent AI use cases is to literally become your user and live their day.

Stop pitching AI. Start debugging your customer’s day. The signal is there. You just have to be quiet enough to hear it. The Stoics will agree anyday.

If you’re building in the middle, you’re not alone. Let’s figure this out together.

Abhi Ballabh is the co-founder and CEO of ExtraaEdge & VidyaAI the Intelligent Admission Growth Platform for the Education Industry, building through the AI transition from the trenches. Building in the Middle is his attempt to think out loud about what it takes to navigate platform shifts without losing your mind or your company.

The question nobody prepares you for

You’ve built a company. Revenue. Team. Customers who trust you. A product that works. And then the ground shifts and you realize the founder your company needs next is not the founder you are today.

In [my last post], I wrote about thinking clearly when your SaaS playbook disintegrates. The fog. The uncertainty. The models that break.

Founders reached out after. Not about frameworks. About fear. The question underneath every conversation:

Am I still the right person to lead this company through what comes next?

That question haunts me too.

In 1985, Andy Grove faced it at Intel. He asked Gordon Moore: “If we got kicked out and the board brought in a new CEO, what would he do?” Moore said, “Get us out of memories.” Grove: “Why don’t we walk out the door, come back, and do it ourselves?”

Fire yourself mentally. Re-enter as an outsider. Rebuild from truth.

Grove’s question took courage. Not physical courage the courage to look at what you’ve built and admit it’s not enough for what comes next.

The SaaS-to-AI shift is not a product update. It’s what Grove called a Strategic Inflection Point. The technology changes first. But the leader’s operating system determines survival.

Peacetime Is Over

The military gets this intuitively. Different wars demand different leaders.

Ben Horowitz named the business version i.e. Wartime CEO vs Peacetime CEO

Horowitz: wartime is about “a very accurate decision extremely quickly” and sometimes this “undermines the development of the organization because there’s more burden on the CEO.”

Colonel John Boyd’s OODA loop which I wrote in my past post i.e. Observe, Orient, Decide, Act explains the deeper mechanism. The side that cycles faster wins. But the *Orient* phase is everything. That’s where your old mental models either accelerate you or trap you.

The SaaS decade trained us to be peacetime operators. Optimize. Delegate. Scale headcount. The AI era needs the wartime version: hard calls fast, close to the metal, zero distance between strategy and execution.

As Grove wrote: ”When a Strategic Inflection Point hits, the ordinary rules of business go out the window.”

The New Math - Revenue per employee is the new headcount

For a decade, headcount signalled credibility. “We’re 500 people” meant you’d arrived. Today, unfortunately, it signals drag.

10–20x efficiency gap. Not incremental. A different species of company.

Klarna proved this at scale: 5,527 employees → ~2,900 through attrition. How?

AI chatbot replacing 800 agents. 1,200 SaaS tools eliminated. Revenue up 108%. Average pay up 60%.

Fewer people. Higher paid. More leveraged.

Every Relationship of the Founder Must Change

When your team collapses from 200 to 40, every relationship the founder operates within must be rebuilt.

**Co-founders → Learning Partner**

You can’t just divide and conquer. In SaaS, you ran parallel silos for months. In AI, the landscape shifts weekly. You need weekly mental model syncs not standups, but

what did we learn this week that changes our assumptions?

Boyd called it shared consciousness. The team moves fast because they share an orientation, not a Slack channel.

**Investors → Long term thinkers**

Who treat AI startups like SaaS linear MRR expectations, panic at flat quarters can & will destroy you faster than any competitor.

The best AI-era investors open enterprise doors and stay calm during the messy middle.

Choose them the way the military chooses allies: shared objective, complementary capabilities, long commitment.

**Your Board → Pattern Recognition Engines**

Siemiatkowski the CEO kept Klarna’s board aligned during radical restructuring by framing around revenue per employee, not just cost cuts.

They needs to understand leverage, not logos.

Frame conversations around velocity, speed with direction & not vanity metrics.

**Every employee → P/L Owners**

They all are load-bearing. Captain Shashank Shandilya, who led counter-insurgency ops in Kashmir, put it plainly:

“It is only when you are unprepared that you blame your problems on uncertainty.”

In small teams with Forward Deployed Engineers (read CSM of AI era), you know every person’s name and their problems. You clear the path so they fight the war.

**Customers → Perpetual Design Partners**

The deepest shift. In AI, the product gets smarter with usage. Customers aren’t buying software anymore. They’re training your system. Palantir understood this first with Forward Deployed Engineers.

Bob McGrew an early exec at Palantir said it “FDEs focus on enabling many capabilities for a single customer.”

You’re not installing software. You’re tuning intelligence. In summary below table -

Rewiring the Founder’s Mind

We upgrade tech stacks and go-to-market. The most neglected hardware & software upgrade is the founder’s own cognitive operating system.

The firmware upgrades I’ve been forcing on myself:

Feature Thinking → Outcome Thinking → Stop shipping features. Price outcomes. You’re selling work done, not seats.

Linear Planning → OODA-Speed Iteration → Kill the annual roadmap. Ship weekly. Prototype aggressively. Boyd: the side that cycles faster wins.

Delegation → Technical Literacy. → My CTO handles the tech, that’s peacetime luxury. F*&# you!! In wartime, the founder understands token economics, inference costs, eval loops. Not to build. To judge tradeoffs. As Horowitz says i.e. accuracy matters so much the CEO decides directly.

Hiring for Coverage → Designing for Leverage → One engineer + AI agents = output of ten. Cursor’s engineers manage fleets of five coding agents each. Stop scaling via people.

Implementation → Forward-Deployed Intelligence → You’re not installing software. Engineers at customer sites, prototyping in real-time. Tuning intelligence at the edge.

Quality Assurance → Sharp Evals → You’re not doing feature testing & use case coverage. Nope. You are looking at Precision, Accuracy, Recall & F1 Score. Time to start learning & teaching teams how Agents & AI gets better.

Stability-Seeking → Productive Paranoia → As Andy Grove says, Only the paranoid survive. A model upgrade can obsolete your feature overnight. Hunt for inflection points especially when things feel stable.

What I Had to Unlearn & still unlearning

The hardest part hasn’t been learning new skills. It’s been releasing the ones that got me here.

I held onto team structures that made me comfortable. I delegated decisions that needed my direct judgment because I thought that’s what scaling looked like. I ran peacetime plays in wartime conditions.

When discipline meets courage, the courage to abandon what worked is something hard but also therapeutic. Not just in the company. In the founder.

The company with VidyaAI that I’m building today is not the company I started. And the founder it needs is not the founder I was.

The army doesn’t send the same officer to every war. The mission changes. The terrain changes. The enemy changes. So the leader must change not their values, but their operating system.

The Truth, mostly brutal

AI doesn’t just compress teams. It compresses excuses.

The question is not whether your product or company is AI-first. It’s whether you are.

In words of the great legendary rapper 50 Cent, Get Rich or Die Tryin' the same voice echoes in my mind.

Upgrade or get upgraded.

If you’re building in the middle, you’re not alone. Let’s figure this out together.

Abhi Ballabh is the co-founder and CEO of ExtraaEdge & VidyaAI the Intelligent Admission Growth Platform for the Education Industry, building through the AI transition from the trenches. Building in the Middle is his attempt to think out loud about what it takes to navigate platform shifts without losing your mind or your company.

Who This Is For and Why Now

Let me paint a picture.

You have Rs XX Cr ($X M) ARR. A 40-person team. Solid retention numbers. Customers who trust you. A product that works.

Then your seed investor asks in the quarterly call: “So, when’s the AI pivot happening?”

Your engineering lead wants to rebuild everything on agents. Your sales team says customers don’t understand AI & tokens. Your burn rate gives you 6 months of runway. Every decision feels existential, & unfortunately, you & your co-founder were not born in the AI Native Era. Bad Timing :)

Welcome to Building in the Middle.

This is the reality for thousands of founders right now. You have working revenue, stable customers, and a team that knows the playbook. But the board/investors keeps asking, “What’s your AI story?” Technology shifts faster than your planning cycles can accommodate. Competitors are rebuilding from first principles while you’re patching features onto legacy systems.

Your team is split down the middle. Half want to defend the core business. Half want to chase the AI future. Both are right. Both are wrong.

Here’s what I’ve learned building ExtraaEdge through this exact transition: In this environment, the real competitive edge isn’t data, models, or capital.

It’s clear thinking under extreme uncertainty at the founding team level.

Shane Parrish puts it simply: “The greatest aid to judgment is starting from a good position.”

Indian founders now sit just 6 to 12 months behind Silicon Valley in the AI race. Not a decade, like the SaaS era. This compression makes clear thinking more critical than ever. The window for course correction is shorter. The stakes are higher. The playbook is being written in real time.

This is not a playbook with answers. It’s a 4 part framework for thinking when there are no answers yet.

Part 1. What Do We Mean by “Uncertainty”?

Let’s ground this word before we go further. Because “uncertainty” can feel like a vague monster. Something that haunts your Sunday evenings but never takes a clear shape.

It’s not. It’s actually quite workable once you understand its structure.

Three Regimes of Decision-Making

Certainty is when cause and effect are stable. Outcomes are predictable. Think of mature SaaS unit economics at scale. You know that if you spend X on acquisition, you’ll get Y customers with Z lifetime value. The math works.

Risk is when outcomes are uncertain, but the possibilities and probabilities are known. You can model CAC variance, churn bands, and A/B test results. You don’t know exactly what will happen, but you can assign probabilities to different outcomes.

Uncertainty is different. You don’t know all possible outcomes. You can’t assign meaningful probabilities. The future contains scenarios you haven’t even imagined yet.

Most of what AI-era founders face falls into this third category i.e. Extreme Uncertainty

Consider: Will India’s Digital Personal Data Protection Act reshape AI product development? Will GPT-5 cost 10x or 0.1x what GPT-4 costs today? Will open source models catch up to closed ones? How will customer expectations evolve when everyone has access to the same foundation models?

These aren’t risk questions. They’re uncertainty questions. And they require different tools.

The Rumsfeld Matrix: Four Modes of Uncertainty

Donald Rumsfeld caught flak for his “known unknowns” framework, but it remains one of the most useful mental models for navigating uncertainty.

Here’s the uncomfortable truth: Most startup tools were designed for risk, not uncertainty.

OKRs assume you can set measurable objectives. Budgets assume you can forecast spend against outcomes. Roadmaps assume you can sequence work toward a known destination.

In the SaaS era, you could model CAC payback periods, LTV curves, and retention cohorts. The math was hard but knowable.

In the AI era, the model layer changes monthly. Customer use cases are still emerging. Value capture mechanisms remain unclear. “Should you build on OpenAI, Anthropic, or open source?” isn’t a risk question with calculable probabilities. It’s an uncertainty question where the possible states keep shifting.

A prompt for you: Take 60 seconds right now. Which decisions in your company are still in “risk” territory, where you can model probabilities? And which have moved into true “uncertainty” territory, where you cannot assign meaningful probabilities? Write down 3 of each.

The key insight here is that recognizing the type of uncertainty changes how you think. Known unknowns demand research and experiments. Unknown unknowns demand resilience and optionality. Unknown knowns demand reflection and the courage to challenge your own assumptions.

Part 2. The Struggle: What Founders Face under extreme uncertainty

Ben Horowitz wrote about “The Struggle” years ago, but it hits different when you’re living through a platform shift.

The Struggle is not an exception. It’s the norm when business models and technology shift simultaneously.

“The Struggle is not failure, but it causes failure. Especially if you are weak.”

What The Struggle Looks Like Today

The Struggle is when your best engineer says “We should rebuild everything as agents” but you have paying customers on the current product who didn’t ask for agents.

The Struggle is when employees think you’re lying about the AI roadmap. And you think they may be right.

The Struggle is when VCs ask about your moat, and you realize that data and workflows, the things that protected you in SaaS, might not matter anymore when every competitor has access to the same foundation models.

The Struggle is when food loses its taste because you’re calculating burn rate against AI development timelines in your head during dinner.

Horowitz nailed this feeling: “The Struggle is when you don’t believe you should be CEO of your company. The Struggle is when you know that you are in over your head and you know that you cannot be replaced.”

Why This Is Different from Normal Startup Hard

Normal startup hard is product-market fit. Hiring. Fundraising. These are known unknowns. Hard, but mappable.

AI transition hard is when the playbook itself becomes uncertain.

Do you charge per seat or per outcome? Do you build a copilot that assists humans or an autonomous agent that replaces workflows? Do you sell productivity improvements or business transformation? Is your edge the model, the data, the workflow, or the distribution?

These aren’t just hard questions. They’re questions where the right answer might change quarterly.

The Psychological Dimension

Research on decision-making under uncertainty shows consistent patterns. Decision fatigue compounds when every choice feels consequential. Cognitive load spikes when your mental models from SaaS don’t transfer cleanly. Imposter syndrome whispers: “Am I even technical enough for the AI era?”

Analysis paralysis sets in because every decision feels irreversible.

But here’s what I find useful: Studies of emergency medicine physicians show that experienced doctors use uncertainty as a trigger to focus cognitive resources, not as a signal to freeze. They’ve trained themselves to recognize uncertainty and lean into it rather than away from it.

That’s learnable. That’s the craft.

Horowitz’s Survival Strategies, Adapted for AI Founders

1. Don’t Put It All On Your Shoulders

Share the uncertainty with your founding team, advisors, even select customers. Horowitz’s advice: “Get maximum brains on problems even if problems represent existential threats.”

Build a kitchen cabinet of 3 to 5 people who’ve navigated platform shifts before. Not mentors who give generic advice. People who’ve felt this specific weight.

2. This Is Chess, Not Checkers

“There is always a move.”

When you think you’re stuck between “rebuild everything” and “keep iterating on legacy,” there’s almost always a third option. A hybrid architecture where new features run as microservices on AI while the legacy system continues serving current customers. A parallel track that doesn’t bet the company.

The move exists. Your job is to find it.

3. Play Long Enough to Get Lucky

“Tomorrow looks nothing like today.”

In 18 months, model costs may drop 90%. New monetization models will emerge. Regulations will clarify. Customer expectations will stabilize into patterns you can design for.

Your job isn’t to have all the answers now. Your job is to survive with optionality intact.

4. Don’t Take It Personally

You made decisions with the information you had. Self-evaluation that grades yourself an “F” doesn’t help anyone.

Horowitz reminds us: Both the hero and the coward feel the same fear. The difference is action.

The Struggle is real. It’s also where every great company is forged.

The question isn’t “How do I avoid The Struggle?” The question is “How do I think clearly within The Struggle?”

Part 3. How Others Think Clearly Under Extreme Uncertainty

Clear thinking under uncertainty isn’t a personality trait. It’s a skill. And some domains have been developing this skill under life-and-death pressure for decades.

Military Decision-Making: The OODA Loop

John Boyd was a fighter pilot who later became one of the most influential military strategists of the 20th century. His framework, developed for pilots making life-or-death decisions in seconds, has lessons for every founder navigating uncertainty.

OODA stands for:

• Observe: Gather information from your environment. Market signals, customer feedback, technology landscape, competitive moves.

• Orient: Analyze what you’ve observed in context of your mental models, experience, and culture. This is where most founders get stuck, using SaaS mental models for AI decisions.

• Decide: Choose a course of action as a hypothesis, not as certainty. This framing matters.

• Act: Execute, then gather feedback that becomes input for the next cycle.

Three insights for founders:

First, speed through the loop beats speed of individual decisions.

Boyd’s insight wasn’t about making faster decisions. It was about completing more decision cycles than your opponent. The founder who ships an AI feature, learns from usage, and iterates weekly will beat the founder who spends six months perfecting before launch.

“The leader who moves through the OODA cycle quickest gains advantage by disrupting the enemy’s decision-making.”

Second, the framework assumes incomplete information.

Boyd designed OODA for situations where you’d never have complete information. That’s the whole point. Train yourself to decide with 60 to 70 percent confidence, then learn fast. Military training deliberately bombards leaders with contradicting information and forces decisions without complete data. Because that’s reality.

Third, the loop has evolved.

Modern military thinking has added nuance. Discovery (enhanced observation). Design (strategic planning with complexity awareness). Decide (hypothesis with explicit risk consideration). Disseminate and Monitor (communication plus continuous assessment).

How to apply this:

Set trip wires. “If our AI feature doesn’t hit X usage in 90 days, we pivot to approach B.” This removes the emotional weight of the decision in the moment.

Use commander’s intent. “Our goal is autonomous workflows for customer success teams. How you get there is flexible.” This empowers your team to make decisions without escalating everything.

Run weekly decision reviews. What did we learn? What hypothesis did we test? What do we believe differently now?

Emergency Medicine: Thinking Clearly in Trauma

Emergency department physicians make high-stakes decisions with incomplete information, time pressure, and lives on the line. Every shift. Their profession has studied how to do this well.

Two strategies that transfer:

Pattern recognition plus staying open.

Experienced physicians use pattern matching for rapid initial assessment. They’ve seen enough cases that certain combinations of symptoms trigger immediate hypotheses.

But here’s what separates good from great: they actively remain open to alternative hypotheses as new data emerges. They hold their initial read loosely. They update when the evidence demands it.

For founders, this means: Use your SaaS pattern recognition to generate hypotheses about AI strategy. But hold them loosely. Update aggressively when customer behavior tells you something different.

Explicit uncertainty acknowledgment.

Emergency medicine has developed formal protocols for acknowledging uncertainty out loud. “I’m not sure if this is X or Y, so we’re going to monitor for these specific signals.”

This isn’t weakness. It’s clarity. It focuses the team on what to watch for. It creates shared understanding of the decision landscape.

Try this in your next strategy discussion: “I’m 60 percent confident in this direction, and here’s what would change my mind.” Watch how it shifts the quality of the conversation.

Part 4 - Where We Go From Here

Building in the middle is exactly as hard as it sounds.

You’re not a fresh startup that can pivot without consequence. You’re not an incumbent with years of runway and diversified bets. You have customers counting on you, a team that joined for a specific mission, and investors expecting a specific outcome.

And the ground beneath all of it keeps shifting.

But here’s what I’ve come to believe: The founders who thrive through platform shifts aren’t the ones who predict the future correctly. They’re the ones who build the capacity to think clearly when prediction fails.

That means understanding what kind of uncertainty you’re actually facing. It means accepting The Struggle as the territory, not as a sign you’re doing it wrong. It means learning from domains that have practiced high-stakes decision-making under uncertainty for generations.

The tools exist. The frameworks exist. The path through exists.

This is the first piece in a series. We’ll go deeper on specific frameworks, share stories from founders navigating this transition, and build a practical toolkit for thinking clearly when the map keeps changing. And changing faster than we have ever seen!

If you’re building in the middle, you’re not alone. Let’s figure this out together.

Abhi Ballabh is the co-founder and CEO of ExtraaEdge & VidyaAI the Intelligent Admission Growth Platform for the Education Industry, building through the AI transition from the trenches. Building in the Middle is his attempt to think out loud about what it takes to navigate platform shifts without losing your mind or your company.