>So, where do you draw the line? Do you accept having an OS?

Yes I accept using an OS usually, I guess there's much more than could fit on a single catchy sentence, but there's a clear policy.

Operating System is the biggest exception, for Windows it's pretty simple to carve out everything that is manufactured by Microsoft itself. But for the main Linux OS (Debian/RHEL), I include everything that is distributed by the main package manager (apt/yum) as allowed by the OS policy exception. (On Windows, this is equivalent to adding software packaged and signed by microsoft, like Git).

Alternative package managers like flatpak or snap are against my personal policy, not only are they very bloaty, but they kind of break the OS monopoly and push towards less safe supply chains, if it's not in apt/yum, then I don't use it.

> So I assume you run directly on BIOS or UEFI?

I have gone that route, but only experimentally, it's not very hard to get C compiled binaries to run and interface with keyboard and display through BIOS, but there's a lot of extra work that needs to be done incrementally, in order to use features in the sequence that they have historically been available, like 16 bit, 32 bit, 64 bits, 4GB memory. If you think of Wirth's law, this might actually be an effective long-term pacing strategy.

But I'm not that hardcore personally, not for lack of want, in a professional setting I'm pulled towards the pragmatic side and start conceding to stuff like using an OS, maybe using one or two packages. I would probably revisit booting directly to binary if any startup I work with hits a home run and needs to upgrade to at least 10k+ concurrent users. It's like one step removed from an ASIC, which is a stage almost no company enters, but I would have definitely have passed the baton at that stage, custom hardware is another discipline.

>But even those are fairly sizable on modern systems.

Well not BIOS, but UEFI and device drives certainly are. BIOS would just be some (mostly unwritten) standards on how to initialize, then it dissapears. Of course hardware itself is a dependency, and I'm definitely not going to be summoning computing from heat, sand, and electricity, but my line is definitely at the OS and above.

One final exception that wasn't mentioned is the programming language and its 'built in libraries'. I use the programming language along with its standard distribution. For Python (my main language), that means I don't use pip, but I might use 'import sockets' (it's almost the same as using cffi and glibc anyways). There's an analogue in almost all languages, node with npm, java with maven, php with composer, I just don't add those kinds of dependencies if I have control over it. I chmod ugo-rwx requirements.txt to avoid other engineers from adding leftpadisms.

That's not to say that it never happens, maybe even I imported Flask to meet a deadline, and maybe there's that perfect library from a good source that someone else suggests and it gets accepted, but it doesn't hurt to add some friction, it catches a lot of trash packages from being added to the foundation of a startup, which give almost no benefits at great expense over the lifecycle of the core.

The end result has a few advantages if I may explicitly sell myself and my strategy:

- Basal stack: Instead of having to hire yarn,yum,pnpm,react,tailwind,buzzword,jev,shadcn, developers (developers of very specific modern deep tech stacks that will only be used and popular during a very narrow timeline), if the startup grows, they have a much broader space to search talent from, which means that hiring can occur across other search parameters, MOST importantly business domain knowledge. I think it's much more productive to hire devs that are interested in dentistry if you are a dentistry startup, rather than devs that know, say, the intersection of Kubernetes, FastAPI, Kafka and some AWS Branded tech.

- Long term Foundation: Usually the simpler basal tech takes a bit longer to get started, as opposed to exclusively prioritizing delivery speed, but it allows for reasonable development speeds in later stages.

We sometimes call it tech debt, in this case the mechanics create debt by: increasing the Lines of Code count (you should count the lines of the dependencies you import), and by reducing the personnel system knowledge.

It is a tradeoff yes, but it isn't really a huge advantage to be able to get the first version up in 2 hours, as opposed to 1 month. Much less getting a first version up in 15 seconds with a prompt. I'd rather just work with someone that can spend like 5K in a 1 month prototype, and thinks about pacing for the long term winner-takes-all condition, rather than trying to save 5K and having a prototype in 2 hours, (or in 15 seconds). Nothing wrong with that, but it just doesn't seem like I would fit in there. If someone wants to setup their prototype in 2 hours, they don't need me, and if they ever call me, we are going to be building the 1-month prototype from scratch, and using the vibecoded or Framework prototype as a Proof of Concept, not an architectural base.

- Proprietary advantage/Moat: Haven't seen this mentioned elsewhere, but code is the main asset of a company, if you import a lot of code to achieve your goal, sure you accomplish that, but you have not accomplished a very distinctive or defensible advantage. Strategically it's more profitable to pursue the kinds of challenges you need to write code for, than the ones you need to import and glue together components for.

- Strategic conditioning: Similar to the above, but you want to think and write code at the same time, if you use someone else's framework you think according to their terms, whether that is to confer them a strategic advantage, or whether the goal of thinking is to reduce development costs. The kind of thinking that occurs in software development should ideally be as free as possible from the influences of actors that are not goal-aligned with the company's mission.

Opinionated software is great, but ideally other software should be incorporated with a commercial relationship in the middle, carved out by some other exception. And even then, their goals should be acknowledged strategically, if you are building, say: a DRM or surveillance system on top of Debian, that's bound to have some sort of conflict. Similarly using Microsoft for a public hospital project is another conflict that is worth at least taking note of.

- Personnel knowledge: I pointed to this, but the knowledge of personnel of the system AND the business domain is relevant. The objective of making software is not JUST to achieve the end-goal, the knowledge acquired in the process of creating that software is a valuable byproduct for both operational and strategic reasons. Similar to writing an essay, it's not just that we want to have the essay in order to slap it into someone else (well maybe sloppers do), but that we actually gain insights and develop our own thoughts while we write it.

- User/Producer separation: For the cases where the product is about LLMs or DevTools. If you both consume dev tools and build devtools, or consume LLMs to code and are building LLM features, I find that people tend to get lost in an unhealthy spiral more often, it's a dangerous task to endeavor, if there's ever a time not to use LLMs to code, it's when your product actually includes LLMs as a feature for users. Which is even a more important goal, right? What's more important, putting this super technology at the hands of the user? Or consuming this super technology to accelerate development?

---

Regarding costs this is not particularly expensive either, it's not like you are missing out on a particularly valuable revolution if you miss out on abusing Open Source supply chains or on abusing vibecoding thingies. An idea-stage startup that hires me to build an MVP would cost like 5K and a month, maybe if they really want to polish it, that's 6 months which is like 30K, plus the (co)founder's salary, whatever that is, as it's not hands-off work.

I'm sure to some the idea of saving 29K and spending 1K in AI subscriptions is enticing, maybe they can even attempt vibecoding before hiring talent, for sure, that's valid. It even helps refining and conveying the idea, and getting more accurate cost and feasibility estimations. But it's also a perfectly skippable step, that bootstrapped investment route has been used for decades now.