We stopped writing specifications. This is the story of why.
Hi — I’m Shogo Harada, CEO of Linnoedge, writing from Ho Chi Minh City.
Let me start with a question. Writing specs — doesn’t it wear you out?
“When the user taps this button, the screen moves here, and the data gets processed like this…”
You already have a clear picture in your head. But to get it across to a development company, you produce document after document. Days disappear into it. Sometimes weeks.
And then, after all that effort, the thing that comes back makes you go quiet.
“…No. That’s not what I meant.”
In moments like that, hasn’t this thought crossed your mind? “If only ‘just make it work nicely’ were enough.”
Everyone says the same thing: never hand it over blindly
Search for “why outsourced software projects fail.” Most articles land on the same answer.
Unclear requirements. The client didn’t write a proper spec. The client has to stay involved.
Fair enough. I’ve watched projects burn for exactly that reason. And I’ll admit it — for years, I was the one saying “please send us your specification.” Without one, we were the side left guessing.
But something about that answer never sat right with me.
Think about your regular restaurant — the place where you sit down and say “whatever you think is good today.” Looked at coldly, that’s a complete hand-off. And yet it doesn’t fail. Most nights it beats anything you would have ordered yourself.
So the problem was never the handing over. The problem is whether the other side holds your context.
Say “chef’s choice” at a first-visit restaurant that doesn’t know what you can’t eat or how you like things cooked — that night goes badly. Which is why I read “never hand it over blindly” as something more precise: never hand it over to someone who doesn’t have your context.
One more detail worth noticing. The good restaurants ask first: “Anything you don’t eat?” That’s a professional going out to get context. Hold that thought — it comes back at the end.
The spec, the code, and the prototype all said different things
Before I go further on context, let me tell you what happened when we trusted documents too much.
One of our ongoing projects is a childcare support app. At some point we looked up and realized the spec, the source code, and the prototype were each saying something slightly different.
Nobody slacked off. The spec got revised, the code moved forward, the prototype ran ahead. On a live project, documents and reality drift apart on their own if you leave them alone. And then nobody can tell which one is correct anymore.
Talking it through with our dev lead, one sentence came out of that conversation:
“If the requirements are wrong, a hundred hours of development are worth nothing.”
That line changed how we work. We stopped sending a spec of nearly a hundred pages with “please confirm everything.” Instead, one question at a time: “This screen, this behavior — like this, right?”
Sounds slower, doesn’t it? It turned out to be the fastest thing we ever did. At the very least, one thing was real: with every answer, the next question got smaller.
Here’s the truth about a 100-page approval: nobody reads all of it. They can’t — they have a business to run. But a single question? Anyone can answer that on the spot. And every answer the team collects is one more piece of your context they now hold.
Context doesn’t travel through instructions
So how does context actually get shared?
The first time that question hit me was in 2012, right after I arrived in Ho Chi Minh City. On a project for a major Japanese manufacturer, I passed a QA comment to a Vietnamese engineer: “This is off by one pixel.” He looked at me, completely serious, and asked:
“Why do Japanese people care about that?”
I had no answer. Back in Japan, I had called that “quality” and never once questioned it. Who would use this screen, what standard the client judged by — I was the only one who knew, and I had never put any of it into words for the team.
After that, I stopped giving one-way instructions. I started bringing problems instead: “What do you think we should do?”
And the six people who had been working as disconnected individuals became a team. They started catching things before being told. I wrote about those early days in another article.
One more thing. The engineer who asked me the one-pixel question? He’s our CTO now. And the way we work hasn’t changed.
Why a dedicated team stops needing specs
“Before next month’s campaign, make that input screen fast and smooth.” Six months into working with the same team, sentences like that start being enough. The same people keep hearing your numbers and your circumstances, so the context accumulates.
That’s the real reason we run a dedicated-team (lab) model. It was never about the hourly rate.
I’ll be straight about the limits, though. A dedicated team isn’t magic. Absorbing your context takes time, and it takes conversation — not silence from your side. Nobody reads your mind on day two of the contract. I’d rather you know that going in.
Show something that moves, before anything written
Even so, misunderstandings happen. We’re human.
So before development starts, we now build a moving mockup with AI and put it in front of the client. The point is speed. AI has reached the point where a screen mockup can be produced during the meeting itself.
“Something like this?”
“Hmm — can this part be bigger?”
“How about now?”
“Yes. That’s it. That’s the one.”
That whole exchange finishes before a single line of code is written. A hundred rounds of written confirmation become one conversation around a moving screen.
I can’t give you an impressive number here — “rework down X percent” — because we haven’t measured it properly. What I can tell you is that the most painful sentence in this business, the “…that’s not what I meant” that arrives after everything is built, stopped happening. All we changed was the order: from “build, then show” to “show, then build.”
Related reading
- What software development in Vietnam actually costs in 2026
- Why offshore development fails — and how to de-risk vendor selection
Curious how we actually run projects? Start with our services overview.
Just bring what’s bugging you — we’ll go get the context
This ran long. Thank you for staying with me.
If you’re staring at a stalled project right now, or at a requirements phase that hasn’t even started, here’s the one thing I’d want you to walk away with:
You don’t have to figure everything out alone before you talk to anyone.
A perfect document matters less to us than the raw version of “I want this to stop being painful.” Collecting the context is our job — one question at a time, the same way that restaurant asks “anything you don’t eat?”
It doesn’t have to start as a business conversation, either. “Something about our systems has been bugging me” is a perfectly good opening line.
And if you ever find yourself in Ho Chi Minh City, tell me. I’ll take you to OKRA FoodBar, my regular spot. Over good food, most of these frustrations turn out to be pretty funny stories.
The short version:
- Hands-off development doesn’t fail because it’s hands-off — it fails when the team holding your project doesn’t hold your context. Same as saying “chef’s choice” at a restaurant that has never met you.
- One question at a time beats a 100-page approval — nobody reads the thick document. Small confirmations stack up into a team that knows your business.
- Something that moves beats something written — an AI mockup before development kills “that’s not what I meant” before it costs you months.
Frequently asked questions
What’s the difference between a dedicated development team and project-based outsourcing?
Project-based outsourcing is a contract to deliver what the specification says — the document is the standard for everything. A dedicated team reserves the same engineers for you over months, so requirements can be settled one question at a time while the work moves. Specs don’t disappear; they change shape, from a thick up-front document into a moving mockup plus a record of confirmed answers. Details are on our dedicated development team service page.
I want to hand development off completely. What does my side still need to do?
Keep the judgment — hand over the rest. Lining up options and the information to decide between them is the team’s job; your job is answering “A or B?” And if those questions arrive one at a time, they don’t need blocks of your calendar. Handing everything over before the team has your context is the “chef’s choice on a first visit” from this article. Our free 3-minute readiness check shows what to prepare on your side.
Our project is half-stalled. Can we still talk?
Yes. A spec, a codebase, and a live product that each say something different — that state shows up in every project sooner or later. It’s exactly where one-question-at-a-time confirmation works best: rebuilding “what is currently true” piece by piece. You don’t need to arrive with things organized. Book a slot below and talk through it as-is.
Once it’s getting specific, bring it to a 30-minute conversation below — as-is is fine.
Tell me what’s been bugging you. That’s enough to start.
I’ll listen to where your business stands and help you find where the understanding is slipping. If it’s useful, we can also get concrete about what a dedicated team that holds your context would look like.
Book 30 minutes → Take the 3-minute readiness check
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.