What this series is about

This is the first article in a twelve-part series that builds one thing from nothing to finished: a camera for your front door that recognises the people it knows, greets them by name, asks a stranger who they are, and tells you on your phone if someone you have flagged turns up. By the end of the series you will have a working device sitting in a weatherproof box by your door, built on a Raspberry Pi, running entirely on software you understand because you wrote or configured every part of it.

Before we touch any hardware or write any code, we need to agree on two things: what the finished project actually does, in plain terms, and what rules apply to pointing a camera at a doorway where people you have not asked permission from will walk past. The second point is not a footnote. Recognising faces is different from counting cars or measuring temperature. It involves other people's images, stored on a device in your house, and that brings real obligations. This article covers both: the shape of the project, and the rules that will shape every design decision in the parts that follow.

A walk through a finished visit

It helps to picture the finished system working before we talk about how any of it is built. Imagine three visits to a front door fitted with the Doorstep Greeter.

First visit: your neighbour walks up to drop off a parcel while you are out. A small motion sensor by the door wakes the camera from a low-power sleep. The camera finds a face in the frame, works out that this is a face it has seen before and been given permission to recognise, and plays a short spoken greeting through a speaker: "Hello, the house is empty at the moment, but I'll let them know you came by." A note with a time-stamped snapshot appears in a log on a small dashboard you can check later from your phone or laptop.

Second visit: someone the camera has never seen walks up. The system detects a face, does not find a confident match against anyone it knows, and instead of guessing, asks a simple question through the speaker: "Hello, I don't think we've met. Would you like to tell me your name, so I can let the house know you called?" If the visitor answers and agrees, their face and name are stored for next time. If they say nothing, or decline, nothing is kept beyond the ordinary short-term recording that any doorbell camera makes.

Third visit: a face matches someone you specifically marked, at some earlier point, as a person you want to know about if they come to your door. No greeting is played, no action is taken by the device itself. A notification simply appears on your phone: "A flagged visitor was seen at 14:32." What you do with that information is entirely up to you. The camera never locks a door, calls anyone, or takes any action beyond telling you.

Those three visits touch almost everything the series builds: motion sensing, face detection, face recognition, a voice, a way of adding new people with their agreement, a flagging system controlled only by you, and a log you can review and clear. The remaining parts of this series build each piece in turn, finishing with the complete device mounted and running at a real front door.

Why this runs on a small computer at your door, not in the cloud

A natural question is why the project is built around a Raspberry Pi sitting physically at the door, rather than a cheap camera that streams video to a phone app and does the clever work on a company's servers. Many commercial doorbell cameras do exactly that, and it is a reasonable choice for a product sold to millions of people. For a project you build and fully understand yourself, there are three good reasons to keep everything local.

  • Privacy by construction. If face images and the list of known people never leave the device, there is no cloud account to be hacked, no company policy to change, and no third party that ever sees your visitors' faces. The data stays where you can see it, in a file you control.
  • Control over deletion. When this series covers deleting a person's data or automatically expiring old records, that only means something simple and certain if the data lives in one SQLite database file on one device, not scattered across a vendor's servers and backups.
  • No dependence on an internet connection or a subscription. The device works the same way whether your broadband is up or down, and keeps working for as long as the hardware does, without a company deciding to discontinue the service.

The trade-off is that a Raspberry Pi has to do real work; it needs a capable enough processor, or a small add-on accelerator, to detect and recognise faces in something close to real time. Part 2 of this series goes through the hardware choices in detail, including the Raspberry Pi 5, an AI accelerator add-on, the camera module, and an enclosure that keeps rain out. For now, the point to take away is a design principle that will come up again and again: faces are recognised on the device itself, and nothing about a visitor's appearance is sent anywhere unless you deliberately choose to.

The shape of the project, part by part

It helps to know roughly where this is all going, without getting ahead of parts that explain things properly when their turn comes. After this article, the series covers the hardware in detail, then explains how face recognition actually works under the hood (detection, alignment, the embeddings that represent a face as a list of numbers, and matching), before moving into hands-on parts: setting up the Raspberry Pi and camera, detecting faces in real time, recognising known people, giving the device a voice, handling new visitors and consent, sending flagged-visitor alerts to your phone, coping with night and bad weather, defending against someone holding up a photo to fool the camera, and finally assembling everything into a dashboard-backed device ready to mount at a real door.

