wtfuc.tech

Operating principles

We are not disrupting
anything.

We are fixing specific, boring, expensive problems that the industry has agreed to live with. These are the eight constraints we design against. They are not aspirational — if we break one, the tool is wrong.

The axioms

  1. Complexity is a bug, not a seniority signal.

    A system nobody can hold in their head is not sophisticated, it is unfinished. The hard part was never adding capability — it was deciding what to leave out and defending that decision in a room full of people who wanted their thing in it.

  2. Every dependency is a promise someone else made.

    You did not choose most of what you ship. You inherited it four levels deep from a maintainer who stopped answering issues in 2021. That is survivable, but only if you know which promises are still being kept.

  3. If it needs a wiki page to survive, it needs a redesign.

    Documentation should explain intent, not compensate for a bad interface. Every onboarding doc that exists purely to warn people about a footgun is a design review that never happened.

  4. Ship the fix, not the framework.

    The instinct to generalise a problem before you have solved it twice is how a two-day task becomes a platform. We build narrow tools that do one uncomfortable thing well, and we resist the abstraction until it earns itself.

  5. Survive first. Excel second. In that order.

    Nobody optimises their way out of an outage, and nobody gets promoted for a rewrite that never landed. Stability is not the opposite of ambition, it is the precondition for it.

  6. Boring technology, interesting outcomes.

    The novelty budget is small and mostly already spent. Spend what is left on the thing that is actually your differentiator, and let the database be a database.

  7. A tool that hides the problem is a slower outage.

    Abstractions that conceal failure do not remove it, they defer it to the least convenient moment and the least prepared person. Good tooling makes the ugly thing visible early, when it is still cheap.

  8. Nobody reads the docs. Write them anyway.

    They get read exactly once, at 3am, by someone who has never seen the system and is about to change it. Optimise for that reader and you will have written the only version that mattered.

The other half

Things we will not do.

A principle you have never had to turn down money for is a preference, not a principle.

  • Ship a tool that needs a six-week onboarding programme
  • Charge per seat for something that runs in your own CI
  • Add a cookie banner so we can find out which of two buttons you clicked
  • Call a wrapper around an API a platform
  • Hold your data hostage as a retention strategy
  • Pretend a rewrite is a strategy

In one line

Build the smallest thing that makes the ugly part visible, then get out of the way.

Everything on this site is an attempt at that. Where we have missed, we would genuinely like to know.

hello@wtfuc.tech