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.

[LouieCRK]

The most interesting part of this post isn't the timetable generator itself, it's the 45% waste-rate analysis.

A lot of developers (myself included) have experienced the same pattern:

• Build a proof of concept quickly.
• See it working.
• Decide it's now a product.
• Discover the architecture was never designed for long-term maintenance.

I actually think your biggest win was recognizing that distinction early.

One thing that stood out was your comment that a 2-hour fix could become a 4-hour task because every change required manual regression testing. That's a great example of how technical debt isn't just messy code, it's anything that slows down future change.

The bridge approach also seems sensible. Many developers try to rewrite everything at once and end up with a half-finished migration. Keeping the legacy UI alive while moving business logic into TypeScript incrementally is often less risky than a "big bang" rewrite.

My suggestion would be to prioritize tests before further feature work. Based on your own write-up, the lack of automated testing appears to be costing more time than the remaining UI technical debt. Once the parser and state-management layers have good coverage, future refactors become much safer.

Out of curiosity, if you were starting the project again tomorrow, what would your first 3 architecture decisions be before writing any code?

[virensingh011]

This is an incredibly impressive project, especially for a first-year, non-CS student! You’ve built a highly functional, privacy-first utility while learning software engineering from scratch.To help you continue refining your Enrollment & Timetable Comparison tool, here are some actionable suggestions and next steps:🛠️ Codebase & ArchitectureMigrate to Modern Frameworks: Since you are already using Vite + TypeScript, prioritize completely removing the legacy.js IIFE. Breaking the UI into modular components (e.g., using a reactive framework like Vue or React) will make state management and undo/redo much easier to maintain.Implement Automated Testing: Start with Vitest for your core time-string parsers. Write unit tests for edge cases (e.g., multi-week courses like "Weeks 2-18", odd/even week patterns, and lunch hour overlaps). This will give you the confidence to refactor without breaking existing features.Strict CI/CD Pipeline: Since you use GitHub Actions, add a linting step (ESLint) and strict type-checking to prevent deployments with broken code.🚀 User Experience & FeaturesMobile Responsiveness: A3 timetables are dense. To improve the mobile experience, consider adding a "Card View" or "List View" for small screens, alongside a toggle to switch between a daily and weekly grid.English Export Support: Since you plan to support English course names, ensure your PDF engine (jsPDF) has robust font embedding (like standard Helvetica) to prevent text truncation or character clipping when exporting bilingual names.Interactive Error Handling: If a messy spreadsheet fails to parse, provide the user with clear feedback (e.g., “Row 5: Could not recognize period string. Please check format.”) rather than just a blank cell.📚 Learning RecommendationsVersion Control Mastery: Look into Git branching strategies (Git Flow) and conventional commits to manage your pull requests cleaner as you transition toward open-source collaboration.Data Structures: Explore how timetable scheduling problems are fundamentally solved using graph theory or interval scheduling algorithms. This will make your auto-fill logic significantly faster and more robust.