Problems I enjoy solving

Not a technology list. The stuff underneath it.

Every tool on the projects page started somewhere. Usually it’s one of these, recognised in the wild before it ever became a spec.

Users rarely ask for the thing they actually need.

  • The spreadsheet that became load-bearing

    A tracker that started as one person’s personal list and became the system three teams now depend on, that nobody’s allowed to touch.

    Why I like it — under the conditional formatting is usually a real, decent data model. It just needs a proper home.

  • Systems that won’t talk to each other

    Two platforms that each do their own job well and still can’t agree on a customer record, so someone re-keys it by hand every week.

    The interesting part is never the API. It’s working out which system should own the truth.

  • The report that answers the wrong question

    Four hours a month to build, and it answers a question nobody asked, twice removed from the decision it was meant to inform.

    Half the fix is technical. The other half is sitting with someone until they say what they meant.

  • The process that lives in one person’s head

    It only works because one person remembers every exception, and everything stops the week they’re on leave.

    That’s not a training problem. That’s an undocumented system wearing a person as its interface.

  • AI without a problem attached

    Being asked to “add AI” to something before anyone’s agreed what it’s meant to fix.

    The honest answer is usually a smaller, more boring automation. Less exciting in a meeting. Right anyway.

  • The bottleneck everyone’s routed around

    A step so slow the whole team has built a workaround, and the workaround is now the process.

    Why I like it — workarounds are free user research. Someone already told you exactly where it hurts.