About Boring Reliability

Boring Reliability is about building software that is calm, predictable and surprisingly robust — even when the metaphors are a bit unhinged.

Under the banner of Calm UX & Dark Magic the focus is on readable interfaces, test-driven workflows for AI-assisted development, and turning legacy systems into stable foundations instead of haunted crypts.

Dennis experiments with GS-TDD, responsible AI tooling, and frontends that feel quiet even when the underlying stack is anything but.

How this site is tested

This site practices what it preaches. Every feature follows GS-TDD (Gold Standard TDD): tests define behavior first, implementation comes second, and refactoring happens without breaking contracts.

The test suite includes:

• Unit tests with Vitest + Testing Library — Component behavior, API routes, and utilities are tested in isolation using BDD-style (Given-When-Then) assertions.
• E2E tests with Playwright — Critical user journeys (navigation, blog reading, interaction flows) are verified end-to-end in real browsers.
• Mutation testing with Stryker — The rate limiter and other critical paths are mutation-tested to catch weak tests that pass but don't actually verify behavior.

If you see a feature marked "Coming soon", it means the tests aren't written yet — not that the feature is half-built. GS-TDD applies to this blog too: no tests, no feature.

Mr. Reliable (the chat assistant)

The chat interface uses a rate-limited OpenAI API route. The rate limiter is currently in-memory (resets on deploy), so in multi-instance production setups you'd want Redis or similar. For a single-instance blog, it's boringly adequate.

If Mr. Reliable is temporarily unavailable, it's likely an OpenAI API issue or rate limit hit — not magic, just reality.