We want to eliminate companies that lose out simply because they don't know better. We want to build a world where value flows straight through — to engineers and clients alike.
It's fine to order from a vendor. What matters is understanding what's inside, never just going along with it, and keeping the reins in your own hands. "A state where you judge for yourselves, and put it to real use" — that's what we call “in-house development.”
CEO. After a stint in sales at Recruit and a failed startup, joined Microsoft Japan and NTT Data. Has worked in development on every side — client, vendor, and in-house — and has watched the same scene repeat for 20 years. Went independent in 2019, incorporated in 2022. Supported agile development standardization at Red Hat. Now builds and runs 10+ products, one person + AI.
Just like building a building. Completion and handover are the “goal.” After that, it's not their problem.
Improvement only begins once something is actually used. Delivery isn't the goal — it's the starting point.
Here lies a fundamental conflict of interest. The client wants it “better,” the vendor wants to “deliver fast and be done.”
When “contract work” fixes the price and deadline,waterfall is the only option left.
Decide everything up front, then flow one-way from upstream to downstream. No going back. — But reality doesn't work that way.
Could you have predicted COVID five years ago, or the iPhone twenty years ago? No one can write a perfect spec up front.
"I want this feature," "this button is hard to tap, move it." Without feedback, you can't build something good.
Even when a design flaw is noticed mid-implementation, it goes unreported to protect the deadline and the payment. The Seven Pay incident is a textbook example.
Are you really okay handing your core technology entirely to another company?
Every time contracted work is handed down through another layer of subcontractors, a middleman margin gets skimmed off. By the time it reaches the team actually building it, there's very little left.
Each layer skims off about 20%. After just 4 layers, over half the order amount is gone to margins, and only about 40% reaches the team actually building it.
Contract work fixes the deadline and the price. So it can't accept change, and becomes waterfall. Agile is the opposite.
Decide everything up front. Can't change.
Delivery is the goal.
Build small, use it, fix it.
Assume change, improve through feedback.
A top-tier PO, scrum master, engineers, and an understanding of agile itself. Assembling all of that isn't easy.
A self-driving team needs delegated authority. But in a Japanese organization, the decision to “trust the front line” rarely comes down.
Even starting with a lab-style contract or SES, you hit walls of talent and contracts. Handing it all off never produces something good in the end.
If you can't rent it, you have to “own” it yourself. But — assembling that elite team came at a steep price.
7-8 people in total. Building that team, ¥10M a month was just normal.
Implementation, design, consultation — AI can do it. As long as you understand the essentials, one person + AI can now run what that elite team used to do. = In-house development just became real.
The only thing AI is missing is your company's “context.”Why not grow someone in-house who can supply that judgment?
What I'm aiming for is a state where you“no longer need to rely on me” to keep running.
No more outsourcing, no more multi-layer subcontractor skimming. Development that used to cost tens of millions gets built in-house, one person + AI. The cost drops by an order of magnitude.
Once you build in-house, the same work can be run by fewer people. Fixed costs go down, and that difference stays as profit.
You stop taking proposals at face value and learn to see through them yourself. Because the people who think and the people who build are the same, “that's not what I asked for” never happens.
Is your company dependent on vendors right now, or able to judge for itself? Why not start by sorting that out together?
