Senior Project
Safe Future Barcode for Good
Project Information
- Client
- Safe Future Foundation
- Client contact
- Chris Tobey
- Project type
- Year-long UNF senior capstone
- Project name
- Safe Future Barcode for Good
- Role
- Student developer on a team-based client project
- Focus areas
- QR workflow, CSV export, error handling, requirements iteration
- Process
- Scrum, Jira, recurring client meetings, class demos
Overview
For my senior project at the University of North Florida, I worked on a year-long team engagement with Safe Future Foundation, a Jacksonville nonprofit. Rather than building a hypothetical class project, our team served as an unpaid development team for a real client and worked on a web-based inventory system designed to improve how donated goods were tracked, labeled, and managed.
The project focused on inventory visibility, item identification, and operational reporting. Safe Future Foundation needed a better way to track items coming in and going out, generate scannable labels, and make inventory data easier to search, review, and export.
Why It Mattered
Safe Future Foundation supports families and the local community through programs related to food access, diaper distribution, and other essential resources. Because of that, inventory accuracy was not just a convenience issue. It affected day-to-day operations, reporting, and confidence in what items were available.
The project gave me experience working on software with a real stakeholder, real constraints, and real operational value. It also required balancing course deliverables with the practical needs of a nonprofit client.
My Role
This was a team project, but my work concentrated on several specific areas of the application and its supporting documentation. My contribution was not primarily focused on broad frontend design. Instead, I contributed in areas such as:
- QR code workflow design and implementation
- feature refinement and simplification
- CSV inventory export
- error handling and user-facing feedback
- use-case documentation and iteration over changing requirements
One of the more important ways I contributed was by helping refine the scope of the QR-label workflow over time. I rewrote that use case multiple times as the design evolved, and I also took the initiative to review whether the earlier persistence-oriented approach was worth keeping. After doing my own analysis, I recommended simplifying the feature toward on-demand QR generation rather than storing QR records as a separate workflow. That recommendation was later accepted and helped reduce unnecessary complexity.
How The Project Worked
The project ran across the academic year and followed a more structured team workflow than a typical class assignment. We used Scrum and Jira to manage work, track progress, and iterate on features over time.
Our team also met with the client regularly throughout the year to gather feedback and adjust the system around actual operational needs. Separately, we submitted formal deliverables to the professor and presented recurring demos in class to show progress against project milestones. Those were separate parts of the workflow: client meetings informed the product, while course deliverables documented and evaluated the work.
Technologies And Tools
- ASP.NET Core MVC
- Entity Framework Core
- C#
- QR generation with ZXing and SkiaSharp
- Jira
- Scrum
What I Worked On
QR Code Workflow
One of the most visible parts of my contribution was the inventory QR workflow. From the inventory interface, users could open a QR page for an individual item, preview the generated code, download it as a PNG, print it, and return to the item record. The generated QR code pointed to that item's detail page, which created a simple labeling workflow tied directly to the inventory system.
This part of the project changed significantly over time. Early in development, I had worked on a more complicated barcode-oriented storage approach. Fairly early on, I removed that direction and rebuilt the workflow around QR codes instead. As development continued, I pushed further toward simplifying the feature by supporting dynamic QR generation on demand rather than treating QR codes as a separate stored record type. That reduced overhead and better matched the actual use case.
Inventory CSV Export
I also added a server-side CSV export for inventory data. This was a smaller feature compared with the QR workflow, but it was still useful because it made the system more practical for reporting, portability, and offline review.
The export produced a timestamped CSV file containing key inventory fields such as item ID, name, description, quantity, category, barcode, expiration date, and date added. It was not the most complex part of the project, but it was a concrete improvement that made the application more useful outside the browser.
Error Handling And User Feedback
I worked on improving error handling and making the application more understandable when something went wrong. That included user-facing error messaging, logging, and more consistent handling of missing or invalid requests.
For example, the application used a shared error view with clearer messaging and request IDs, and the inventory workflow included item-specific not-found handling, including a more helpful message when a QR code pointed to an item that could no longer be found. This was one of the less flashy parts of the project, but it mattered because it made the application more usable and easier to diagnose.
Documentation And Requirements Work
Because this was a year-long senior project, documentation was a real part of the work, not just something done at the end. I contributed to use-case documentation and revised the QR-related use case multiple times as the design changed.
That process reflected a broader reality of the project: the client's needs stayed consistent, but the best implementation approach became clearer only as the team built and reviewed the system over time.
Challenges And Lessons
This project involved more than just implementing features. It required working within a team, communicating with a real client, responding to feedback over time, and staying grounded in what the organization actually needed.
- A simpler implementation is often better than a more elaborate one.
- Client-facing usefulness matters more than feature count.
- Documentation, communication, and demos are part of real software work.
- Error handling and operational polish matter just as much as major features.
The QR workflow is the clearest example. It started as a more complicated design, evolved into a simpler QR-based workflow, and eventually became a practical on-demand implementation. That progression taught me a lot about scope control and engineering judgment.
Current Status
This project was completed as part of my UNF senior project sequence. It represents a year of team-based client work rather than a short standalone build.
What I find most valuable about it now is not just the finished application, but the combination of client communication, iterative development, technical problem-solving, documentation, and feature decisions shaped by real constraints.