Nullhaus
Near-black textured backdrop with faint gold hairline geometric lines

The Library

Learn

Everything we publish. Free.

The Library

Eight fields, one catalogue.

Everything Nullhaus publishes is here, free, with nothing behind a signup. Start from the pillar you work in, or read whatever went up most recently.

Recently published

  • The empty state is the first screen most people see
    Products are designed with the data already in them, so the screen every new user actually meets is the one nobody reviewed. Four kinds of empty, and why only one of them is a success.
  • The first responder is the least informed person on the call
    Incident response fails on coordination far more often than on diagnosis. Separating the person deciding from the people investigating is the change that makes the difference, and it costs nothing to adopt.
  • Primer: event time, processing time, and the watermark
    Every data pipeline has two clocks, and most reporting bugs come from confusing them. A plain-language primer on when something happened, when you found out, and how a system decides it has waited long enough.
  • A test suite is a budget, not a percentage
    Coverage measures which lines ran, not which failures you would catch. Treating the suite as a fixed budget of time and attention changes what you write and, more usefully, what you delete.
  • Access is a lease, not a grant
    Most access reviews fail because they ask the wrong question. Standing permission accumulates because nothing in the system expires, and the fix is an expiry date rather than a quarterly spreadsheet.
  • Training your users to click yes
    Are you sure is a question nobody answers honestly. It moves responsibility from the system to the person at the exact moment they are least able to carry it, and it is usually standing in for an undo that was never built.

Learn

Knowledge should belong to everyone.

Everything Nullhaus discusses in private, it eventually teaches in public. That’s not a tagline. It is the reason the library exists. The inner circle stays small so the conversation stays honest; the material that comes out of it stays open so that honesty isn’t wasted on ten people. No login wall. No lead-gated PDF. No “create an account to keep reading.” If you can find this page, you can read everything on it, wherever you are and whatever you do for a living.

We also teach the discipline of the work, not the fear around it. Cybersecurity content especially tends to sell through worry: breach statistics, worst-case scenarios, threats engineered to make you buy something. We don’t do that. What we publish is meant to make you better at the actual work: understanding a real risk, writing better code, running infrastructure that holds up, evaluating an AI system honestly.

A shaft of warm light falling diagonally across a dark concrete interior corner

The inner circle is private. The learning is not.

What we publish

Four kinds of thing.

Recorded sessions

Edited recordings of Assembly conversations, published after every session with the participants’ review. These aren’t polished corporate webinars. They are real, sometimes contentious conversations between people who know the subject cold, trimmed for length but never sanitized for content.

Field guides

Longer, structured pieces built around a durable topic rather than this week’s headline, laying out how a class of problem actually works, where practitioners commonly go wrong, and what good practice looks like today. Written to be referenced repeatedly, not skimmed once.

Briefings

Short, focused write-ups tied to a specific session or a fast-moving development in one of our eight pillars. Where a field guide takes its time, a briefing gets to the point in a few minutes.

Primers for newcomers

Entry points for people new to a pillar entirely: a student deciding whether to study security, an engineer moving from software into infrastructure, a product manager trying to figure out what “alignment” actually means in AI. No assumed background, no talking down to the reader.

Example topics by pillar

Eight pillars. Open the ones you work in: each holds the kind of question that actually comes up in a session, not a syllabus.

Cybersecurity · detection, response, and what a clean audit still misses
  • Why most “threat intel feeds” are just noise a SOC has to triage, and what a program worth paying for looks like
  • How incident response teams decide to contain versus keep watching when they don’t yet know if the attacker is still inside
  • What a clean compliance audit doesn’t tell you about whether an organization can actually detect an intrusion
  • Reading a breach disclosure for what the timeline is quietly leaving out
  • Alert fatigue as a staffing and tuning failure, not a tooling gap a vendor can sell their way out of
  • What actually changes on a security roadmap after a near-miss versus after a real breach
Artificial Intelligence · evals, retrieval, and reading benchmark claims
  • Building an eval harness that catches regressions before your users do
  • Why RAG pipelines fail silently: retrieval quality, chunking, and stale embeddings
  • Fine-tuning versus better prompting versus a bigger model: a cost and latency framework
  • Red-teaming an AI application for prompt injection and jailbreaks, not just the base model
  • What changes operationally when a model gets tool access, and what still needs a human in the loop
  • Reading a vendor’s benchmark numbers: what’s cherry-picked, what’s not reproducible, and what to ask for instead
Software Engineering · dependencies, review, and the debt worth keeping
  • Why “add a lockfile” isn’t dependency-risk management, and what actually reduces exposure to a compromised or typosquatted package
  • Code review that catches concurrency bugs and logic errors, not just style nits and naming
  • Reading your tech-debt backlog as interest payments due rather than a wishlist, and knowing which debt you can justifiably never repay
  • Designing for partial failure: degraded modes and blast-radius containment instead of chasing five nines
  • Migrations labeled “temporary” that outlive the team that shipped them, and what it costs to finally finish them
  • What incident reviews teach you about your architecture that code review never will
