Connecting a community website
to the work behind the league.

The local organization and my role

I worked with MPSC, a local organization in my city, to revamp its website and help the owner improve the process behind it. My contribution addressed both the public experience and the technological framework for managing registration, email, and communication more easily.

The live site describes a Monterey Park girls’ softball league, with programs, seasonal registration, schedules, a calendar, locations, downloads, and communication sign-up. That creates an operational problem as well as a design problem: families need the right information, while organizers need a reliable way to keep it current. The league website supplies the public context.

The software that can be verified

The public site explicitly identifies TeamSideline and includes its sign-in widget. It also loads the Duda/multiscreensite website runtime, RequireJS, a React runtime, and CloudFront-delivered assets. These are observations of the current website, not evidence that I wrote those vendor frameworks.

TeamSideline is the identifiable league-platform dependency. The exact configuration of registration exports, email delivery, and any additional automation tools has not yet been supplied. No separate CRM, email vendor, payment provider, or custom database is named as part of my implementation without confirmation.

Designing the operational boundaries

The website should make the current season, registration path, eligibility information, schedules, locations, and contact options easy to find. The operational framework should define where each kind of information is owned and which system is authoritative.

Registration state, payment state, team placement, and communication preferences are distinct concepts. A submitted registration must not be treated as a completed payment or a confirmed team assignment. A family requesting league communications should not silently become registered for a program.

Data mapping and communication workflows

A reliable process maps season, program, participant, and guardian records through stable identifiers. Names and email addresses alone are poor join keys because they can change and families can share contact information. Imports and exports need an explicit field map and a process for ambiguous or duplicate records.

The following is an illustrative workflow contract, not a claim that MPSC runs this custom code. It explains the separation needed between completed registration and the communication process that follows it.

Illustrative, simplified code explaining the implementation pattern. This is not a copy of private production source.

type RegistrationEvent = {
  eventId: string;
  registrationId: string;
  seasonId: string;
  programId: string;
  state: "submitted" | "confirmed" | "cancelled";
};

async function processRegistration(event: RegistrationEvent) {
  // Claim uses a unique event ID and a recoverable processing lease.
  const claim = await workflow.claim(event.eventId);
  if (!claim.acquired) return;
  try {
    const registration = await source.getRegistration(event.registrationId);
    if (registration.state !== "confirmed") {
      await claim.complete();
      return;
    }
    await notifications.sendConfirmation(registration, {
      idempotencyKey: `registration/${event.registrationId}/confirmed`
    });
    await claim.complete();
  } catch (error) {
    await claim.releaseForRetry();
    throw error;
  }
}

The workflow needs a recoverable claim rather than permanently marking an event processed before sending the message. A failed send can then be retried, and the provider-side idempotency key prevents duplicates after an uncertain response. This is the kind of systems thinking that makes administration easier rather than merely relocating manual work.

Administration, testing, and usability

Administrative access should match responsibilities, and export files containing participant details need controlled handling. Keep the public site clear of private registration data. Communication content should distinguish transactional notices from optional updates and give organizers a way to correct stale contact details.

Validation should exercise the complete family journey: find the relevant program, follow registration, understand completion state, locate schedule and field information, and reach the organization for help. Mobile layouts matter because families often use these pages while traveling to practices and games.

Operational tests include the wrong season link, cancelled registration, duplicate import, changed email, and undeliverable communication. The process needs clear ownership so a schedule update or a registration correction has an identifiable place to happen.

Outcome

The project combined a renewed website with a more manageable registration and communication process for a local organization. The technical value was aligning the public interface with the systems and procedures used to run the league. No revenue, participant-count improvement, or time-saved figure has been supplied, so those outcomes are not invented.