Project overview
1. Project introduction
The idea for Playground Pulse was born during an out-of-state family trip. We were trying to find a good playground for our son to burn off some energy, but standard mapping apps only showed us pin drops—not the actual condition of the parks. When we finally arrived at a location, we faced broken swings, closed restrooms, or overwhelming crowds.
We all know how disappointed kids get when you promise a trip to the park and it doesn't have what they were expecting! We wished we had an app that didn't just show where a park was, but gave us the real-time details caregivers actually need—like whether the toddler swings are working or if there's a restroom nearby—so families can pick the right park on the first try. That trip inspired us to build Playground Pulse to ensure no family has to deal with ruined park outings again.
Playground Pulse is a kid-friendly park discovery web application built to give families better, more actionable information than a general map search can provide. It helps caregivers decide whether a park matches a child’s age group, meets safety expectations, and reflects current real-time conditions before leaving home.
General-purpose mapping tools often leave parents without clear answers to key questions:
Playground Pulse brings those details together in one reliable platform.
Powered by a modern full-stack web architecture backed by Firebase services, our team developed a comprehensive, role-aware system organized into five key modules:
2. Website showcase
Rather than a generic feature tour, each card below outlines what we plan to show live for one of our three roles. Each walkthrough sticks to the actions that are unique to that role, and we've built in a few deliberate mistakes along the way so you can see not just the happy path, but how the app responds when something goes wrong.
Workflow 1
Show that a caregiver can register, find a park that actually fits their family, and leave it a little better for the next parent who visits.
We'll register a new account, catching a weak-password error before signing in, then search for a park by zip code with family-friendly filters on (including an over-filtered search that returns nothing). Once we're on a park, we'll submit a crowd report and try a second one to trigger the one-hour cooldown, leave a review and attempt a duplicate, and upload a photo, first with an unsupported file type and then successfully, before saving the park to Favorites.
Firebase Authentication manages identity, while Firestore stores user roles and park records. The crowd-report cooldown and the one-review-per-park rule are both enforced in the UI and checked again on the server, so the errors you see during the demo are real permission and data-integrity checks, not staged messages.
We're proud that the app backs up its family-friendly promise with real safeguards. Duplicate-submission protection, file validation, and honest empty states all work together to keep the information other parents rely on accurate and trustworthy.
Workflow 2
Show that a Park Admin's authority is real but scoped — they can maintain and moderate the parks assigned to them, and nothing else.
Signed in as a Park Admin, we'll edit an assigned park's details, then try editing a park that isn't ours to trigger a permission error. We'll update an equipment item's status and add a new one, advance a safety report to "In Review," and attempt to delete it to show that deletion is Site Admin-only. Finally, we'll moderate a review on our assigned park, then attempt the same on a park we don't manage.
Every action checks the signed-in user's assignedParks list against the target park before the UI even renders a control, and that same check runs again in Firestore's security rules and service functions. That means a Park Admin can't get around the scoping simply by sending a request directly instead of clicking through the interface.
Watching a Park Admin get blocked from editing a park they don't manage, or from deleting a report they can't delete, isn't a flaw in the demo. It's the point. Those boundaries are enforced the same way in the interface and on the backend, so the permissions you see are the permissions that actually exist.
Workflow 3
Demonstrate full platform oversight: onboarding new parks, provisioning admins, moderating content across the whole system, and staying accountable via the audit log.
From the admin console, we'll create a new park and invite a Park Admin to manage it, then try an invalid invite (a Site Admin with assigned parks) to show it getting rejected. We'll suspend a demo account and confirm it's locked out at login, reopen and delete a closed safety report, and finish in the audit log, filtering by event type before clearing the filters to trigger a required-filter error.
Site Admins skip the per-park assignedParks check entirely since their authority spans every park, but nothing they do goes unrecorded. Every create, invite, suspension, and moderation action writes an immutable audit event, and suspending an account disables the actual Firebase Auth record rather than just flipping a flag in the app.
We didn't want administrative trust to rest on good intentions alone, so we built the audit log to back it up with evidence. Everything a Site Admin does during the demo shows up right away in a filterable, timestamped record of who did what and when.
3. Challenges and incomplete work
This project grew from a straightforward park finder into a more complex role-aware application. Several features took longer than expected because they had dependencies across authentication, data design, UI states, and team integration.
Authentication was not only about sign-in. Once different user roles existed, every create, edit, moderation, and admin path needed both UI gating and service-level checks. That made seemingly simple features more expensive to wire correctly.
Features like busy-level calculation, notifications, favorites, photo uploads, and admin assignment each depended on different collections, rules, and validation patterns. The integration cost across those pieces was higher than it appeared at the feature-list level.
Some workflows needed iteration after implementation, especially park detail interactions, popup behavior, and responsive layout tuning. The team adjusted UI structure as the dashboard became denser and more interactive across sprints.
Email-based notification delivery, broader analytics, and deeper polish around some administrative experiences remain incomplete. If time continued, those areas would need another pass for refinement, hardening, and usability validation.
4. Interesting lessons
The most useful lessons came from the parts of the project where implementation details changed our original assumptions about scope, architecture, and collaboration.
Collections, relationships, and security assumptions influence feature complexity long before the UI feels complete. A small schema decision can affect reporting, favorites, notifications, and moderation later.
Roles cannot be treated as a cosmetic toggle. They shape routes, buttons, validation, and service rules at the same time, so the best results came from treating authorization as a shared system concern.
Implementation plans, model definitions, and service contracts made it easier to integrate work from different teammates. Without those agreements, later feature merges would have been slower and riskier.
Features like duplicate crowd-report prevention, password reauthentication, and admin moderation only became reliable after being tested as complete user tasks rather than isolated functions.
AI was most helpful when used for structured implementation support, UI iteration, and debugging assistance against clear requirements. It was less useful when the scope or data contracts were still vague.
5. Future improvements & lessons learned
If development on Playground Pulse were to continue, our roadmap would focus on expanding real-world usability, increasing mapping precision, and refining system architecture based on what we learned during development.
Highest-priority feature
The Focus: Growing the active park database beyond the initial Livonia, Michigan pilot area to encompass surrounding metropolitan communities.
Why It Matters: Scaling the dataset will allow more families across the region to benefit from the platform. This expansion would also include a “Suggest a Park” submission workflow, enabling community members and local park districts to request new playground listings directly.
Quality improvement
The Focus: Fine-tuning map marker placement and latitude/longitude geocoding precision across interactive mapping views.
Why It Matters: While current markers display general park areas, upgrading to high-precision geocoding will allow families to see exact pinpoints for main entrance gates, designated parking lots, and specific play structures—saving time and preventing confusion when visiting a new park for the first time.
Redesign or refactor target
The Focus: Refactoring the main Park Detail and Dashboard views into a modular, tabbed component architecture.
Why It Matters: As search filtering, interactive maps, real-time crowd updates, safety reports, and community reviews were added, the dashboard interface naturally became dense. Refactoring these responsibilities into distinct, dedicated sub-views will keep the user interface clean, responsive, and intuitive as new features are introduced.
What we would approach differently
The Reflection: If we were starting this project over, our team would establish and lock down shared data contracts, mock API responses, and database schemas earlier in Sprint 1.
The Benefit: Defining these data structures upfront would allow frontend UI styling and backend integration logic to be developed in parallel with zero friction, eliminating the need for minor data-mapping adjustments during Sprints 2 and 3.