City HB workspace
Prepared for Milan, City of Huntington Beach
Prepared by taskmatic.io
April 25, 2026
Discovery & Requirements

City of Huntington Beach

Resident Services Platform

An app for the city's online services that starts with Milan's rentals and is built to expand into additional modules or apps for other teams over time. This document summarizes what we heard, what Phase 1 looks like, and what's needed to engage commercially.

01 / Vision

Move online, in stages City HB controls.

The platform starts with the rental experience Milan's division runs today — replacing in-person paperwork with an online flow that residents can complete from home and that staff can approve in minutes, not days.

It's designed so additional modules — permitting first, then anything else City HB wants to bring online — can be added without rebuilding from scratch. Each module shares a common foundation: authentication, payments, audit, accessibility, security. New ones plug in.

Phase 1 is the only thing on the table today. Future modules are scoped separately, when City HB is ready.

02 / Module 1 — Rentals

Clubhouse rentals, online end-to-end.

Replaces the current in-person, paper-form rental process. Residents see availability, book, and pay from home. Staff approve from a single queue. Extensions and changes are self-serve.

Resident booking flow

  • Pick a facility — see photos, capacity, amenities, current pricing.
  • Filter by capacity — type expected headcount; only facilities that can hold the group are shown.
  • Pick date and time window — calendar shows available slots, with buffer rules already applied.
  • Add-ons — alcohol (yes/no), outside-alcohol fencing, table setup, BBQ usage.
  • Pay online — Stripe integration; confirmation issued immediately, pending staff approval.
  • Self-serve changes — extend, shorten, or cancel without phone calls or office visits.

Hard scheduling rules non-negotiable

From the discovery call. These are core to the product, not configuration:

60min
Buffer between bookings
Standard cleanup window between consecutive rentals at the same facility.
90min
Buffer when alcohol is served
Extended window to clear lingering drinkers before the next rental.

Buffer logic is enforced by the scheduling engine — staff don't have to remember it.

Staff workflow

  • Approval queue — pending bookings shown in priority order; approve, reject, or request edits with one click.
  • Override capability — staff can edit any booking on a resident's behalf (extensions, comp accommodations, exception handling).
  • Facility management — upload photos, set capacity, manage pricing, mark facilities offline for maintenance.
  • Communications — automated confirmation and reminder emails; manual override for one-off messages.
Integration
Payments via Stripe; booking and transaction records flow into INOVA (City HB's finance system) on a schedule finance prefers. Manual export by staff is replaced with automated push, gated by a finance approval step.

03 / Module 2 — Permitting

Tiered event applications, scaled to event size.

The current permitting process treats a 50-person beach yoga class the same as a 50,000-person music festival. Same form, same questions, same review effort. The new module routes applications by tier so each event answers only what's relevant.

How it works

  • Tier classification at intake based on event size, location, and risk profile.
  • Adaptive application — questions about police, fire, traffic, vendor coordination only appear for tiers that need them.
  • Routing to the right department(s) for review automatically.
  • Approval lifecycle tracked end to end: applied, under review, approved/denied, archived.
Scope dependency
Detailed Phase 2 scope is finalized once City HB shares the existing tier framework (number of tiers, criteria, gating questions per tier). Ballpark example anchors: Tier 1 = small gathering (50-person yoga); top tier = Coastal Country Jam-class event (50k+ attendees, full multi-department coordination).

04 / Shared platform capabilities

One foundation, used by every module.

The capabilities below aren't built per-module. They're shared infrastructure that every current and future module uses — so each new addition is faster and more consistent than the last.

05 / Security & compliance

Built to meet City HB's standards.

The platform is designed to satisfy City HB's IT security and compliance requirements. Specific frameworks (CCPA, NIST, sector-specific) and any City HB-specific standards are confirmed during a security review with City HB's IT team — that review is a planned step, not an afterthought.

Standard practices included

  • Encryption at rest and in transit — TLS for all browser traffic; encrypted storage for all resident and staff data.
  • Multi-factor authentication available for all staff/admin accounts.
  • Role-based access controls — least-privilege by default; permissions reviewed and adjusted per role.
  • Audit trails — who did what, when, on which record.
  • Automated backups with documented recovery objectives.
  • Incident response process — documented, with named contacts and notification timelines.
  • Vendor security documentation available for City HB IT review.
Reference frameworks
WCAG 2.1 AA and Section 508 for accessibility (mandatory). CCPA alignment for resident data privacy. Other compliance frameworks aligned to City HB's checklist once shared.

06 / Scope boundaries

What's in, what's out.

Clear scope keeps Phase 1 deliverable, predictable, and procurement-friendly. Out-of-scope items aren't excluded forever — they're scoped separately when City HB is ready.

Phase 1 (in scope)
  • Rentals module — full booking flow, staff workflow, integrations
  • Shared platform foundation (auth, payments, retention, security)
  • Stripe and INOVA integrations for the rentals flow
  • WCAG 2.1 AA + Section 508 compliance
Out of Phase 1
  • Replacing City HB's existing department-wide systems broadly
  • Class registration, towing payments, lifeguard scheduling
  • Permitting module (Phase 2, separately scoped)
  • Modules for departments outside Milan's division

07 / Engagement structure

Two stages, so City HB always knows what's next.

Engagements run in two short, separately-priced stages. City HB approves each stage independently — nothing about the build commits before discovery is complete and a real quote is on the table.

Stage 1 — Discovery proposal scoped small

A focused engagement to lock down every detail before the build is quoted: facility data export, permit tier framework, IT security checklist, finance integration specifics, approval workflows, refund/cancellation rules.

Output: a complete scope document and a real, fixed-fee build quote. Sized to fit comfortably under City HB's procurement thresholds — no RFP required.

Stage 2 — Engagement proposal the build

Based on the discovery output, this is the proposal for actually building Phase 1 — real cost, milestone schedule, and engagement letter. Phase 1 (rentals) is structured to fit under City HB's $30,000 procurement threshold; future modules are scoped separately when City HB is ready.

Ongoing maintenance is a separate annual line item, agreed before launch.

Why two stages
Discovery has its own price because it's real work — and the cost of skipping it is bad estimates and surprise change-orders. Pricing the build only after discovery means the engagement quote is grounded, not guessed. City HB can stop after Stage 1 if the build cost or scope no longer makes sense.

08 / What we need from City HB

To finalize Phase 1 scope.

A few inputs from City HB unlock the detailed quote and engagement letter: