1. Summary
CrewBoard is a one-click Windows tool that reads the depot's fixed-format crew-board PDFs and turns them into shift data. Before it, staff re-keyed each crew board by hand every shift, a multi-hour task that introduced transcription errors. CrewBoard cut that to minutes per shift and removed the transcription errors, without changing the PDF, the source system or anyone's training.
2. Problem and context
Who has the problem. Depot operations staff at Mowasalat (Karwa), Qatar's government public transport company, who prepare shift data from crew boards.
What it costs them.
- Every shift, the crew board arrives as a fixed-format PDF, and someone re-keys it into shift data by hand.
- That re-keying took hours per shift and was error-prone. Transcription errors flowed into shift preparation.
The constraint. IT said the PDF format couldn't change. Any fix had to work with the PDFs exactly as they are.
Discovery
I spoke directly to the depot operations manager to understand the task, where the time went and where errors came from. IT's answer that the PDF couldn't change ruled out fixing the problem at the source. Two delivery options were left: a server-based tool or a desktop tool. I chose a one-click .exe over a server so nobody needed training. Assumption: a desktop tool also avoided the approvals, hosting and maintenance a new server would have needed.
3. Users and personas
| Persona | Need |
|---|---|
| Depot scheduler (primary user) | Turn the shift's crew-board PDF into usable shift data quickly and without errors |
| Depot operations manager | Reliable shift readiness and less staff time lost to re-keying |
| IT | No change to the PDF or the source system, and nothing new to host |
Assumption: the primary users are the schedulers who did the re-keying.
4. Goals and non-goals
Goals
- Cut crew-board processing from hours to minutes per shift.
- Remove transcription errors.
- Need no training: one click.
- Need no change to the PDF, the source system or IT infrastructure.
Non-goals
- Changing how crew boards are produced.
- A server or web application.
- Scheduling optimisation or rostering decisions.
5. Requirements
Functional requirements
C-1. Extract. As a scheduler, I want to open the shift's crew-board PDF and get its contents as structured shift data.
- The tool reads the PDF as issued; no reformatting is needed.
- Text is extracted automatically and restructured into shift data.
C-2. Orientation. As a scheduler, I want to control the orientation of the extracted data, so that it matches how I read the board.
C-3. Views. As a scheduler, I want to expand and collapse parts of the result, so that I can check one section at a time.
C-4. One click. As a scheduler, I want to start the tool with one click, without installing or configuring anything.
Non-functional requirements
| Area | Requirement |
|---|---|
| Deployment | A standalone Windows executable, compiled through GitHub; no server |
| Usability | One click; no training needed |
| Accuracy | No transcription errors from re-keying |
| Performance | Minutes per shift instead of hours |
| Privacy | Assumption: crew data is processed locally on the PC and not sent anywhere |
6. Solution overview and architecture
Build and delivery. Written in Python with FastAPI service logic and pdfplumber for extraction, built with Codex, and compiled into a Windows .exe through GitHub. Assumption: the FastAPI service runs locally inside the executable and serves the desktop interface.
7. AI design
Assumption: CrewBoard has no AI model at runtime. Extraction with pdfplumber is deterministic, which suits a task where every value must be exact. AI was used to build it: the code was written with Codex.
8. Success metrics
Confirmed
- A multi-hour re-keying task cut to minutes per shift.
- Transcription errors removed.
Metrics to track
- Processing time per shift
- Errors found in shift data
- Shifts processed with CrewBoard, as a share of all shifts
- Number of depots or users using it
9. Release history and roadmap
| When | Release |
|---|---|
| 2025 | CrewBoard built and put into use in depot operations |
10. Risks and open questions
Risks
- Layout drift. The PDF format can't be changed on request, but a future change to the source system could still alter the layout and break extraction.
- Single maintainer. One person built the tool. Assumption: the same person maintains it.
- Executable policies. Assumption: Windows security policies may block or warn on an unsigned executable.
- Updates. A desktop tool has to be redistributed to each PC when it changes.
Open questions
- Should the tool flag when a PDF doesn't match the expected layout, instead of producing partial data?
- Is it worth extending to other fixed-format reports in depot operations?
11. My role
- Product owner and solo builder.
- Ran discovery directly with the depot operations manager.
- Worked within IT's constraint that the PDF couldn't change.
- Chose a one-click .exe over a server so nobody needed training.
- Built it in Python with FastAPI and pdfplumber, using Codex, and compiled it through GitHub.