Building a Project Website¶
A Guide for CS, IT, and Engineering Groups¶
What This Document Is For¶
This document is written for groups in Computer Science, Information Technology, and Engineering who are building a live project website as their shared presence.
It covers two things:
◆ what your site should contain — and why each element matters
◇ how to publish it using GitHub Pages, without building additional infrastructure
The HTML, CSS, and JavaScript that make up your site are your work. This document does not build the site for you, and it does not prescribe how to code it — your site should reflect your group's capability, not a template someone else provided.
What this document provides is the thinking behind the content: what belongs on a project site, what distinguishes a strong one from a generic one, and how to get it live so the work is visible while it is happening.
Before You Build — One Principle¶
A project website built at the end of a project is an outcome page. A project website built from the beginning of a project is a living record.
The most valuable thing your group can do is start early and update consistently. A site with a clear problem statement, a first entry in the timeline, and a working team section — published in week two — is worth more than a polished, comprehensive site published the week before submission.
Start small. Keep it real. Update it when something happens.
What Your Site Should Contain¶
The sections below are guidance, not a mandatory structure. Every project is different. Understand why each element is there before deciding whether to include it — and adapt it to fit your project's actual shape.
Project identity¶
Every visitor to your site needs to understand, within the first thirty seconds, what the project is about.
This section should answer:
◆ what is the project called
◇ what problem does it address — in plain language, not academic brief language
◆ who is it for — the intended user, client, or beneficiary
◇ what is the scale and scope — prototype, production system, research tool, intervention
The problem statement is the most important sentence on your site. Write it for someone who knows nothing about your institution, your subject, or your technical stack. If a potential employer reads it and understands immediately what your group was trying to solve, it is working.
Avoid copying your project brief directly. Rewrite it in your own words, for an audience outside your institution.
The team¶
Name each team member, their role in the project, and a brief note on their area of responsibility. This section does two things: it attributes the work to real people, and it demonstrates that the group had intentional structure and division of responsibility.
For each member, include:
◆ full name
◇ role or area of focus — backend, frontend, database, research, UX, testing, and so on
◆ a one or two sentence description of what they were responsible for
◇ a link to their individual Guide B showcase, if published
That last element — the link to individual showcases — is what transforms a team directory into a professional network. A recruiter or client can move from the shared project to each individual's account of their contribution. Do not skip it.
Personal information on public sites
Do not include student numbers on a public-facing website. Contact details, if included, should be professional — a LinkedIn profile or institutional email — not personal phone numbers or private email addresses.
Project timeline¶
This is the element that most distinguishes a meaningful project site from a static one. It is also the element that requires the most discipline, because it can only be built if you update it as the project progresses.
A project timeline shows:
◆ when key milestones were reached
◇ when significant decisions were made or directions changed
◆ when problems were encountered and how they were resolved
◇ when external interactions happened — client meetings, supervisor reviews, user testing sessions
Entries do not need to be long. A date, a brief heading, and two or three sentences is enough. The cumulative effect of consistent, dated entries across a semester is far more compelling than a detailed retrospective written at the end.
Consider a format similar to a changelog or release log — familiar to technical readers and easy to maintain. A dated heading, a brief description of what happened or what changed, and optionally a note on what it meant for the project direction.
This section is visible evidence that your group worked throughout the project, not just at the end. It cannot be faked after the fact — and experienced readers know that.
Key decisions¶
Select two or three decisions that significantly shaped your project and explain them briefly. Not every decision — just the ones that would raise questions if left unexplained.
For each decision, a reader should understand:
◆ what was decided
◇ what the main alternative was
◆ why this path was chosen
◇ what the trade-off or accepted risk was
This is the section that demonstrates technical and strategic thinking to external readers. It is also the section most frequently absent from generic project sites — which makes it one of the most effective ways to stand out.
Draw from your individual Guide A records when writing these. The decision reasoning is already there, recorded at the time it happened.
Screenshots and visual progression¶
Include screenshots or visuals that show the project at different stages — not just the polished final version.
Useful visuals include:
◆ early wireframes or sketches alongside later implementations
◇ database schema diagrams or architecture diagrams
◆ screenshots from different sprint milestones showing progression
◇ testing outputs or evaluation results
◆ any design iterations where the approach changed visibly
Caption each visual briefly — say what it shows and when it was produced. The purpose of showing visual progression is the same as the timeline: it demonstrates that the project evolved through deliberate work. Progression evidence is harder to fake than final screenshots, and experienced readers know this.
Client or partner acknowledgement¶
If your project involves a real client, external partner, or community organisation, acknowledge them — with their permission.
A brief note explaining who the client is, what context they operate in, and what they needed from the project adds significant credibility. It signals that the work had a real purpose beyond academic assessment.
Before including any client information, confirm:
◆ that the client is comfortable being named publicly
◇ that no confidential information about their organisation is being shared
◆ that any agreements between the institution and the client permit this
When in doubt, describe the client's context without naming them specifically. "A small logistics company operating in the southern African market" communicates the context without identifying anyone.
Links to the project¶
Include links to:
◆ the project repository — when it is in a state suitable for public viewing
◇ a live demo or deployed version — even a staging environment is valuable
◆ a prototype link — Figma, InVision, or similar, if applicable
◇ relevant documentation — API docs, user guides, technical specifications
Link outward rather than reproducing content on the site. The site is a navigational surface; the artefacts themselves live elsewhere. If the repository is not yet public, acknowledge that it will be available and add the link when it is ready.
Demo video¶
A demonstration video is a valuable addition — but timing matters.
An end-of-project demo video showing the completed system is standard. More valuable are milestone videos: short recordings at different stages showing what the system could do at sprint two, sprint four, and sprint six. These do not need production quality. A brief screen recording with narration, uploaded to YouTube or Vimeo and linked from the site, shows progression in a way that a final video alone cannot.
At minimum, plan for a final demo video that:
◆ demonstrates the core functionality clearly
◇ is narrated — explain what you are showing and why it matters
◆ reflects the actual system, not a scripted ideal path
◇ is short enough that a reader will watch it — two to five minutes is usually sufficient
Group reflection¶
When the project concludes, add a brief group-level reflection to the site.
This is different from individual reflections in Guide B. It is a short, collective note from the team on:
◆ what the group is most proud of in the final outcome
◇ what the group would approach differently if starting again
◆ what the project taught the group as a collaborative unit
◇ where the project could go next — future development, open questions
This closes the narrative of the site. It signals that the project was a learning experience, not just a deliverable. And it leaves a reader with a sense of the group as a thinking team, not just a list of names.
Reference list¶
Include a brief reference list of the sources, tools, frameworks, and methodologies that informed your project. This demonstrates that the group's choices were informed, not arbitrary, and it is standard practice for work that builds on prior thinking.
References might include academic papers that informed your methodology, technical documentation for frameworks you adopted, industry standards or best practices you followed, and any prior work your project references. Keep the list manageable — the sources that genuinely influenced decisions, not every link you opened during the project.
Publishing With GitHub Pages¶
GitHub Pages is the most appropriate publishing platform for CS, IT, and Engineering groups. It is free, integrates directly with your project organisation or repository, and the published URL is itself a signal of technical competence.
What you need before starting¶
◆ a GitHub account — personal or the group's shared organisation account
◇ a repository for the site — either a separate repository or a /docs folder within your project repository
◆ at minimum, an index.html file in the repository — this becomes your homepage
Your index.html does not need to be finished before you publish. A placeholder page with the project name and a brief description is enough to get a live URL. You will update the content as the project progresses.
Publishing steps¶
Navigate to the repository containing your website files — your index.html, CSS, and any other assets.
Step 1 — Open the repository on GitHub in your browser.
Step 2 — Select Settings from the top navigation bar of the repository.
Step 3 — In the left-hand sidebar, select Pages under the Code and Automation section.
Step 4 — Under Source, select Deploy from a branch.
Step 5 — Under Branch, select the branch your site files are on — usually main — and set the folder to / (root) unless your site files are in a subdirectory such as /docs.
Step 6 — Select Save.
GitHub will build and deploy your site. This takes between thirty seconds and a few minutes on the first publish.
Step 7 — Refresh the Pages settings screen. When the site is live, GitHub displays the published URL at the top of the section, in the format:
Your site is now live. Share this URL in your team section, in your individual showcases, and with your supervisor or client.
Updating the site¶
Every time you push a commit to the selected branch, GitHub automatically rebuilds and redeploys the site. No additional publish step is required after the initial setup.
Updating the site is the same as updating any file in the repository: edit the file, commit the change, push. The update is live within a minute or two. This is why GitHub Pages suits a living project site — updates are low friction, version controlled, and traceable.
A note on repository visibility¶
For GitHub Pages to serve a public site, the repository must either be public, or your account must have GitHub Pro or be part of a GitHub Organisation with Pages enabled for private repositories.
If your project repository contains code or documentation not yet ready to be public, keep your site in a separate public repository. The site repository does not need to contain your full project codebase — it only needs the files for the website itself.
What Makes a Group Site Stand Out¶
To be direct: most group project sites are forgettable. They exist, they satisfy a requirement, and they communicate very little about the quality of thinking behind the project.
The elements that make a group site genuinely memorable are not difficult. They require discipline and intention, not advanced technical skill.
A site stands out when:
◆ the problem statement is written for a reader who knows nothing about the institution — plain, specific, and immediately understandable
◇ the timeline shows real progression — decisions, pivots, and milestones across the semester, not just a launch date and a completion date
◆ individual team members link to their own professional showcases — the site is a network, not a directory
◇ at least two key decisions are explained with reasoning — not just what was chosen, but why, and what was given up
◆ visual progression is shown — early and late states, not just final screenshots
◇ the reflection note is specific and honest — not "we learned teamwork" but something that could only have been written by this group, about this project
None of these require exceptional design. They require thought. A site that demonstrates thought is one a reader remembers.
In Summary¶
A project website for a CS, IT, or Engineering group is an opportunity that most groups underuse.
Built with intention — started early, updated consistently, written for an external reader — it becomes the most visible evidence of your group's professional practice. It connects your collective work to each individual's Guide B showcase, gives clients and supervisors a window into progress, and demonstrates to the wider world that your group did real work, made real decisions, and learned from both.
The code is yours to build. The thinking behind it starts here.
If members of your group are in non-technical disciplines, or your group is exploring platforms beyond GitHub Pages, continue to Shared Presence for Other Disciplines.