Two things are deliberately placed early, before any hardware or code: this article, and the next one on choosing hardware. The reason is that the rules in this article, and the physical realities of the hardware in the next, constrain almost every decision later in the series. It is much easier to design a system that respects people's privacy from the start than to bolt privacy on afterwards, so we start there.

The rules for filming people at your door

A camera at your front door is pointed, almost by definition, at a space other people walk through: your postal worker, delivery drivers, neighbours, canvassers, trick-or-treaters, people collecting for charity, and sometimes people you would rather not have at your door at all. None of them chose to be filmed by you. Some of what follows is simple good manners. Some of it is law, in a general sense that applies across the UK, the EU, and much of the US, though the precise detail differs by country and by US state. None of this is legal advice for your specific situation; treat it as a map of the main issues to check against the rules that actually apply where you live, and against your own household's values about privacy.

Detection is not the same as recognition, and that distinction matters legally

It is worth being precise about two different things a camera can do, because the rules treat them very differently.

  • Face detection answers the question "is there a face in this image, and roughly where?" It does not know or care whose face it is. A huge number of ordinary cameras, including the autofocus system in most phone cameras, do this constantly, and it is generally treated the same as any other video recording.
  • Face recognition answers the question "whose face is this, out of a list of people I already know?" To do that, the system has to turn a face into a stable numerical description (an embedding, covered properly in part 3) and compare it against stored descriptions of known people. That stored description of a specific person's face is biometric data: information that can identify a particular individual from a physical characteristic.

Biometric data gets special treatment in data protection law precisely because a face, unlike a password, cannot be changed if it is misused. Under the UK and EU General Data Protection Regulation (GDPR), biometric data used to identify a specific person is a category of data that requires a clear legal basis beyond the ordinary justification for processing personal data in general, and consent is the most natural basis for a home project like this one. In the United States there is no single federal law covering biometric data, but several states have their own: Illinois has the Biometric Information Privacy Act (BIPA), which requires informed consent before collecting things like faceprints and sets rules around how long such data can be kept, and other states including Texas and Washington have their own biometric privacy statutes with broadly similar aims. The exact wording, thresholds, and penalties differ from place to place, and they change over time, so check the current rules for your own country or state rather than relying on a general description like this one, and if you plan to use anything like this beyond your own household, get proper legal advice.

The practical consequence for this project is simple to state even if the law behind it is not: detection (there is a face) can happen for anyone who walks up, because it never identifies a specific person. Recognition, and storing the data that makes recognition possible, only happens for people who have agreed to it. That single rule shapes the design of part 8, where the device asks a new visitor for their name and their consent before it remembers their face at all.

Tell people a camera is in use

Across UK and EU data protection guidance, and as a matter of simple fairness, people who might be filmed should be told that a camera is there before they are filmed, not after. For a doorbell camera this usually means a small, clearly visible sign near the door, stating that a camera and audio or voice system is in operation, roughly what it is used for, and who to contact with questions. This is sometimes called "fair processing" or "transparency" in data protection guidance: people cannot meaningfully agree to anything, or object to anything, if they do not know it is happening.

A sign is not a formality to satisfy a regulator; it does real work. Someone who sees a sign saying a camera recognises faces and asks new visitors for their name is not surprised when the device speaks to them, and is in a position to decide not to approach the door at all if they would rather not be recorded. That is a meaningfully different situation from a hidden camera silently building a database of everyone who walks past. Later in this series, when we design the voice interaction in part 7 and the consent flow in part 8, the signage and the spoken introduction work together: the sign tells people before they arrive, and the greeting itself can briefly restate it for anyone who missed the sign.

Only store a face after the person agrees to it

This is the single most important design rule in the whole series, so it is worth stating plainly: a visitor's face is only stored in a way that lets the system recognise them again if that visitor has said yes. Nobody is enrolled silently, and nobody is enrolled because they happened to be a frequent visitor, a family member assumed it was fine on their behalf, or the camera simply saw their face often enough to build a profile automatically. Consent has to be an active, informed choice made by the person whose face it is.

In practice, part 8 of this series builds a short, spoken exchange: the device explains briefly what it is doing, asks for a name, and asks a direct question along the lines of "can I remember your face for next time?" Only a clear yes leads to the face being stored. A no, silence, or anything else means the visit is treated like any other anonymous visit: detected, perhaps logged as a snapshot for your own short-term review in the way any doorbell camera would, but not turned into a named, recognisable entry in the system.

There is a harder case worth naming now, because it comes up with every family that builds something like this: what about children, or visitors who are not in a position to give meaningful consent, such as a very young child or someone who cannot understand what is being asked? The honest answer is that the device should not attempt to enrol anyone who cannot give informed agreement, and a responsible household should set its own policy here, generally erring towards not storing faces of children and routing any such cases to a human decision in the house rather than to the camera's own judgement. This is one of several points where the series gives you the tools, but the policy decisions belong to you, the person running the device at your own front door.

Keep data for a limited time, and delete it on request

GDPR's storage limitation principle says, in plain terms, that you should not keep personal data for longer than you actually need it for the purpose you collected it for. BIPA, in the jurisdictions where it applies, requires a written retention schedule and deletion once the purpose for collecting biometric data has been satisfied or within a set time, whichever comes first. Translating that into a home project gives two concrete features that this series builds, in part 12 in full and touched on earlier: an automatic retention limit, so that a face record that has not been seen again after some period you choose (a sensible starting point might be a year, but it is your decision) is deleted automatically rather than sitting in the database forever, and a manual deletion request, so that if someone who was enrolled asks you to remove them, you can do that completely, not just hide them from a list while the underlying face data remains.

There is a practical reason to care about this beyond the law: a database of faces that only grows is a liability sitting on a device in your porch. Every record you do not need is a record that could be exposed if the device were ever stolen or compromised. Part 12 also covers encrypting the data at rest where the hardware supports it, which reduces, though does not eliminate, that risk.

Point the camera at your doorstep, not at the street

UK data protection guidance for home CCTV and doorbell cameras is fairly specific on this point: a camera used for domestic purposes, such as protecting your own home, is generally outside the full scope of GDPR under what is sometimes called the household exemption, but that exemption weakens or stops applying the moment the camera's field of view captures a meaningful amount of neighbouring property, a shared path, or a public pavement that other people use to go about their business, rather than just your own entrance. The general principle, and good manners besides, is to angle and position the camera so that it covers your doorstep and the direct approach to your door, and as little as reasonably possible of your neighbour's garden, their windows, or a public footpath that people use to walk past without any intention of visiting you.

In practice this is as much a hardware and installation decision as a legal one, and it comes up again in part 2 when choosing the camera's field of view, and in part 12 when mounting the finished device. A camera with a narrow field of view pointed down at the doorstep captures what you actually need, people standing at your door, and naturally avoids capturing a wide strip of street or a neighbour's front window. If your door faces directly onto a busy pavement and there is no way to avoid capturing passers-by who have no intention of visiting, that is worth thinking through carefully, and in some cases worth discussing with neighbours whose property might be visible, before you install anything.

A quick checklist before you build anything

  • Put up a clear, visible sign near the door explaining that a camera and voice system is in use, before you record anyone.
  • Only store a face, with a name attached, after that specific person has given a clear yes.
  • Keep the list of known people and their face data on the device itself, not uploaded to a third party.
  • Set an automatic limit on how long a face record is kept if the person has not been seen again, and delete it after that.
  • Honour a deletion request completely and promptly if someone asks to be removed.
  • Aim the camera at your own doorstep, and avoid capturing more of a public pavement or a neighbour's property than you need to see who is at your door.
  • Check the specific rules that apply in your own country or US state, since this article describes general principles, not a complete legal summary, and the details (thresholds, required notices, penalties) vary and change over time.

Flagged visitors: a human decision, never the model's

One feature of the finished project deserves a section of its own, because it is the part most likely to be misunderstood or misused if it is not designed carefully: the ability to flag a visitor so that you get a phone alert if they turn up.

The design rule is simple and non-negotiable throughout this series: the system itself never decides that someone is worth flagging. It has no concept of a suspicious face, an unwanted face, or a dangerous face. The only people who ever get flagged are people you, the owner of the device, have explicitly added to a flagged list, by name, after they have already been enrolled as a known person through the ordinary consent process described above. Perhaps it is a relative you want to know has arrived even if you are upstairs. Perhaps it is someone who has called at your door repeatedly trying to sell something you have already declined several times, and you would simply like a moment's warning before answering. The reasons are yours, and they stay in your household. The device's only job, when a flagged face matches, is to send a notification to your phone saying a flagged visitor was seen, with a time and a snapshot. It does not lock a door, sound an alarm, contact anyone else, or take any action of its own. What you do with that notification is entirely a decision you make as a person, not something the software decides for you.

This matters because face recognition systems make mistakes, and it is important to understand the shape of those mistakes before you build anything that acts on a match. A match from a face recognition system is a statement of similarity, not a statement of certainty: the system found that a detected face's numerical description is close enough to a stored description to clear a threshold you (or a sensible default) set. Two different kinds of error are possible, and they trade off against each other.

  • A false match: the system says a face belongs to a known or flagged person, when it is actually someone else. This becomes more likely in poor lighting, at odd camera angles, with a face partially obscured by a hat, mask or scarf, or when two people genuinely do look similar.
  • A false non-match: the system fails to recognise someone it has actually been enrolled to know, because the lighting has changed, the person is wearing glasses they were not wearing when enrolled, or they have aged or changed their hairstyle since enrolment.

It is also well documented in independent research on commercial face recognition systems that accuracy is not evenly spread across everyone: error rates can differ by skin tone, by lighting conditions typical of different times of day, by age, and by sex, often because the systems (and the photographs used to build and test them) were not equally representative of everyone who might stand in front of a camera. This series does not claim to fix that problem; no home project can. What it does instead, throughout later parts, is build in habits that reduce the damage any single error can do: a sensible, adjustable matching threshold rather than an aggressively low one that maximises matches at the cost of false positives, a short cool-down so the same face is not repeatedly re-processed in noisy conditions, clear logging so you can see what the system actually matched and when, and the firm rule that a match is an input to a human decision, never an automatic trigger. A flagged-visitor alert should be read as "the system thinks this might be the person you flagged, go and check if you care," not as "this is confirmed to be that person."

Part 9 of this series builds the flagging and alerting feature in full, including how the matching threshold works and how to review and correct mistakes. Part 11 covers a related but distinct problem: stopping someone from fooling the camera altogether by holding up a photograph or a video of a known person's face. Keep both of those limitations in mind as a theme that runs through the whole project: the camera observes and suggests, and a person decides.

Designing for trust, not just for accuracy

It is tempting, when building something like this, to focus entirely on making the face recognition as accurate as possible and treat everything in this article as a compliance chore to get through before the interesting engineering starts. It is worth resisting that framing. A doorbell that recognises faces sits at your front door, in full view of everyone who visits your home, and how it behaves says something about the kind of household it belongs to. A device that is upfront about what it is doing, asks before it remembers someone, and gives people a straightforward way to be forgotten, is not just more defensible legally; it is also simply a better thing to have stood between you and the people who knock on your door. Several of the design choices later in this series, a sign that matches what the device actually says, a voice that explains itself briefly rather than silently judging, a dashboard where you can see and delete exactly what has been stored, exist because that kind of straightforwardness is the actual goal, not a constraint imposed on top of the goal.

What comes next

This article set out what the finished Doorstep Greeter does, in the form of three example visits, and laid out the rules that will govern its design from here on: tell people a camera is in use, only store a face with that person's agreement, keep everything on the device, delete data on request and after a reasonable time limit automatically, avoid filming more of the street or your neighbours than you need to, and treat every flagged-visitor match as something a human checks, never something the software acts on by itself.

Part 2 moves from rules to hardware: it goes through the Raspberry Pi 5 with 8 GB of memory, the AI HAT+ accelerator that makes real-time face recognition practical on a Pi (and the NVIDIA Jetson Orin Nano as an alternative board), the Camera Module 3 and its NoIR variant for night use, a small speaker, a PIR motion sensor to wake the camera, the power supply, the microSD card, and an enclosure that will keep the whole thing dry and working outdoors, with approximate prices for each part and a clear note that prices vary by region and over time. From there, part 3 explains how face recognition actually works, detection, alignment, embeddings and matching, so that by the time the hands-on parts begin in part 4, you understand not just how to type the commands but why each step exists.