Selected project
BirdScout
A mobile app for identifying, recording, and exploring bird sightings, built to handle uncertain species identification, persistent sighting records, and location privacy.
An end-to-end birdwatching app
BirdScout is an app for birdwatchers. Take or upload a photo, optionally add some field notes, receive a suggested species, and keep the result in a personal journal. A community map shows sightings from other users.
Six of us built BirdScout over roughly four months for a McMaster software design course, taking it from requirements and architecture through to a working mobile prototype. The project covered requirements, system design, implementation, and integration.
From a photo to a saved sighting
The mobile client accepts a photo and observation details, persists the submission, and calls an Edge Function for classification. It then saves the suggested species as a sighting. That record supplies the result screen, journal, map, and achievement views.
Take a photo or choose one from the library, with optional notes and location.
Persist the image and observation metadata as an artifact before classification.
An Edge Function retrieves the artifact and asks a vision-capable model for a species.
Save the resulting sighting for the journal, map, and related views.
Designing the identification system
Bird identification can involve incomplete or conflicting evidence. Our proposed design used a blackboard architecture so that a generative model, geographic expert, and rule-based expert could contribute independently, with an identification controller combining their results.
Repository-style subsystems handled account, journal, and map data. This isolated the classification knowledge sources from the rest of the application and allowed them to be replaced independently. The working prototype used a simpler path: one vision-capable model invoked through an Edge Function rather than the proposed multi-expert system.
Turning a broad idea into decisions
Before implementation, we described nine business events from five stakeholder viewpoints. We also translated responsiveness, reliability, and privacy into specific design targets and failure cases.
SCOPE
Trace the main workflows
The requirements covered account creation, identification, past results, the sightings map, premium features, bird information, incorrect-result reports, and achievements.
PERFORMANCE
Put numbers behind “responsive”
We set design targets of three seconds for expert responses, one second for journal writes, and two seconds for map loading. These were specification goals, not production benchmarks.
FAILURE HANDLING
Consider more than the happy path
The proposed classifier could retry failed requests and continue when one expert was unavailable. These cases shaped the boundary between orchestration and individual experts.
PRIVACY
Be deliberate with location data
The design called for explicit permission, opt-in map contributions, and spatial anonymization. The prototype implemented only part of that design.
What I worked on
My contribution spanned the design work and implementation. I contributed across the project deliverables and was the primary contributor to the application source.
PLANNING
Requirements and architecture
I drafted the initial purpose, scope, and security requirements and helped define the business events and stakeholder viewpoints. I created the use-case and system-architecture diagrams, contributed to the architecture and subsystem design, and produced the detailed class diagram.
IMPLEMENTATION
Application and integration
I built the initial mobile UI and core domain model, then implemented photo storage, database-backed journal and map data, and classification through an Edge Function. I also handled loading and refresh behaviour, theming, platform compatibility, and the integration required for the end-to-end workflow.