Rebuilding NYC Borough Pass — Engineering Around a Vendor We Couldn't Fully See Into

Role: Technology Director, Rita XYZ (credited on this project as Engineering Director) — directed two engineers (Cassandra, Rachel), working cross-functionally with Design and Product inside Rita XYZ's Agile, Design Thinking–driven process.

Timeline: November 2023 – January 2024 (NYCBP engagement); Technology Director role held since February 2023

The Problem

1. A diagnostic full of hard numbers. Design's audit found unclear navigation, inconsistent visual hierarchy, no way to filter attractions, a 42-second average time on site, and a 93% drop-off rate between the homepage and attraction pages. None of that was going to fix itself in the rebuild — Engineering's job was to make Design's fixes real.
2. A build that had to survive without us. Whatever we shipped had to be responsive, accessible by default, and maintainable by a client with no in-house developer — not a system that quietly broke the day we handed it off.
3. A vendor we could build around but not into. Bandwango, NYCBP's third-party "destination experience engine," owned both the purchase flow and the customer support layer, and we had very limited visibility into its underlying code. Every purchase-related feature had to work around Bandwango's boundaries, not inside them.

Design Process

Wrapping structure around a system we couldn't open We built a checkout card that dynamically displayed validity terms per pass selected, wrapping around Bandwango's black-box purchase flow rather than trying to replace it, and wrote custom JS to show and hide the checkout container and handle responsive scroll behavior across mobile, tablet, and desktop.
Making the CMS something a non-developer could actually maintain We restructured Webflow's CMS around single-page data entry so the client's non-technical team could maintain attraction listings — borough, tags, price, reservation, accessibility notes — in one place instead of across scattered fields.
Building the navigation and filtering the diagnostic said was missing We built two navigation elements from scratch — a homepage passes slider and secondary in-page navigation for the attraction pages — directly answering Design's "unclear navigation" finding. Then we integrated Jetboost to add the live filtering and sorting the audit flagged as missing, and UserWay to bring accessibility support across the rebuilt pages.
Running QA as a standing practice, not a final pass We ran a standing QA checklist — link routing, typography, container consistency, button states — against a running cross-team bug list throughout the build, rather than treating QA as a single pre-launch gate.
Knowing what not to launch yet We fully built a reviews and testimonials feature but deliberately kept it unlaunched until NYCBP had enough real reviews to make it credible — a working feature isn't the same as a feature that's ready.
Leaving the client able to maintain it without us We delivered a maintenance guide and ran direct Webflow onboarding for the client's team post-launch, so the handoff was a real transfer of ownership, not just a live link.

Reflection

Leading the NYCBP engineering team surfaced a lesson I'd see again later doing my own cohort's Project 1 group website: the dev team usually absorbs the short end of the stick, because bugs and the actual friction of working with a given technology aren't things product and design fully register until they're the ones debugging it. Making sure my engineering team could move forward without leaning entirely on me for every solution was one of the harder parts of the role.
My advice to another Technology Director walking into the same kind of constraint: know when to step back and call it a day. Tight-timeline projects like this one are physically and emotionally draining, and that has to be managed deliberately, not pushed through.

Tools: Webflow, Bandwango, Jetboost, UserWay, Weglot