Build a Citizen Request Tracker with React, FastAPI and PostgreSQL

Build a Citizen Request Tracker with React, FastAPI and PostgreSQL Product overview script Narration: 605 words, about 4 min 39 s at 130 words per minute SCENE 1: The problem VISUAL: a busy council contact centre, agents on phones beside a wall map pinned with potholes and broken streetlights NARRATION: Larkmoor City Council is a fictional town council with a very real problem. Residents report potholes, broken streetlights and missed bin collections by phone or email. Nobody receives a reference number, so there is nothing to follow up with. A third of all calls to the contact centre simply ask for an update. SCENE 2: Who it is for VISUAL: a resident checking a phone at a bus stop, intercut with a case officer at a desk reviewing a laptop NARRATION: Three groups of people lose time to this problem every single day. Citizens want to report a problem once and know that it is being handled. Contact centre agents want fewer repeat calls, so they can help people with new issues. Case officers in the Neighbourhood Services team need a simple way to post updates. And every update should reach the citizen without another phone call. SCENE 3: Reporting an issue VISUAL: a phone showing a short report form, then a confirmation panel with a large reference number and a target date NARRATION: The answer is Larkmoor Citizen Desk, a small public web application for the council. A citizen picks a category, then describes the location and what is wrong. They press submit and receive a reference number straight away. They also see a target date, so they know when to expect a fix. There is no account to create and no password to remember. SCENE 4: Tracking progress VISUAL: a tracking page with a coloured status badge and a vertical timeline of dated notes from the council NARRATION: Later, the citizen types their reference number into the tracking page. They see the current status, the target date and every update in order. Each update carries a short note that the council wrote for the citizen. Case officers move each request from Submitted to In review, Scheduled and Resolved. When the council cannot help, the request is marked Not actioned, with an explanation. In this lab, case officers make updates through the service's built in documentation page. SCENE 5: The business rules VISUAL: a report form with friendly error messages under each field, beside a calendar with a target date circled NARRATION: Behind the screens, clear business rules keep every request clean and predictable. Every field is checked in the browser and then checked again on the server. If anything is wrong, the citizen sees every problem at once, in plain English. Target dates come from the category, such as five days for a pothole. A missed bin collection gets two days, and graffiti removal gets ten. Status changes follow a fixed path, and a closed request can never be reopened. Marking a request Not actioned always requires a note for the citizen. SCENE 6: Privacy and reliability VISUAL: a case card showing status and timeline, with the citizen's name and email visibly left out and a small padlock icon NARRATION: Anyone who holds a reference number can open the tracking page. So the tracking view never shows the citizen's name or email address. Each new request and its first history entry are saved together, or not at all. Both screens work on a phone, and both can be used with the keyboard alone. If the service is down, citizens see a friendly message and a retry button. SCENE 7: What you build VISUAL: a split screen showing a web page, a Python service log and a database table of service requests NARRATION: You build Larkmoor Citizen Desk from a starter project in about three hours. The theme, setup scripts and tests are ready, so you focus on real logic. On the front end, you build two React screens for reporting and tracking. In the middle, a Python web service built with FastAPI applies the rules. Underneath, a PostgreSQL database stores categories, requests and the full status history. Setup steps cover Windows and macOS, and the database works with or without a password. SCENE 8: What you take away VISUAL: a developer smiling at a screen of passing tests, with the finished app open on a second monitor NARRATION: Along the way, you practise skills that employers expect from a junior full stack engineer. You handle forms and data loading in React, and validation in FastAPI. You design a clean web API that returns the right status for every situation. You write safe database queries and use transactions to keep data consistent. Automated tests on both sides prove that every rule really works. The finished project is a complete feature you can demo and explain in an interview. SCENE 9: Start building VISUAL: the Larkmoor Citizen Desk report screen on a laptop, with a bright start button below it NARRATION: This lab is called Build a Citizen Request Tracker with React, FastAPI and PostgreSQL. Start today, and ship your first full stack feature from the form to the database.