React project with qr scanning
Budget: $30 – $250 USD
Our budget. 100 dollars.
Phase 1 – Login and User Management (phase 1 is 95 % done)
We need a web-based backend system where we, as super administrators, can:
• Create new organizations (companies)
• Create the first administrator user for each organization
• Automatically send an email with login details to the new administrator
Organization administrators must be able to:
• Log in securely
• Create and manage users (with roles: administrator or user)
• Create and manage departments
• Change password and email
• All user access must be handled securely, using session management (e.g. JWT or similar)
⸻
Phase 2 – Checklists and Reporting
Administrators must be able to:
• Create checklists per department (e.g. fire extinguishers, playgrounds, vehicles, etc.)
• Set control intervals: weekly, every 14 days, monthly, every 2, 3, 6 months, yearly or every 2 years
• Set buffer days – for example, a checklist turns orange 16 days before the due date
Users must be able to:
• Complete checklists
• Mark each item as “Approved” or “Not Approved” with optional comments and pictures
The system must:
• Visually mark checklists as green (completed), orange (upcoming), or red (overdue)
• Store all data securely in the database
• Allow download or export of completed checklists as PDF reports
⸻
About checklists: Completion and Report Locking Logic
A user selects a checklist for fire extinguisher inspection. In this case, the checklist includes 35 fire extinguishers located within a specific area. The user walks around and checks each extinguisher one by one. For every extinguisher, the user must mark the result as either:
• Approved or
• Not approved
Once all extinguishers have been reviewed and a result has been recorded for each, the user confirms the entire checklist as completed. At this point, a final report is generated and permanently locked.
The user uses his smartphone to check every e.g. fire extinguishers. We place a uniq QR code on each item and the user can scan and approve or not approve every fire extinguisher. The QR code shall be easy to print, change etc. for every item.
The report cannot be reopened or edited after submission.
It is critical that the final report:
• Is fully completed
• Cannot be altered
• Remains unaffected by future changes to users, equipment, or checklist templates
This means that:
• If a user is later deleted
• If an extinguisher is removed, renamed, or added to the checklist template
• Or if other structural changes are made
→ the completed report stays unchanged and intact.
⸻
Technical Summary:
• Each control/checklist is based on a master template stored under the department
• When a user starts a checklist, a snapshot of the master is taken and stored
• Once completed, the report is stored as a locked instance
• Completed reports are immutable for audit and compliance purposes
⸻
Specification: Inspection System for Region Holbæk
⸻
1. System Structure and User Roles
1.1 Organization
• Company: “Region Holbæk”
• Subunits: “Areas” (Høng, Kalundborg, Holbæk Midtby, Holbæk Vest, Taastrup 061, Taastrup 010)
• An “Area” can contain multiple “Departments”
• Example: The area “Taastrup 061” includes the departments: Rugvænget, Parkvej, Teglstenen, Pælestykket
1.2 Roles
Team Leader (Administrator): Has access to their own departments and can:
• Create and delete users (inspectors) who perform inspections
• Promote users to administrator level
• Create departments
• Create and edit master controls (templates)
• Perform inspections
• View and manage reports
Inspector (User):
• Can complete and submit inspections based on existing templates
⸻
2. Functionality
2.0 Inspector Web App (Mobile)
• The inspector uses a mobile-friendly web app (optimized for iPhone and Android)
• Inspections can be started by scanning a QR code or NFC tag on-site
• As the inspector walks from one inspection item to the next (e.g. from stairwell to stairwell), they:
• View which items are completed, remaining, or skipped
• Navigate using arrows (next/previous) or select directly from an item overview
• The system ensures maximum usability and responsiveness on small screens
2.1 Master Control / Template
• The team leader creates a master control for each inspection type (e.g. Fire Extinguishers)
• A master includes:
• Inspection type (e.g. Fire Extinguishers, Community Room, etc.)
• Inspection items (list of Item + Location)
• Inspection interval (e.g. every 6 months)
• Master controls can be adjusted (frequency, number of items) and apply going forward
• Existing reports are not affected by changes to the master control
2.2 Creating an Inspection
• An inspector or team leader starts a new inspection from a master control
• A control instance is created with:
• Start timestamp
• A copy of the item list from the master control
2.3 Completing an Inspection Report
• For each line (item) in the inspection:
• Item and location are pre-filled (from master)
• Inspector enters:
• Note (mandatory if “Not Approved”)
• Status: “Approved” / “Not Approved”
• Date and time are recorded automatically based on the action timestamp
• The inspection can only be saved as a final report when all items are marked and notes are entered where required
2.4 Finalizing the Report and PDF Generation
• Upon completion:
• The report is locked
• A PDF is generated containing:
• Inspection type, date, time, inspector, department
• Total number of items
• Number of approved / not approved items
• Full list of items with all fields
• Reports cannot be edited after they are saved
2.5 Report Overview and Follow-Up
• Overview shows:
• List of all reports
• Reports with “Not Approved” items are clearly marked
• To remove the marking, the team leader must:
• Enter a follow-up date
• Write a follow-up note
2.6 Inspection Types per Department
• Each department can have different inspection types
• Examples:
• Rugvænget: Fire Extinguishers, Community Room
• Parkvej: Fire Extinguishers, Playgrounds, Dry Risers, Community Room, Vehicles, Power Tools
• Teglstenen: Vehicles
• Pælestykket: Community Room
2.7 Inspection Frequencies
• Fire Extinguishers: Twice a year
• Playgrounds: Once a year
• Dry Risers: Once a year
• Community Rooms: Once a year
• Power Tools: Every 4 months
• Vehicles: Once a year
2.8 Next Inspection Date
• The team leader must be able to manually adjust the next planned inspection date
• This should not affect previously completed reports
⸻
3. Technical Requirements
3.1 Database Model (Main Objects)
• Organization
• Area
• Department
• User (role: team leader / inspector)
• Master Control (template)
• Inspection Items (item + location)
• Inspection Instance (active inspection)
• Inspection Report (PDF + metadata)
• Follow-Up (date + note)
3.2 Locking and History
• Report data must be saved as immutable snapshots
• Editing is done in the master template – not in completed reports
3.3 File Management
• PDF reports are saved per report with filenames that include department, date, and inspection type
• PDF files can be downloaded via the report overwork
⸻
We work GMT time. Payment when job is testet and approved from us.
Phase 1 – Login and User Management (phase 1 is 95 % done)
We need a web-based backend system where we, as super administrators, can:
• Create new organizations (companies)
• Create the first administrator user for each organization
• Automatically send an email with login details to the new administrator
Organization administrators must be able to:
• Log in securely
• Create and manage users (with roles: administrator or user)
• Create and manage departments
• Change password and email
• All user access must be handled securely, using session management (e.g. JWT or similar)
⸻
Phase 2 – Checklists and Reporting
Administrators must be able to:
• Create checklists per department (e.g. fire extinguishers, playgrounds, vehicles, etc.)
• Set control intervals: weekly, every 14 days, monthly, every 2, 3, 6 months, yearly or every 2 years
• Set buffer days – for example, a checklist turns orange 16 days before the due date
Users must be able to:
• Complete checklists
• Mark each item as “Approved” or “Not Approved” with optional comments and pictures
The system must:
• Visually mark checklists as green (completed), orange (upcoming), or red (overdue)
• Store all data securely in the database
• Allow download or export of completed checklists as PDF reports
⸻
About checklists: Completion and Report Locking Logic
A user selects a checklist for fire extinguisher inspection. In this case, the checklist includes 35 fire extinguishers located within a specific area. The user walks around and checks each extinguisher one by one. For every extinguisher, the user must mark the result as either:
• Approved or
• Not approved
Once all extinguishers have been reviewed and a result has been recorded for each, the user confirms the entire checklist as completed. At this point, a final report is generated and permanently locked.
The user uses his smartphone to check every e.g. fire extinguishers. We place a uniq QR code on each item and the user can scan and approve or not approve every fire extinguisher. The QR code shall be easy to print, change etc. for every item.
The report cannot be reopened or edited after submission.
It is critical that the final report:
• Is fully completed
• Cannot be altered
• Remains unaffected by future changes to users, equipment, or checklist templates
This means that:
• If a user is later deleted
• If an extinguisher is removed, renamed, or added to the checklist template
• Or if other structural changes are made
→ the completed report stays unchanged and intact.
⸻
Technical Summary:
• Each control/checklist is based on a master template stored under the department
• When a user starts a checklist, a snapshot of the master is taken and stored
• Once completed, the report is stored as a locked instance
• Completed reports are immutable for audit and compliance purposes
⸻
Specification: Inspection System for Region Holbæk
⸻
1. System Structure and User Roles
1.1 Organization
• Company: “Region Holbæk”
• Subunits: “Areas” (Høng, Kalundborg, Holbæk Midtby, Holbæk Vest, Taastrup 061, Taastrup 010)
• An “Area” can contain multiple “Departments”
• Example: The area “Taastrup 061” includes the departments: Rugvænget, Parkvej, Teglstenen, Pælestykket
1.2 Roles
Team Leader (Administrator): Has access to their own departments and can:
• Create and delete users (inspectors) who perform inspections
• Promote users to administrator level
• Create departments
• Create and edit master controls (templates)
• Perform inspections
• View and manage reports
Inspector (User):
• Can complete and submit inspections based on existing templates
⸻
2. Functionality
2.0 Inspector Web App (Mobile)
• The inspector uses a mobile-friendly web app (optimized for iPhone and Android)
• Inspections can be started by scanning a QR code or NFC tag on-site
• As the inspector walks from one inspection item to the next (e.g. from stairwell to stairwell), they:
• View which items are completed, remaining, or skipped
• Navigate using arrows (next/previous) or select directly from an item overview
• The system ensures maximum usability and responsiveness on small screens
2.1 Master Control / Template
• The team leader creates a master control for each inspection type (e.g. Fire Extinguishers)
• A master includes:
• Inspection type (e.g. Fire Extinguishers, Community Room, etc.)
• Inspection items (list of Item + Location)
• Inspection interval (e.g. every 6 months)
• Master controls can be adjusted (frequency, number of items) and apply going forward
• Existing reports are not affected by changes to the master control
2.2 Creating an Inspection
• An inspector or team leader starts a new inspection from a master control
• A control instance is created with:
• Start timestamp
• A copy of the item list from the master control
2.3 Completing an Inspection Report
• For each line (item) in the inspection:
• Item and location are pre-filled (from master)
• Inspector enters:
• Note (mandatory if “Not Approved”)
• Status: “Approved” / “Not Approved”
• Date and time are recorded automatically based on the action timestamp
• The inspection can only be saved as a final report when all items are marked and notes are entered where required
2.4 Finalizing the Report and PDF Generation
• Upon completion:
• The report is locked
• A PDF is generated containing:
• Inspection type, date, time, inspector, department
• Total number of items
• Number of approved / not approved items
• Full list of items with all fields
• Reports cannot be edited after they are saved
2.5 Report Overview and Follow-Up
• Overview shows:
• List of all reports
• Reports with “Not Approved” items are clearly marked
• To remove the marking, the team leader must:
• Enter a follow-up date
• Write a follow-up note
2.6 Inspection Types per Department
• Each department can have different inspection types
• Examples:
• Rugvænget: Fire Extinguishers, Community Room
• Parkvej: Fire Extinguishers, Playgrounds, Dry Risers, Community Room, Vehicles, Power Tools
• Teglstenen: Vehicles
• Pælestykket: Community Room
2.7 Inspection Frequencies
• Fire Extinguishers: Twice a year
• Playgrounds: Once a year
• Dry Risers: Once a year
• Community Rooms: Once a year
• Power Tools: Every 4 months
• Vehicles: Once a year
2.8 Next Inspection Date
• The team leader must be able to manually adjust the next planned inspection date
• This should not affect previously completed reports
⸻
3. Technical Requirements
3.1 Database Model (Main Objects)
• Organization
• Area
• Department
• User (role: team leader / inspector)
• Master Control (template)
• Inspection Items (item + location)
• Inspection Instance (active inspection)
• Inspection Report (PDF + metadata)
• Follow-Up (date + note)
3.2 Locking and History
• Report data must be saved as immutable snapshots
• Editing is done in the master template – not in completed reports
3.3 File Management
• PDF reports are saved per report with filenames that include department, date, and inspection type
• PDF files can be downloaded via the report overwork
⸻
We work GMT time. Payment when job is testet and approved from us.