Skip to main content
Harp is built so another school can adopt it without rebuilding anything. Almost everything event-specific, from the hackathon’s name and dates to the application form, scan types, FAQs, sponsors, and schedule, is runtime configuration managed from the super-admin UI. Not code.

​
What adopting looks like

  1. Fork the platform. Fork hackutd/harp and keep upstream as a remote so you can pull platform improvements each year. See Forking & staying upstream.
  2. Deploy it. Stand up the Go API + portal, PostgreSQL, and SuperTokens, plus the optional services you want (GCS, email provider, web push, Apple Wallet). See Production deployment.
  3. Configure your event. Sign in as a super admin and complete onboarding: event name, dates, contact email, application deadline, and feature toggles. Then build your application form, scan types, FAQs, sponsors, and schedule from the admin UI.
  4. Build your public site. Start from the marketing template and redesign it for your event’s theme, keeping its data layer pointed at your API’s public endpoints. See The marketing site.

​
What you customize vs. what you don’t

Keep your fork’s diff against upstream small: branding plus environment configuration.
Adoption tooling is actively being improved. A standalone marketing template repo, a committed .env.example, and a dedicated portal branding directory are in progress, and this guide will be updated as they land.

​
After the event

Run the annual reset workflow to clear event-specific activity while keeping your configuration, then pull the latest upstream release and start planning next year. See Administration & reset.