01
Areas picked from memory
A manager chose today's props from memory of what was knocked recently, circled them on a map screenshot and sent them to each team on WhatsApp.
Case study · First Home Improvements · 2026
D2D: taking a door-to-door sales team from paper surveys to live data
I knocked doors on this team, and I designed and built the tool it now runs on. Over four months I took it from a paper sketch to an offline-first platform: a phone app that logs every door in one tap, and a web dashboard that plans areas, generates walking routes and shows results.
+40%
average leads per week, 5-week pilot
+2
pitches per canvasser per week
60+
canvassers using it daily
5
South West branches, live since October 2026
- Role
- Sole designer and developer: field research, UX/UI, data engineering, full-stack build, rollout
- Timeline
- July to October 2026. Planned and designed in July, live since October
- Worked with
- The canvassing team (field testers and route annotations) and the regional manager (stakeholder and buyer)
- Platform
- Mobile web app for canvassers (offline-first). Responsive admin for managers
- Next.js 15
- TypeScript
- Tailwind
- Supabase
- Postgres + PostGIS
- Row-level security
- MapLibre GL JS
- MapTiler
- Dexie / IndexedDB
- Vercel + Cron
- OpenStreetMap
- OS Open UPRN
- EPC open data
- Figma
TL;DR
The 60-second version
- Problem
- Areas were planned from memory and circled on WhatsApp. Every knock was written on paper. Nobody could answer "we knocked this area six weeks ago: which doors are left?"
- What I built
- A canvasser app that logs a door in one tap, works with no signal and follows a generated walking route. A manager dashboard to draw areas, allocate teams, see coverage and coach from real numbers. The company CRM syncs back in every night.
- How
- I worked the job myself, wrote down the team's unwritten rules (how they walk a street, what counts as a contact), designed in Figma, and shipped in tested phases with AI-assisted delivery, accelerated by batch scripting and manual checks and corrections.
- Result
- Live across 5 South West branches, used daily by 60+ canvassers. Leads per week up 40% on average in a 5-week pilot. Talks about expanding further are under way.
Context
The job, and why I was the one to fix it
A Bristol home-improvements firm (windows, doors, conservatories) finds its sales appointments by knocking doors. Teams of one to three canvassers work an area, called a prop, for about five hours a shift, six days a week. I was one of those canvassers. I also design and build software, so I could see the problem from the pavement and fix it from the keyboard.
How it worked before
02
Every knock on paper
Canvassers wrote a house number and an outcome on a paper survey: contact, lead, not in, rented. Sheets came back with missing house numbers and street names.
03
No memory between visits
Nothing linked a door to its history. Bad areas got a reputation ("that area's dead") instead of a plan.
An insider's brief
Building for a job I do every day meant I didn't have to guess at the field conditions: rain on the screen, one hand free, patchy signal, a partner leapfrogging ahead of me. It also meant I knew the team's unwritten rules, like what actually counts as a "contact" (someone you could book, not just anyone who opened the door). Those rules became hard requirements later.
Problem and constraints
Make every door count, without changing how the team works
The goal: replace memory and paper with data, so managers can plan areas from history and canvassers can log faster than they could write. The hard part was the list of things the tool was not allowed to do.
Who it's for
Canvasser
Logs every door, outdoors
One hand, often gloves or rain. Signal drops between streets. Has seconds between doors, and won't use anything slower than a pen.
Manager
Plans areas, coaches people
Needs to know what's been worked, what's left and who converts. Numbers-first and non-technical, so it has to be clear without explanation.
Office
Settles what happens to leads
Confirms appointments and records sales and pitch-and-miss results in the company CRM.
Constraints that shaped every decision
Compliance
No Cold Calling Zones are a hard exclusion
Bristol has 26 zones covering 13,270 properties. Doors inside them can never appear on a list, a map or in a count. No resident names anywhere: property-level data only.
Data
There was no clean address list
OS Open UPRN gives 424,952 Bristol doors as points with no addresses. Energy certificates gave a house number to only about 31% of them, so the app had to work when a door has no number.
Field
Offline first, one-handed
Every tap has to work with no signal and sync later without duplicates. Tap targets of 44px or more, actions at the bottom of the screen.
People
Canvassers are self-employed
Location features needed a defined purpose, the least intrusive design, a visible indicator and a one-tap stop (ICO guidance on monitoring workers).
Licensing
Terms ruled out the obvious tools
Mapbox's terms needed a paid commercial licence and forbid storing route results, so the maps run on MapLibre and MapTiler. Address fields from public data carry their own reuse limits, so they sit in a separate, removable table.
Adoption
Don't redesign the job
"A tool that changes how a team knocks gets abandoned in week two." Routes, outcomes and team behaviour had to match how people already work.
What success looked like
- Logging a door is faster than writing it down: one tap, no confirmation step.
- Zero lost knocks offline: re-syncing the same event twice changes nothing.
- The generated route matches how the team actually walks a street.
- A manager can see coverage and per-person numbers without asking anyone.
Design iterations
Seven versions of one screen
The Logger is where a canvasser spends their whole shift: one door, one tap, next door. It went from a pencil sketch to the shipped screen through seven rounds, each changed by something seen on a real street.
The seven rounds
- Pencil sketch
- First Figma concepts
- Annotated interaction model
- First field build
- Revamp explorations
- Circles and the door scroll
- Shipped, then tuned in the field
Where it landed
- One tap logs. No confirmation, a 400 ms double-tap guard, a 60-second Undo.
- The door number is the hero. When it's unknown, the canvasser can type the number they can see.
- Counts only (doors, contacts, leads), never rates or rankings, so nobody cherry-picks doors.
- Works with no signal. Every tap is queued on the phone and synced exactly once.
Design iterations
Routes that walk the way the team walks
A route that's already drawn when you arrive removes the 10 to 15 minute "who goes where" conversation at the start of every shift. Getting it right took two attempts, and the second came from the team's own drawings.
How the route generator came together
- Draw the area, keep only knockable doors
- Attempt 1: a textbook traversal
- Attempt 2: a walker built from the team's rules
- Make the route readable at a glance
- On the street
Decision log
Five decisions, and what each one cost
Most of the design work here was deciding what not to build. Each decision was written into the build brief as a hard rule, with a dated note whenever it changed, so it couldn't drift session to session. These are 5 of the 12.
Decision 02
No scores or rankings in the canvasser app
Scoring and ranking stay on the manager side. Canvassers see the door order and their own counts.
- Why
- If canvassers can see which doors score well, they cherry-pick them, and the coverage data stops meaning anything.
- Trade-off
- The prototype's scoring work only reaches managers. A sales leaderboard was later added to the field app as a deliberate, owner-approved exception.
Decision 04
One offline sync queue, safe to repeat
Every tap is queued on the phone with an ID created there, and synced exactly once. Undo happens inside the same queue.
- Why
- Signal drops between streets. With a client-made ID, re-sending the same knock is harmless, and a 60-second Undo never touches the server.
- Trade-off
- I built and tested the queue before any feature wrote through it. That was a slower start, but no knocks have been lost.
Decision 05
Routes copy the team, not a textbook
The generator follows the eight walking rules from the team's drawings, and it's deterministic.
- Why
- Adoption. A route that changes how people knock gets ignored. Fixed rules also keep visits comparable over time.
- Trade-off
- It isn't the shortest possible route. 26% backtracking was measured and left for later, data-driven optimisation.
Decision 08
No door claiming between partners
Removed the claim, reserve and "Take" system I'd already built.
- Why
- Partners leapfrog to the next free door. Locking doors to one person fought how the job works.
- Trade-off
- Two offline phones can log the same door now and then. The app flags it after sync, and coverage counts distinct doors.
Decision 10
Live location: current position only
Managers see where teams are right now. There is no trail and no history, ever.
- Why
- Canvassers are self-employed, and ICO guidance on monitoring workers asks for the least intrusive means. So there's a visible Sharing pill and a one-tap Stop that changes nothing else.
- Trade-off
- Managers can't replay a day. A DPIA and a legitimate-interests assessment are required before wider rollout.
Outcome
Adopted across the region
The pilot started in one office. The app is now used daily by 60+ canvassers across every branch in the South West, and talks about expanding further are under way.
What changed day to day
For managers
Props planned from history
Instead of "that area's dead", a slow prop becomes a plan: rotate the start, return to a good area, finish what was missed last time.
For managers
Coaching from real numbers
Contact-to-lead ratios per person turn "pick it up" into specific coaching, framed as support, not policing.
For canvassers
No more "who goes where"
The route is drawn before the team arrives. New starters follow it instead of shadowing someone for weeks.
For the office
Complete survey data
The tap is the address: no missing house numbers or street names, and lead outcomes flow back from the CRM every night.
Reflections
What I'd do differently
Being the user and the builder was the advantage, and occasionally the blind spot.
Next time
Start with the job, not the data
The scoring prototype answered a question nobody was asking. A week of writing down what was actually slow would have pointed straight at memory and logging.
Next time
Ask how people walk before writing an algorithm
I built a textbook traversal first, and only then asked the team to draw their routes. Their drawings were the spec all along.
Next time
Do the privacy paperwork alongside the feature
Location sharing shipped with strong technical limits but ahead of its written assessment. That's fine for a pilot, but not for a national rollout.