Cloud & Infrastructure · blast radius, misconfiguration, and the first minutes of a sev1
  • Blast radius: why “highly available,” multi-AZ architectures still take the whole platform down at once
  • The five-minute IAM or network misconfiguration that becomes a multi-day breach: real incident patterns, not hypotheticals
  • How autoscaling makes things worse: thundering herds, connection-pool exhaustion, and capacity math nobody checks until it’s too late
  • Multi-cloud, honestly: when it buys real resilience versus when it’s just doubled operational cost and duplicated risk
  • IaC drift: the gap between what your Terraform state says and what’s actually running in production
  • The first fifteen minutes of a sev1: why the runbook doesn’t match reality, and what experienced on-call engineers do instead
Data Engineering & Analytics · silent pipeline failure and numbers that only look reconciled
  • Why a dashboard can keep serving correct-looking numbers for weeks after the pipeline feeding it silently broke
  • Backfills that quietly duplicate or drop rows, and the reconciliation checks that actually catch it
  • Schema changes upstream: contracts, versioning, and why “just tell the data team” doesn’t scale past a few pipelines
  • Batch versus streaming: picking the wrong one is usually a latency-requirements mistake, not a technology mistake
  • Data quality as an on-call discipline: SLAs for freshness and completeness, not just uptime
  • Reading a “single source of truth” claim skeptically: which numbers actually reconcile, and which just look like they do
DevOps & SRE · SLOs, paging, rollback, and postmortems that change something
  • SLOs versus SLAs: why the number you promise externally should almost never equal the number you engineer to internally
  • What actually gets a service paged at 3am, and why most alerts should be tickets instead
  • Deploy pipelines that make rollback slower than the incident they’re meant to prevent
  • Toil audits: work that quietly justifies its own headcount instead of getting automated away
  • Postmortems that produce real action items, not a list of “communicate better” platitudes
  • Feature flags as a reliability tool rather than just a product one, and where they introduce their own failure modes
Blockchain & Web3 · consensus trade-offs, custody, and what an audit really covers
  • Consensus mechanism trade-offs explained without the marketing: what you give up for throughput, and what you don’t get back
  • Smart contract audits: what a “passed audit” claim actually covers, and what it never will
  • Custody and key management as the real point of failure, more often than the protocol itself
  • Reading a project’s tokenomics for red flags a hype-driven audience tends to miss
  • Cross-chain bridges: why they’re consistently the most-attacked component in the ecosystem, and what that implies
  • Where distributed-ledger properties actually solve a problem versus where a normal database would do the job for less
Product & UX · shipped versus needed, and the metrics that predict churn
  • The gap between “we shipped it” and “someone needed it,” and how to actually test for the second one
  • Writing error states and empty states that help instead of just filling space
  • Reading usage data honestly: vanity metrics versus the ones that predict churn
  • Cross-functional friction: where product, design, and engineering define “done” differently, and what that costs a release
  • Onboarding flows audited for the moment a new user actually decides to stay or leave
  • Saying no to a feature request from the loudest stakeholder in the room, and defending that call with evidence

Who makes it

Who creates this

Content originates from what happens inside Nullhaus itself: Assembly conversations, Roundtable problems (anonymized and generalized, never attributed to the company that brought them), and the working knowledge of our network of practitioners. A small editorial group, working with session participants, turns raw conversation into material that still holds up as a reference months or years later. Nothing here is written by a marketing team trying to make a product look good. There is no product to sell.


Access

Access, language, and reach

Every recorded session, field guide, briefing, and primer is published without a paywall, a login, or a regional restriction. We currently publish primarily in English, with a growing number of pieces translated as our network and resources allow. Anyone, anywhere, can read all of it. That is the whole point.


Questions

Frequently asked

Do I need to be a Nullhaus member to access the library?

No. Everything published here is open to anyone, member or not, in any country. Membership determines whether you might be invited to a live session. It has no bearing on library access, and it never will.

How often is new material published?

New material follows each Assembly session: a field guide or briefing, published alongside the recorded session itself. The library grows at the pace of the sessions rather than to hit a posting quota.

Can I suggest a topic?

Yes, and we read them. Send it through the Get notified form on the Join page and say what you would want covered. We prioritize durability and practical usefulness over this week’s news cycle, so the suggestions that get made are the ones a reader will still need in a year.

Does any company influence what gets published?

No. Nullhaus doesn’t accept payment or favorable treatment in exchange for coverage, and no company gets input into what we publish or how it’s framed. That includes companies whose people sit in our sessions.

Can I reuse or cite Nullhaus material elsewhere?

Yes, with attribution. Teach from it, quote it in a postmortem, put it on a syllabus. The material is published to be used, and that is the entire point of making it free in the first place.