How I work

Most projects I work on follow a similar flow:

Understanding how your organisation works.

I spend time with you and your team, ask questions, and find out what's really happening: what's working, what isn't, and what people actually need (not necessarily what's in the brief).

Testing realistic options.

No half-hour demos but days or weeks of real, actual use. I study the documentation, poke the support team repeatedly, and explore the edge cases you might come across.

Mapping the risks and exits before you commit.

I look at vendor lock-in, data jurisdiction, export formats, hidden dependencies, and what migration would really cost – in money, but also in time and potential lost history.

Along the way, I help with the questions you might not think to ask, or the ones a vendor or agency has carefully steered you away from.