From Spreadsheet Chaos to A3 Clarity – A Privacy-First Tool for Students

[Qinsanlian]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Verification Help & Guidance

Hi everyone,

Hello everyone,

I want to share a project I’ve been working on over the past weeks: Enrollment & Timetable Comparison, a privacy-first, pure front-end tool that helps international students turn messy enrollment spreadsheets into a clean A3 timetable.

It’s live at qinsanlian.github.io/enrollment-timetable-comparison – no installation, no account, no data leaves your browser.

What it does

• Import your official enrollment Excel (10-column format, Chinese or English), or start from built-in samples.
• A weekly grid (Mon–Sun, 6 period pairs) displays course names, times, rooms, and section codes by filling in index numbers.
• One‑click auto‑fill parses complex time strings (e.g. “Wednesday Periods 3‑4 {Weeks 2‑18}”) and places courses into the correct cells.
• Export to A3 PDF (bilingual), application package (cover + timetable), or print directly – all with an “unofficial layout” watermark to avoid misuse.
• Privacy: name hashing (SHA-256), session-only storage, mandatory confirmation phrase before export.
• Recent additions: logo/image watermark support, improved undo, language auto-detection, translation popups, and a simplified title.

What’s under the hood

The project started as a single 5,000‑line HTML file (a proof‑of‑concept). I’ve since moved it to a Vite + TypeScript setup with a layered architecture:

• types/constants → utils/core (pure functions) → state (persistence, undo/redo) → main.ts (bridge) → legacy.js (UI code that’s being phased out)
• Three CDN dependencies (html2canvas, jsPDF, SheetJS) locked at specific versions.
• Automatic deployment to GitHub Pages via Actions.

Honest limitations

• No automated tests – quality relies on a manual checklist. This is the biggest gap.
• The UI layer (legacy.js) is still a large IIFE with significant technical debt; only pure logic has been migrated to TypeScript so far.
• Recent changes (watermark, import confirmation, translation dialog) added some UI code that should eventually be modularized.
• The project is still a pre‑MVP by strict enterprise standards: functional but not yet proven with continuous integration.

Next steps

• Add unit tests for the core parser and state management modules (Vitest).
• Set up CI/CD with proper type‑checking and linting.
• Continue replacing legacy UI with TypeScript modules.
• Eventually open the door for English course name export and better mobile preview.

Why this matters to me

This project is part of my effort to learn software engineering from scratch as a first‑year, non‑CS student. I made plenty of mistakes – wasted tokens, broke undo multiple times, fought with GitHub Pages deployment for hours. I’m sharing this not because it’s perfect, but because the process of turning a messy prototype into something maintainable taught me more than any tutorial.

If you have feedback, found a bug, or want to contribute, feel free to open an issue or PR on GitHub. I’m still learning, and honest critique is always welcome.

Thank you to the communities and mentors who helped me get here – especially CodeFather for early guidance.

---

Apache License 2.0. This is an unofficial layout aid, not an institutional document.

[Qinsanlian]

6 Days, $450, and a 45% Waste Rate — Lessons from Rebuilding a Student Timetable Tool

Overview

I rebuilt a 5,000-line spaghetti-code HTML file into a modular TypeScript application in 6 days — spending $450 on API tokens and wasting nearly half of that budget on preventable mistakes.

Live: qinsanlian.github.io/enrollment-timetable-comparison
Source: github.com/Qinsanlian/enrollment-timetable-comparison

The Numbers

Metric	Value
API cost	$450 (Sonnet-4.6 + Codex-5.4-low + DeepSeek)
Total timeline	6 days
PoC to pre‑MVP	4 days prototype, 2 days engineering
Waste rate	~45% (includes the refactoring of initial bad architectural decisions)
Architecture	5-layer: types/constants → utils/core → state → bridge → legacy UI

What Got Built

• A privacy-first course timetable generator running entirely in the browser.
• Imports enrollment Excel files (10-column academic format), auto-fills a weekly grid, and exports professional A3 PDFs with compliance watermarks.
• TypeScript under the hood (17 modules), with a progressive bridge pattern that keeps legacy DOM code working while new logic replaces it chunk by chunk.

Where the 45% Went

Category	Cause
Architectural dead ends	Attempted full UI migration too early — rolled it back after hitting IIFE/ESM conflicts.
No Plan phase	Started coding before defining a minimum deliverable. Built modules without a clear integration strategy.
No automated tests	Every change required manual regression across 29 checklist items. A 2-hour fix took 4 hours because verifying it meant clicking through the entire UI.
Tooling friction	Spent meaningful time on Vite config, tsconfig tuning, and fighting GitHub Pages deployment — all solvable in advance with a proper scaffold.

These weren't "learning investments" — they were waste that a plan phase and a test suite would have eliminated.

What Actually Worked

• Progressive Bridge (__tsBridge): Kept the original IIFE intact while exposing typed functions from new modules. No naming collisions, no scope pollution.
• Layered architecture: types → utils/core → state → bridge → legacy — enforced one-way dependencies from the start.
• Compliance by default: Watermark injection, mandatory confirmation phrases, name hashing — all built into the export pipeline, not bolted on.
• Honest self-audit: Calculating the waste rate forced me to admit the mistakes instead of justifying them.

What This Project Is Not

• Not an MVP by enterprise standards (no CI/CD, no automated tests).
• Not a showcase of perfect code (the UI layer is still legacy JS).
• Not a claim of expertise — I'm a first‑year, non‑CS student learning in public.

Key Takeaway

The 45% waste came from one mistake: confusing "Proof of Concept" with "Minimum Viable Product." The prototype was functional but architecturally bankrupt. When I treated it as a real product, the technical debt bill arrived immediately — and I paid for it in tokens, time, and sanity.

If you're building something similar: spend 30 minutes on a plan before writing a single line of code. It's the cheapest insurance against a 45% waste rate.

---

Feedback, issues, and honest critique welcome. Still learning.