Build Guide

Own a role. Build through one shared process.

Every important responsibility has an owner, but every member helps the team plan, test, improve, understand, and present the product.

Six Team Roles

Responsibilities, not biographies.

A role names the work a member owns. It does not prevent that student from helping elsewhere, and it is never just a title.

No prior experience requiredStudents learn the role by doing meaningful work.
Not every member must codePlanning, research, design, testing, and pitching count.
Smaller teams can combine rolesOne student may hold two related responsibilities.
All six areas stay coveredEvery major responsibility still needs an owner.
01

Owns direction, organization, and scope

Project Lead

Main responsibilities

  • Keep the team focused on a specific problem and realistic first version.
  • Organize the PRD, tasks, progress updates, and deadlines.
  • Coordinate roles, deployment, demonstrations, and final project decisions.

Meaningful work

PRDTask listProgress updatesContribution record

Should be able to explain

The problem, priorities, scope decisions, current blockers, and how each role contributes.

02

Owns AI tools, prompts, and build workflow

AI / Vibe Coding Researcher

Main responsibilities

  • Research and test useful AI tools and prompting methods.
  • Break large tasks into smaller prompts with the right context.
  • Record successes, failures, troubleshooting guidance, and responsible-use practices.

Meaningful work

Prompt libraryTool researchContext documentsTroubleshooting notes

Should be able to explain

Why a tool or prompt approach was chosen, what AI changed, and how the team reviewed the result.

03

Owns technical implementation and deployment

Lead Developer

Main responsibilities

  • Maintain the codebase and turn the plan into working features.
  • Review AI-generated code, fix errors, and save working versions in GitHub.
  • Keep the live product working and protect keys and private information.

Meaningful work

Working codeRepositoryLive deploymentTechnical notes

Should be able to explain

How the main feature works, where data lives, what services are used, and what could fail.

04

Owns interface design and user experience

Design & User Experience Lead

Main responsibilities

  • Plan page layouts, navigation, visual direction, and important actions.
  • Work with the developer to turn designs into usable interface code.
  • Test with possible users and improve mobile, desktop, empty, and error states.

Meaningful work

WireframesPage designsUser-test notesFinal screenshots

Should be able to explain

The main user flow, important design choices, user feedback, and resulting improvements.

05

Owns problem evidence, target users, and value

Business & Research Lead

Main responsibilities

  • Research the problem, target user, and existing alternatives.
  • Interview or survey possible users when appropriate.
  • Check facts and use evidence to guide product and competition decisions.

Meaningful work

Problem researchUser evidenceAlternative analysisSource list

Should be able to explain

Who has the problem, what evidence supports it, what alternatives exist, and how research shaped the product.

06

Owns the pitch, demo, and public explanation

Marketing & Pitch Lead

Main responsibilities

  • Shape the project name, short description, and main message.
  • Coordinate the pitch, demo script, recording, and presentation.
  • Prepare accurate competition responses and describe contributions honestly.

Meaningful work

Pitch scriptDemo videoPresentationSubmission responses

Should be able to explain

The user and problem, what the product does, what the team learned, and what each member contributed.

Every Role Contributes

Visible work takes more than one form.

GitHub commits are useful evidence, but they are not the only evidence. Every member should produce work the team can point to and explain.

Code commitsPrompt documentsProduct plansDesign filesResearch notesUser-testing resultsDemo scriptsPresentation slidesCompetition responses

Project Workflow

Nine stages from problem to handoff.

Move in order, keep the scope controlled, and test the public version throughout the build.

  1. 01

    Discover

    Find and define a real problem

    Start with a specific user and a problem the team understands—not with a technology or a vague “AI app” idea.

    CheckpointThe target user and problem are specific.
  2. 02

    Focus

    Develop and pitch a focused idea

    Define the product and its one main action. The first pitch explains the user, problem, possible solution, and why it matters.

    CheckpointAnother person can say what the user clicks and what happens.
  3. 03

    Organize

    Select projects and form teams

    Evaluate ideas for clarity, realistic scope, interested members, and demo potential. Cover all six responsibilities when forming each team.

    Not yet finalizedThe final project-selection and team-formation processes.
  4. 04

    Plan

    Write the one-page PRD

    Define the target user, problem, main feature, user stories, pages, stored information, and what version one will deliberately exclude.

    Not yet finalizedWho gives final PRD approval.
  5. 05

    Launch early

    Start from the club scaffold and deploy early

    After PRD approval, create the repository from the approved starter and give the project a public URL before building major features.

    Open the starter template
  6. 06

    Build

    Build in layers

    Complete and deploy each layer before asking AI to build the next one.

    1. 1SkeletonPages, navigation, placeholders
    2. 2PagesLayout, clarity, visual structure
    3. 3DataSimplest necessary storage
    4. 4InteractionMain user action works
    5. 5PolishMobile, states, accessibility
  7. 07

    Prove

    Test with users and reach a working demo

    Watch possible users try the main action, record confusion, and prioritize fixes that improve the core function.

    Working demoThe public site opens, the main action works, and a clear result appears.
    Not yet finalizedThe working-demo deadline.
  8. 08

    Present

    Prepare the pitch and competition submission

    Show the real product, research, roles, contributions, AI use, and remaining limitations honestly. Use only verified competition rules.

    Open competition guidance
    Not yet finalizedWhether every club project must enter a competition.
  9. 09

    Continue

    Reflect and hand off the project

    Record what worked, what failed, what remains unfinished, and what future members need to run and improve the project.

    Handoff goalFuture members can continue instead of starting again from zero.

Still undecided

No dates or policies are being guessed.

The official school-year calendar has not been created. Project selection, team formation, PRD approval, the working-demo deadline, and the club-wide competition requirement remain unfinalized.

Pending official decisions

Keep moving

Choose the next guide your team needs.