Skip to content
Nixperts.

Why?

Where the name comes from, why the stack leans on free and open source software, and what the Unix philosophy does to the shape of a codebase.

Most consultancies are named after a founder or a Latin root. This one is named after a family of operating systems, a package manager, and a pun.

Three readings of one name

*nix

The Unix family — Linux, the BSDs, and the free software culture that grew up around them. Decades of tools built to be composed rather than clicked, by people who assumed the next person would want to take the thing apart. That assumption turned out to be the most valuable design decision in the history of software.

Nix

The package manager, the language and the operating system. Declarative, reproducible, and unusually strict about the difference between it works and it will work again tomorrow, on a different machine, in two years. The site you are reading is built in an environment described that way.

experts

The only part of the name that has to be earned rather than chosen.

Why free and open source

The argument is not ideological — or not only. It is that open components make for services that last.

  • Software that can be read can be fixed. A bug in a dependency is an afternoon with a debugger, not a support ticket into a queue with no visible end.
  • No rug pull. Licence changes, acquisitions and sunset emails are a normal part of the proprietary lifecycle. Postgres, nginx, Linux and Git have no renewal date and no sales team that can decide otherwise.
  • Auditable by anyone, including you. Security that rests on nobody being able to look is not security.
  • Leverage compounds. Thirty years of other people’s careful work is available for the cost of reading the documentation.

A stack assembled from open parts can be handed to somebody else, moved to another provider, or left alone for five years and still be understood. That is what “long-lasting” means in practice: not that nothing changes, but that change stays possible without permission.

What the Unix philosophy does to code

Do one thing and do it well was written about command-line tools, but it survives translation into a modern TypeScript codebase almost intact.

  • One reason to change. A module that does a single thing is a module that can be replaced without a planning meeting.
  • Composition over configuration. Small pieces that combine beat a large piece with forty options — the first is read by understanding the parts, the second only by understanding all of it at once.
  • Clear interfaces at the seams. Pipes worked because the contract was obvious. Typed boundaries, schema-derived types and explicit API shapes are the same idea with a compiler attached.
  • Expect the output to become somebody’s input. Including your own, six months later.

The result is the thing clients actually care about: a codebase that can be read in pieces, changed in pieces, and handed over without a ceremony.

Where the principle stops

This is a preference, not a religion. Figma is proprietary and excellent. Managed databases are sometimes the correct answer. The language models that write a share of the first draft are not open either.

The test applied is narrower than “is it free software”: if this vendor disappeared tomorrow, could the client still operate and move the thing? When the answer is yes, the tool earns its place regardless of its licence. When the answer is no, that is a cost — and one worth naming out loud before it is paid rather than after.