Blog
Nothing published
here yet.
The blog will carry four kinds of writing: build notes explaining why the product works the way it does, arguments about survey methodology, notes on what actually blocks UK public sector adoption of a new tool, and a plain-language record of what shipped. There are no posts yet, and this page will not pretend otherwise — when the first one goes up, it will appear here with a date on it.
In the meantime the reference pages are where the substance is. They are written to be read, not skimmed past on the way to a sign-up button.
What will live here
Build notes
Why a thing works the way it does. Why response caps are enforced by a database trigger instead of the interface. Why partial answers live in a table with no row-level security policies and are reachable only through SECURITY DEFINER functions. Why there is no PDF library shipped to respondents.
Survey methodology
The parts of survey work that are argument rather than fact: question order effects, when randomisation helps and when it hides a real result, whether a recommend score tells you anything on its own, and how long a survey can honestly be.
Working in the UK public sector
What actually blocks a council, a trust or a school from adopting a tool. Usually not price — usually a DPIA, an accessibility statement, or a sub-processor list that has to survive an information governance panel.
Changelog in prose
What shipped, written so you can tell whether it affects you. Short entries, no roadmap promises, and no feature described in the present tense until it is live.
What this blog will not be
There is a genre of survey-tool blog that consists of eight hundred words of “what is a Likert scale” written to rank, followed by a call to action. That is not the plan. Where a definition is useful it goes in the glossary, where a procedure is useful it goes in the guides, and where a task-level answer is useful it goes in the help centre. The blog is for things that are genuinely opinion, genuinely new, or genuinely a decision someone had to make.
It also will not carry customer stories or case studies, because there are no paying customers yet and inventing one is not a mistake you recover from. When there are, and when they agree to be named, they will appear under their own names.
Where the writing already is
Most of what would ordinarily be spread across a year of posts is already on the site as reference material, which is easier to find and easier to keep accurate.
- Conditional logic — including why scoring counts only the questions a respondent actually saw, which is the sort of design decision a blog post would otherwise have to explain.
- The 16 question types — with the reasoning behind labelling the 0–10 question “Recommend score” rather than NPS.
- Exports — why matrix rows get their own CSV columns, and why per-response PDFs are produced by the browser rather than a shipped library.
- Security — where responses are stored, how organisation isolation is enforced, and which certifications we do not hold.
- The comparison pages — each written against a competitor's published documentation, with the date it was checked.
Suggest a post
If there is something you would like explained — a design decision that looks wrong from outside, a methodology question you cannot get a straight answer to, or how a specific survey should be structured — send it over. Questions from people building real surveys are considerably better source material than a keyword list.
While you wait, the template structures sketch out thirty surveys by sector, and the resources index lists everything published on this site in one place.
The product is ahead of the blog.
There is nothing published here yet, but the thing the posts will be about is already built. Open the builder and put a real survey together while we get the writing done.
- Reference pages carry the detail the posts would repeat
- Build notes will explain decisions, not restate the glossary
- No customer stories until there are customers to name
