Opening
Hi there. This is 服部明, one year into running my own company, founder of coiai Inc. coiai is an IT company centered on technology, doing system development and product development. Every Monday on this show, I, the founder, share the reality of running a startup.
This time, I want to cover this week's tech news, and then for the main segment, get into whether a mission statement is really as meaningful as people claim, and also talk about system design — specifically, why I think designing in a bit of slack, a bit of buffer, tends to be the better approach.
This Week's Tech News
Let's start with this week's news. I'll walk through some notable articles from Hacker News and Zenn.
Can I Run AI Locally
"Can I Run AI Locally" was pretty big on Hacker News this week. What this is: you go to the Can I Run AI Locally site, select the computer or graphics card you're currently using, and it tells you roughly what size of LLM you'd be able to run.
It's got a pretty intuitive, easy-to-understand interface. We ourselves sell an on-premises AI service — installing an open-source LLM that runs on a server, usable from within a company's own internal network — so I found this site really easy to read and genuinely well done.
It's also great as a piece of material you can immediately show a client — "with a machine at this spec, you'd be able to run something around this size" — I personally thought that was really nice. I also just use things like Ollama myself day to day, so this felt like a genuinely useful tool.
The Debate Around Spec-Driven Development
There was also a fair amount of debate going around about spec-driven development. Talking about spec-driven development means we first have to talk about what a "spec document" even is.
In the programming and engineering world, it's fairly common practice to write up a spec document first and then build based on that. This shows up especially often in waterfall-style development environments, and there are even people whose job title is "engineer" who spend their entire day just writing spec documents in Excel. I'm not joking — these people genuinely exist. People who spend the whole day in Excel writing things like "if you press this button, it jumps to this page."
Personally, I don't think that's a particularly productive way to work. There was a discussion going around along the lines of: if the spec itself basically already is a working program, then why not just treat it as such — and I'm honestly somewhat sympathetic to that view.
There are plenty of cases where a program, or really any system, is genuinely hard to fully express in words alone. Trying to lean entirely on language to spell out "this does this, and this does that" up front, and only then translating it down into actual behaviors and interactive elements like buttons — I do think that approach has real limits.
Writing a perfect spec is fine as a way to protect yourself, or to lay out what your own company commits to delivering. But if the actual end goal is delivering a working product, I think keeping spec-writing to a reasonable minimum and prioritizing writing working code is what matters most.
This isn't a new idea, either — the Agile Manifesto has been freely available online for a long time now, and you can read it yourself. It says things like "working software over comprehensive documentation," so I think finding the right balance, the right amount, is what really matters here. Writing out every single detail of a spec word for word just isn't realistic, so personally, I think it's better to only really nail down the important parts.
Other News
That was basically the big one this week, along with a fair number of Claude Code stories floating around. There was also news about a helium supply shortage — possibly affecting semiconductor manufacturing — so, that kind of week. Nothing that felt like a particularly major wave this week, I'd say.
Main Topic 1 — Is a Mission Statement Actually Necessary? What MVV Really Is
Okay, let's move on to the main topic. This one's about mission statements.
We haven't actually set one for our company, and the reason is simple — we don't have employees. We run as a two-founder setup, so there isn't really a large group of people we need to communicate a mission to. Communicating it to people outside the company might matter, but since dealing with outside parties basically means contract work for us, I'd always felt like a mission statement wasn't all that relevant.
That said, I've started thinking it wouldn't hurt to have one. As an individual, I've always worked with some kind of personal philosophy guiding me, and I think a corporation, being kind of like its own personhood in a sense, could use having a philosophy given to it too — so I've been doing some research into this.
I Went Looking for the Original Source of the MVV Framework, and…
Here in Japan, you've probably heard of the MVV framework — mission, vision, values. It's pretty famous — it shows up in books about starting a company, in articles, and people who support startups will often tell you "let's nail down your MVV." But what actually is this thing?
I went through a phase of reading a lot of business books, and management and economics texts, and I noticed there really isn't much out there that clearly documents where this comes from. I wondered if there was an original source, so I looked online — there isn't one.
Something close to it apparently appears in one of Peter Drucker's books, I think it was "Managing in the Next Society" or something along those lines — but every source just says "apparently it's written there," without actually quoting it. I think mission and values do show up in there somewhere. But it's not laid out anything like the MVV format that's used today.
The Vagueness of Business Frameworks
So somewhere along the line, someone just started saying "Drucker said this," and that always struck me as pretty sloppy — I can't really bring myself to like that kind of thing.
For those of us who write code, we always go check the official documentation — how does this API's spec actually work, is this the right way to write this — that kind of verification is second nature. But with a lot of these business frameworks, somehow they get treated as hugely credible even though nobody can quite say who actually came up with them, there's no real scientific backing, and it's not even clear that major companies actually adopted them. It happens a lot, honestly — you end up wondering what the thing even is.
Same goes for the PDCA cycle — it's often attributed to a specific person, but it turns out that person never actually proposed it. I keep feeling like business frameworks in general are just way too loosely sourced, and it's honestly unsettling that following one doesn't come with any real reproducible guarantee of success.
That Said, I Do Think Having a Philosophy Matters
Even so, I've come to feel that having some kind of guiding philosophy probably does matter. Plenty of well-known companies publish something like a values statement. Apple, for instance, still has an "Our Values" page right on its official website. It's very short, but it quotes the current CEO, Tim Cook, saying something to the effect of — translating it into Japanese and back — "we believe that when business is done in its best form, it contributes to the public good, empowers people around the world, and connects us more than ever before." That's on a page aimed at investors, information for investors specifically.
So I do think it's fine to set some kind of guiding philosophy. Plenty of Japanese car manufacturers have their own stated philosophies too. But none of them frame it explicitly as "mission, vision, values." I think the substance that framework tries to capture does show up inside those philosophies, but I don't think you necessarily need to force it into that specific framework.
As the company grows bigger, it would be nice to be able to share some kind of shared conviction with everyone. As for what coiai Inc.'s own philosophy actually is, I'd like to work that out and share it over time.
So, that was basically my take on MVV — mission, vision, values — and whether it's not, honestly, a little bit dubious.
Main Topic 2 — Building Buffer into System Design
Next up. Recently, I had a chance to observe a full system replacement in progress, and the new system turned out to be genuinely not very usable — it wasn't getting a great reception on the ground. I want to talk about what specifically was bad about it, as much as I can within what I'm able to share.
A Library Analogy
Let's say there's a library. The library has a book lending and return system. A customer borrows a book. Let's say that when they borrow it, a lending slip gets issued. Now imagine a system where, if you don't bring that lending slip back with you, you can't return the book — a system where even if you bring the actual book back, you can't complete the return without the slip.
But from the customer's perspective, there's a very real chance they'll lose that slip, right? Yet due to how the system works, unless it scans the barcode printed on that slip, it has no way of registering that the customer actually returned the book. Do you think that's good design? I don't think that's good design at all.
Designing With Human Error in Mind
Customers are human, and so are employees. I really do believe you have to design with human error in mind as a given, but if you just build a system in the ordinary, straightforward way, it ends up with no buffer at all.
Computers are extremely well-suited to setting things as simply True or False, but the real world branches off in all sorts of directions constantly. Every single object out there has essentially an infinite number of possible actions attached to it. Take just one light bulb — you can turn it on, you can remove it, you can break it, you can attach all kinds of things to it — there's essentially no end to what's possible.
So designing the right amount of flexibility into a system is genuinely difficult. But if you make that flexibility too limited, then the moment the system runs into a situation it didn't anticipate, you end up completely stuck, with no way to handle it.
And what happens then is something I see a lot in system development, and honestly, it's one of the worst outcomes: a case that could have been handled just fine manually before the system was introduced suddenly becomes impossible to handle the moment the system goes live.
coiai's Approach
coiai Inc. does core business system development as one of our services. Given my own philosophy on this, I genuinely believe that building in buffer is the first step toward a beautiful system, so we make a point of always doing this — and I know it's the kind of thing that often only gets discovered after delivery, once it's too late.
So at our company, we build on an agile development approach, staying in constant dialogue with the client — asking things like "will this actually be okay," "what happens in this kind of edge case" — and doing our best to catch these things during design and implementation, rather than after the fact.
So, if you've ever moved to a new system and it just hasn't gone well, please do reach out to us — and there's my usual smooth segue into a bit of self-promotion.
Closing
And with that, we're about at time again this week. coiai Inc. works on web development, XR development, core business system development, and on-premises AI adoption support — that is, LLMs that run locally. We can handle pretty much anything else too, so if you've had a project turned down elsewhere, or gotten a quote that felt too expensive, quotes are always free with us — please reach out about anything at all.
See you again next Monday. I'd be happy if you'd subscribe to the channel and come back to listen again next week. Thank you very much.