LaunchShell.org is a student-built project site for documenting practical technology builds, beginner guides, free student resources, and lessons learned from real projects.
The site started as a simple static homepage and grew into a structured project archive with separate areas for guides, resources, real builds, reusable card assets, and JSON-backed content. The stack stayed intentionally simple: HTML, shared CSS, local assets, JSON, Git, GitHub, Cloudflare Pages, and AI-assisted learning.
LaunchShell did not start as a finished website plan. It started as a small homepage and became more organized as the project grew.
guides/, projects/, and
resources/, which made URLs and navigation easier to understand.assets/site.css instead of
being copied into every page.The site uses a simple static setup on purpose. No framework, no backend, no build system.
| Part | What I used | Why it mattered |
|---|---|---|
| Pages | HTML | Each page is easy to inspect, edit, copy, and deploy. |
| Design | Shared CSS file | One stylesheet keeps the site consistent across guides, resources, and projects. |
| Structured content | JSON | JSON keeps repeated card information and book data organized without turning the site into a full web app. |
| Assets | Local images and logos | Keeping assets local makes the site easier to move, back up, and deploy. |
| Version control | Git | Git lets me commit working versions, try changes, and roll back when something breaks. |
| Code hosting | GitHub | GitHub stores the repo, supports private work-in-progress, and helps turn finished projects into a portfolio. |
| Cloud coding | GitHub Codespaces | Codespaces provides a Linux-based browser workspace where I can edit files and use the terminal. |
| Domain and DNS | Cloudflare Registrar and Cloudflare DNS | I used Cloudflare to register the domain, manage DNS, and connect the public site to the domain. |
| Hosting | Cloudflare Pages | Cloudflare Pages deploys the static site from the GitHub repo and serves it on Cloudflare’s network. |
| Proxying and security | Cloudflare proxy, security rules, and access features | Cloudflare gives the site room to grow into real web security topics like proxying, WAF rules, access control, and protected admin areas. |
| Edge experiments | Cloudflare Workers | Workers make it possible to run small pieces of code at the edge without managing a traditional server. |
| Learning assistant | AI | AI helped with planning, drafting, debugging, explaining, reviewing, and organizing. |
Cloudflare made this project feel realistic without making it complicated. I use it for more than simple hosting: Pages, DNS, proxying, security features, access control, and edge Workers all fit into the same learning path.
I use Cloudflare Pages to host the static site. The workflow is simple: push changes to GitHub, let Cloudflare deploy them, and then check the live site.
I also use Cloudflare DNS and proxying. That means Cloudflare can sit in front of a site, route web traffic through its network, and add caching, protection, and security controls.
Cloudflare is useful because it lets a student project grow into real security topics: WAF rules, security rules, access policies, identity-aware access, and protected admin pages.
That makes it a great bridge between web development, networking, cloud infrastructure, and cybersecurity.
Cloudflare Pages hosts the public site directly from the GitHub repo.
DNS points the domain, and proxied records let Cloudflare protect and handle web traffic.
Workers can run small serverless functions close to users without managing a traditional server.
Access control can put login rules in front of internal dashboards, admin pages, and private apps.
Cloudflare security features make it easier to learn what web protection looks like in practice.
A real domain makes the project feel real, and Cloudflare Registrar keeps the domain workflow simple.
The site is organized so each section has a clear purpose.
.
├── index.html
├── data/
│ └── site-index.json
├── assets/
│ ├── site.css
│ ├── launchshell-logo-horizontial.png
│ ├── card-linux-terminal-intro.png
│ ├── card-aws-free-vps.png
│ └── ...
├── guides/
│ ├── git-and-github/
│ ├── github-codespace/
│ ├── libby/
│ ├── linux-terminal-intro/
│ └── ...
├── projects/
│ ├── build-this-site/
│ ├── 8-bit/
│ ├── json-book-recommendation/
│ └── ...
└── resources/
├── book-recommendations/
│ ├── books_public.json
│ └── index.html
└── index.htmlAs LaunchShell grew, the homepage started to become harder to maintain by hand. At first, writing each card directly in HTML was simple. But once the site reached more than 25 card images, guides, projects, resources, and homepage links, I needed a more organized way to manage the same information across the site.
Each card had a title, type, image, summary, link, button, category, and eventually
metadata like skill level and time to complete. Updating that directly in
index.html meant repeating the same structure over and over.
That worked when the site only had a few pages. It became messy once LaunchShell had separate sections for guides, projects, resources, books, Linux, cloud, Python, electronics, networking, and cybersecurity.
I added a central data/site-index.json file to describe each public page
once. The homepage can then read that file and render the correct cards into sections
like Start Here, Featured Guides, Featured Projects, and Resources.
This keeps the homepage focused on layout and storytelling, while the JSON file becomes the source of truth for card content.
Each item gets an ID, title, type, level, time estimate, category, summary, URL, image, and homepage section.
Instead of hardcoding every card, the homepage uses empty grid containers marked with
data-card-section.
A small script loads the JSON, filters cards by section, escapes the text, and builds consistent card HTML.
Because every card now has level, category, type, and time metadata, full project and guide filters can be added later without rewriting everything.
{
"id": "linux-terminal-intro",
"title": "Linux Terminal Intro",
"type": "Guide",
"level": "Beginner",
"time": "30-45 min",
"category": "Linux",
"summary": "Learn basic commands, files, folders, apt installs, SSH, and why Linux tools are useful.",
"url": "guides/linux-terminal-intro/",
"image": "assets/card-linux-terminal-intro.png",
"homeSection": "start-here",
"featured": true
}The workflow follows the same LaunchShell method used across the site.
Create the page, add the structure, write the content, and connect the assets.
Commit working changes with Git before making risky edits.
Try new layouts, move folders, change links, and test what fails.
Use the errors to understand paths, CSS, deployment, browser behavior, and Git history.
A simple static site still teaches real technical lessons.
Pages inside folders need different asset paths, like ../../assets/site.css.
Guides, resources, and projects needed different meanings so the site stayed organized.
Logos and graphics needed to look clean on the site, not like copied previews.
Once the site had many cards and assets, repeated homepage card HTML needed to move toward structured data.
AI was useful because I stayed involved. I asked questions, tested the output, changed the direction, fixed mistakes, and made final decisions.
AI helped turn rough notes into page outlines, sections, checklists, and beginner-friendly explanations.
AI helped rewrite technical ideas in plain English so a new student could understand them.
AI helped review pages, code, and repo content for secrets, hardcoded values, confusing wording, and risky publishing mistakes.
One of the most practical uses of AI is turning messy human information into structured data.
For the Recipe App, recipes came from index cards, magazine clippings, old notes, text messages, family recipes, and online references. None of those formats matched.
AI helped normalize that messy information into consistent JSON records that the app could read, search, display, and organize.
The book recommendations page uses the same idea: a private audiobook history became a smaller public
books_public.json file that renders a Top 30 list without exposing the full source history.
I still had to check ingredients, review steps, fix mistakes, choose the JSON structure, test the data in the app, and make sure the recipe made sense.
AI made formatting and cleanup faster, but I was still responsible for the final result.
AI is useful, but it has to be used carefully.
AI can produce confident wrong answers. I still had to run the code, open the page, check the links, and inspect the result.
Passwords, API keys, tokens, private files, SSH keys, and sensitive logs do not belong in AI prompts.
The final project is my responsibility. AI can help, but I need to explain what was built and why it works.
This site is more than a homepage. It demonstrates a complete beginner-friendly web workflow.
HTML, CSS, assets, pages, links, browser testing, and clean folder structure.
GitHub repository, Cloudflare Pages deployment, domain, DNS, proxying, and HTTPS.
Using AI to ask better questions, organize ideas, review work, and learn faster without giving up ownership.
LaunchShell.org was built to prove a simple idea: students can learn real technical skills by building real things. Git makes the work safer, Cloudflare makes the site real, JSON keeps repeated content organized, and AI can help turn curiosity into progress when the student stays in control.