Capstone Plan · Design-Based Research
Poway-Midland Railroad Digital Experience
A heritage railroad at Old Poway Park runs on volunteers, a paper calendar, and a static website. This plan proposes turning that site into a working operations and visitor platform — and then names exactly which pieces we cannot finish without the railroad itself at the table.
Contents
Part 1 — What We Would Build
Proposed features, each stated against what the current PMRR website actually does today. Priority badges reflect the feedback in the research section below, not our own enthusiasm.
Live Departure Board
Priority 1The single question every visitor arrives with is "when is the next train, and can I get on it?" Today that answer requires reading a static table and guessing.
Stack: Flask + SQLite behind a JSON endpoint, Jekyll front end, polling refresh with a cached last-known-good render for offline visitors.
Online Reservations
Priority 1PMRR has never had online booking. Every seat is claimed in person, which caps attendance at whoever happens to show up and makes special events hard to plan for.
Stack: Flask routes with transactional seat locking, SQLite, confirmation codes generated server-side. No payment processing in this phase — see Part 2.
Volunteer Crew Scheduling
Priority 1The railroad runs on volunteer crews coordinated by phone and paper. This is the feature that saves staff time every single week, which is why it outranks anything visitor-facing that looks flashier.
Stack: Flask-Login sessions, SQLite shift table, role separation between volunteer and coordinator views.
Staff Admin Dashboard
Priority 1Prior feedback from PMRR was blunt about this: a feature staff cannot update themselves becomes stale within a month and then actively misleads visitors.
Stack: Flask-Login, hashed credentials in SQLite, audit log of who changed what and when.
Events & Announcements Board
Priority 2Seasonal events are a large share of PMRR's attendance, and they are currently announced as plain text buried on a page.
Stack: SQLite-backed posts, category filter in the client, staff-editable through the admin dashboard.
Interactive Fleet Encyclopedia
Priority 2The rolling stock is the attraction. A visitor who knows what they are looking at before arriving has a better visit, and a donor who understands a restoration is more likely to fund it.
Stack: Static JSON roster, responsive card grid, accessible modal pattern with focus trapping.
Interactive History Timeline
Priority 2A heritage railroad's product is history. Presenting it as a wall of prose wastes the best material the organization has.
Stack: Structured JSON timeline, progressive-disclosure UI, sourced-content policy enforced in review.
Membership & Donation Portal
Priority 2Right now supporting the railroad requires contacting someone. Every step between intent and donation loses donors.
Stack: Flask forms and records. Live payment processing is explicitly out of scope — it needs the railroad's merchant account. See Part 2.
Visitor Forecast (ML)
Priority 3Useful for staffing decisions, but only once it is trained on something better than proxies. We are listing it honestly as an experiment, not a promise.
Stack: scikit-learn, Open-Meteo weather API, offline training with the fitted model served read-only. Blocked on real attendance data — see Part 2.
Route Map & 360° Panoramas
Priority 3Good for pre-visit planning and for accessibility — a visitor who cannot easily walk the park can still see it.
Stack: Pannellum for panoramas, Leaflet with OpenStreetMap tiles, self-hosted image assets.
Visitor Notes Community Board
Priority 3Worth building, but nothing user-generated ships without moderation, because a small volunteer organization cannot absorb the cost of an unmoderated board.
Stack: SQLite posts with a pending/approved state, image size limits enforced server-side, moderation surfaced in the admin dashboard.
Visit-Planning Assistant
Priority 2Staff feedback on the prior capstone identified an assistant as the highest-value time saver, because the same handful of questions consume most of the phone calls.
Stack: Rule-based responses over structured site data in phase one. LLM upgrade is a partnership item, not a phase-one commitment.
💬 Research Already In Hand
We are not starting from zero. A previous Open Coding Society team (RCR) built and demonstrated a PMRR platform, then published what worked and what did not. Their retro is the most valuable input to this plan.
What the last team's feedback tells us to do
| Finding | Source | What we changed in this plan |
|---|---|---|
| GPS train tracking was unnecessary at this site's scale | PMRR staff | Cut entirely. Not in the feature list above. |
| The AI assistant was the most valued feature for reducing staff workload | PMRR staff | Promoted to Priority 2, scoped to answer from live site data |
| Staff need to update news and schedules themselves | PMRR staff | Admin dashboard moved into Priority 1 — it is a launch requirement, not a follow-up |
| User research should have driven where effort went | RCR retro | Priorities set from staff feedback before any code is written, revisited after first user testing |
| Verbal articulation at the CTE Expo needed more preparation | RCR retro | Demo script and a rehearsed 3-minute walkthrough built in Sprint 4, not the night before |
📝 What We Would Do Differently
- Talk to PMRR staff before choosing what to build, then again at the midpoint — not only at the expo.
- Ship the admin dashboard with the first feature it manages, so nothing goes stale waiting for it.
- Treat moderation, offline states, and error states as part of a feature's definition of done, not as polish.
- Do not build GPS tracking. Prior feedback already answered this.
- Do not present a machine learning model trained on proxies as though it were trained on real attendance.
- Do not connect live payments until the railroad's own merchant account and approval are in place.
📋 Build Plan
Repo scaffolding with CI, shared design system, data model, authentication, and the staff admin dashboard. Nothing visitor-facing ships before staff can edit it.
Departure board, reservations with seat-conflict handling, volunteer shift scheduling. This is the sprint that saves staff time.
Events board, fleet encyclopedia, history timeline, membership and donation flow, visit-planning assistant.
Route map and panoramas, moderated visitor notes, forecast experiment if data allows. Accessibility pass, staging deploy, staff walkthrough, demo script, handoff documentation.
Risks
| Risk | Likelihood | Mitigation |
|---|---|---|
| No real attendance data, so the forecast stays a proxy model | High | Forecast is Priority 3 and labelled an experiment; the platform is complete without it |
| Staff do not adopt the admin dashboard | Medium | Built in Sprint 1 and walked through with staff twice before launch; every content feature routes through it |
| Volunteer scheduling competes with an existing informal process | Medium | Read-only coverage view first, self-service claiming second, so the paper calendar can stay authoritative during transition |
| User-generated notes attract spam a volunteer org cannot moderate | Medium | Moderation queue ships with the feature; the board can be disabled from the dashboard in one click |
| Scope grows past a school-term capstone | High | Priority 3 items are explicitly cuttable; Part 2 below exists so cut work has a documented home |
Part 2 — With Partnership
These are the features we genuinely cannot finish alone. Each one names the specific thing we need from the Poway-Midland Railroad, so the ask is a decision rather than a favor.
Live Platform Camera
A live view of the station platform answers "is it busy right now?" better than any predictive model, and it costs nothing to run once it exists.
We need: an IP camera at Old Poway Park, network access for it, and a decision from the railroad about what may be shown publicly.
Real Attendance History
The forecast model is only worth shipping if it learns from actual ridership. With real ticket and headcount records, this moves from an experiment to a staffing tool.
We need: historical ticket sales or headcounts, at any granularity, even a spreadsheet of daily totals.
Live Payments for Memberships and Donations
The donation flow can be built and tested end to end, but it cannot move real money without the railroad's own account. We will not connect a payment processor on a nonprofit's behalf.
We need: the railroad's merchant or payment-processor account, and written approval to integrate against it.
Full Assistant Over Real Park Data
Staff identified the assistant as the biggest time saver. Upgrading from rule-based answers to a language model grounded in real operational data is the highest-leverage next step — but only if it answers from facts the railroad has approved.
We need: approved answer content, an escalation path for questions it should not answer, and a decision on who covers model costs.
School & Group Booking
Group visits are handled entirely by phone today. A coordinator-facing booking path with custom pricing tiers would remove that bottleneck.
We need: the railroad's group pricing rules, capacity limits, and lead-time policy.
Real Staff Accounts
The admin dashboard is built against seed accounts. Real accounts turn it from a demo into the tool the railroad actually runs on.
We need: a list of staff and volunteer coordinators, agreed roles and permissions, and an owner for account administration after handoff.
🎯 Definition of Done
- All Priority 1 features work end to end on a staging URL the railroad can reach.
- A staff member with no technical background updates the schedule and posts an announcement, unassisted, while we watch.
- A visitor completes reservation and volunteer sign-up flows on a phone with no unhandled errors.
- CI passes on
main, with no credentials or API keys committed to the repository. - Every Priority 3 or partnership-blocked feature is documented as such, so nothing unfinished is presented as finished.
- A written handoff covers the data model, admin procedures, known limitations, and the Part 2 asks.