How we work
Listen first. Build what is useful.
We work in seven steps. At the end of each one you get something in writing to keep, so you can always see where the work is and why decisions were made.
Seven steps. Something in writing at every one.
Understand
We start with what is happening, who it affects and what needs to change. We talk with the people closest to the problem and the services around them, and we look at what data already exists and what it misses.
A short written statement of the challenge, the people affected, the intended outcome, what is known, what is not known and whether technology is the right response at all.
Co-design
Young people, communities and frontline practitioners shape the response early. We explain what they can influence, pay for substantial contribution and keep a record of decisions.
Who takes part, how they are recruited, what they are paid, what they can change, how consent and safeguarding work, plus a service blueprint showing the journey and the systems around it.
Build
We build in small releases, using accessible patterns and lean engineering that works on older devices and slower connections. Prototypes use fictional data and are labelled.
A working prototype, an annotated record of design choices, the safeguard attached to each choice and the limitation each choice carries.
Test
We test with the people who will use the service, with keyboards, screen readers and zoom, and with practitioners who will run it. We test for geographic and demographic bias where community data is involved.
Findings against WCAG 2.2 AA, what was fixed, what remains, and the results of testing with people with access needs and with practitioners.
Safeguard
Privacy, safeguarding and data ethics shape the product from the start rather than being checked at the end. Location-aware and community-reporting features follow the guardrails below.
Our written contribution to your data protection impact assessment, a safeguarding review with named lead and escalation route, and a moderation and incident plan.
Learn
We measure what was agreed before any claim is made. We separate participant feedback from independently measured outcomes and publish negative or inconclusive learning where it changes practice.
What was measured, over what period, with what denominator and method, what the limitations are and what we would change.
Hand over
Partners should not depend on us. We document, train and plan the exit before launch, so the service can be run, moved or switched off without loss.
Deployment and release notes, training materials, support terms, data export and deletion steps and the exit plan.
How participation works
People decide whether to take part. We explain what they can influence, how their contribution will be used and what changed as a result.
Taking part is real work, so we treat it like work. People know what they are shaping, choose to be involved, share the real decisions and are paid properly for substantial contributions. For young people it should also lead somewhere: skills, references and routes into paid roles.
Paid participation, not “giving young people a voice”. Young people already have voices.
Location-aware safeguards
Anything that touches location or community reports follows these rules. They draw on the ICO’s Children’s code principles on data minimisation and geolocation.
We collect data for a defined public benefit, not because technology makes collection possible. We minimise personal information, explain how insight will be used and present community reports with their limitations.
- Complete a DPIA before processing live location or sensitive community reports.
- Default geolocation to off, especially for children, unless a documented best-interest case supports use.
- Make active location use obvious and temporary. Never expose a young person’s precise location publicly.
- Use the lowest precision and shortest retention that achieves the task.
- Separate official records, partner data, community reports and resource information.
- Show source, age, geographic coverage, verification and confidence.
- Design moderation, malicious-report, duplication and safeguarding escalation before launch.
- Test for geographic and demographic bias. Low-reporting areas must not automatically appear safer.
- Publish how route options are calculated and retain human oversight for material safety decisions.
- Provide emergency signposting while clearly stating that the product is not an emergency service.
Want to talk through how this would work for you?
Tell us what is happening, who it affects and what needs to change. We will talk you through the steps and what you would get in writing at each one.
We reply within three working days.