About
knowlezi is the name I design and build under. I’m interested in the whole process: understanding a problem, designing something useful, writing the code, and looking after it once it exists.
Most of that work is for churches, charities and community organisations — places with a real audience, a small budget, and no one on staff whose job is the website.
Why a pseudonym
The name exists to separate the work from the person, so that what gets judged is the thing that shipped rather than a CV. That is a deliberate choice, and I know it asks something of you: you cannot look me up.
So the site is built to be checkable instead. The case study links a site you can open and use. The colophon shows how this site is made and what has to pass before anything is published. The accessibility statement says plainly what is tested and what those tests cannot prove. Evidence you can inspect, rather than a name you would have to take on trust.
If you are considering working with me, we will talk, and I will not be anonymous to you.
Design and development, together
The details connect. A content model shapes what an interface can say. A design system makes the next change easier. The tools people already use should inform how a product fits into their day.
Because I do both, there is no handover in the middle of a project where the intent gets lost — and no incentive to design something that is impressive to look at and miserable to maintain.
How I work
The brief is usually wrong, and that is fine. Organisations ask for a new website when the real problem is that nobody can update the old one, or that the information on it is wrong. I would rather find that out in the first conversation than build the wrong thing well.
I say what is not finished. The case study on this site describes a project that is live but still in preview, with its calendar not yet connected. That is what it is. You will get the same directness about your project, including when the answer is that you do not need me.
Maintenance is the design problem. Anything I build has to be changeable by whoever inherits it. If a decision would make the site harder to look after in three years, it is the wrong decision, however good it looks now.
Accessibility is not a phase. It is tested continuously and it is not a line on the invoice. How a project runs covers what that means in practice.
Building in the open
I share projects as they develop, alongside notes about the work. Churchfield is being prepared for an open-source release so other churches can use and adapt it.
If you’re working on something related, have a question, or want to compare notes, I’d like to hear from you.