A PM I’ve known for a couple of years called me in the spring. New offshore vendor, new start. “This team is better,” he said. “More senior. Faster to respond.”
By month four, the project had stalled in exactly the same place as the one before it. Same requirements gap. Same decision bottleneck. Same confusion about who owned the outcome when something broke.
Different vendor. Same environment.
When we finally spoke, I didn’t try to fix the vendor. I asked him to describe what “done” looked like for the feature they’d been building for eight weeks. He paused long enough for both of us to understand what that meant.
You Changed Vendors. The Problem Came With You.
I’m not saying offshore vendors don’t vary — they do, in skill, in communication style, in how they handle ambiguity under pressure. But in my experience, the ceiling on a vendor’s performance is usually set by the client’s own structure, not the vendor’s capability.
When I ask a client to describe what “done” looks like for a specific feature, I usually get a slide title. When I ask who approves it, I get a team name. When I ask what happens if it ships wrong, I get silence. That’s what sets the ceiling — not which team you hired.
This was already true before AI tools entered the picture. With AI-native development, it becomes more visible — because AI amplifies whatever environment it’s working inside.
AI Runs Fast. But Only on Solid Ground.
Here’s what I’ve seen when AI-native development is working at its best: a task that used to take 50 hours gets done in 2. That compression is real. I’ve watched it happen more than once.
But that speed assumes a few things. The spec is written clearly enough for AI to act on it without constant clarification. The data is accessible without three approval layers between the developer and the thing they need. Someone is accountable — genuinely, personally accountable — when the output goes wrong.
Take any of those away, and you don’t get a slower version of AI-native development. You get a fast-moving project accelerating in the wrong direction.
If a project needs a hero to keep it on track, the system isn’t strong enough yet.
The same logic applies here. If your organization depends on finding a vendor who “just gets it” without structured specs, fast decisions, and clear ownership — that dependency doesn’t go away by changing the vendor.
The 5 Questions I Ask Before We Start
When a company approaches us about working together, I walk through these five questions before we discuss scope, budget, or timeline. Not as a test — as a diagnostic. The answers tell me more about whether a project will succeed than any technical requirements document.
They’re also the questions I’ve most often seen go unanswered in projects that stall.
1. Can you put your requirements into words?
Not slides. Not “something like what Notion does.” Words — specific enough that two developers with no context would independently build the same thing.
AI works inside language. If the spec is directional rather than specific, AI speeds up building the wrong thing.
Something I ask in early conversations: can you send me a requirement you’ve written recently? Not a complete spec — just one feature, described in enough detail that someone could build it without asking follow-up questions. The answer tells me more about readiness than an hour-long kickoff call.
I’m not looking for perfect documentation. I’m looking for the habit of writing things down before building them.
2. Is your data in a state AI can actually use?
It doesn’t need to be clean or perfectly structured. But it needs to be findable, labeled at some basic level, and accessible to the people building with it — without a multi-step approval process every time a developer asks a question.
If your team has to manually compile data each time something comes up in development, AI can’t compress the feedback loop that matters. You end up with fast code and slow inputs. The bottleneck moves upstream.
3. Can your organization make decisions at AI’s pace?
I see this pattern often. A developer submits 10 clarifying questions on Monday. The client responds by Thursday with answers to 3. Over time, the developer stops asking — they start guessing instead.
At that cadence, AI’s speed advantage becomes a liability. The pipeline fills. The team idles. Costs accumulate while the decision queue drains slowly.
On projects where decision-making actually works, I’ve noticed the same pattern: there’s one specific person — not a committee, not “leadership” — who responds to blocking questions within the same working day. In one project, we created a dedicated thread just for blocking questions. Nothing else went in that thread. We named one person responsible for it. The pace of the project changed within a week. Not because of the tool — because naming the person changed who felt responsible.
4. Is someone clearly accountable for the output?
This one surprises people. As AI generates more of the code, ownership tends to blur. “The AI wrote it” becomes a kind of answer — and it points to no one.
What I’m looking for is a person — not a team, not a title — who will step up when something ships broken.
The clearest case I’ve dealt with directly: a client’s internal tool launched with a bug affecting roughly 40% of daily active users. The vendor had flagged the risk two weeks before launch. The AI had written most of the code. For three days after the bug surfaced, everyone had a reason it wasn’t their call. Nobody was hiding anything. There just wasn’t one person whose job it was to care enough to catch it first.
That’s the gap I’m trying to identify before we start, not after.
5. When something breaks, does it make you better?
Every project has failures. The question is what happens after.
The teams I’ve worked with that handle this well share one habit: they keep a short failure log — what broke, what caused it, what changed as a result. It doesn’t have to be sophisticated. A shared doc with three columns is enough.
One client started doing this after their third consecutive bug in the same module. The fourth bug never came, because the pattern showed up clearly in the log before anyone else had noticed it.
Teams that treat failures as noise accumulate technical debt faster. With AI in the loop, that debt accumulates at AI speed.
This question isn’t really about process. It’s about whether your organization learns.
If Some Answers Were Unclear — That’s Actually Useful
Most companies I talk to don’t have all five in place. That’s expected — especially if you’re moving from traditional offshore development to AI-native for the first time.
What I’m looking for isn’t perfection. I’m looking for awareness. A team that knows which questions they can’t answer clearly is already ahead of one that assumes they can.
If you went through these five and hit some grey areas, that’s a useful output. It tells you where to focus before bringing in any external team — including ours.
If you want to talk through what you found, I’m happy to. Usually 15 minutes is enough to identify where the real gaps are and what to focus on first. No preparation needed — just bring your honest answers to the five questions above.
Not sure which question you stumbled on? Let’s find out together.
15 minutes is usually enough to identify where the real gaps are and what to focus on first.
Book 15 minutes →Related: What AI-Native Offshore Development Actually Looks Like
Frequently Asked Questions
Where do we start if our team isn’t AI-ready yet?
Start with the first question: can your team write clear requirements? That’s the highest-leverage starting point. Documentation habits — writing specs before building, logging decisions — tend to unlock the other four naturally over time. You don’t have to fix everything at once.
How much faster is AI-native offshore development, actually?
In the right environment, individual tasks that used to take 50 hours can compress to 2. For a project overall, the number depends heavily on how structured your inputs are. With clear specs and fast decision-making, the speedup is real and compounds over the course of a project.
What if we know we’re not ready yet — is there still a conversation worth having?
Yes. Knowing you’re not ready is more useful than thinking you are when you aren’t. A 15-minute call is usually enough to identify the one or two things that would make the biggest difference before you bring on any external team.
Shogo Harada原田 祥吾
CEO · Linnoedge Inc. · LinkedIn↗
Operating IT offshore development and overseas expansion support businesses across two bases: Tokyo and Vietnam. A leader who believes in “Systems over Spirit,” structuring cross-border businesses that often tend to be opaque. Committed to providing “reproducible quality” to organizations and clients rather than relying solely on individual skills.