Aksel Cichocki

B.S. Industrial Engineering · UW–Madison

01 — Project Live

Scout Club CA website rebuild

Scout Club CA restores International Harvester Scouts in California. The existing site was a stock page-builder template. The rebuild treats it as what it actually is: a commissioned-build studio with a six-figure entry price and a waiting list.

scoutclubca.com: a stock page-builder layout with a photo carousel and standard navigation Before
scoutclubca.com — page-builder template. Generic nav, carousel hero, no pricing or access signal.
The rebuild: an editorial layout with a serif headline, a commission call to action, and a specification bar After
bins.akselcichocki.com — editorial hero, a single clear action, and the commercial facts up front.

What changed, and why

The original buried the two things a buyer needs first — what it costs and how you get in. The rebuild puts From $100,000, the studio locations, and by appointment only in the first screen. That is qualification, not decoration.

One action, not six

A template offers Home, About, Builds, Shop, Blog, Contact and a cart with equal weight. The rebuild offers one primary action — Commission a build — and a secondary path to browse.

The idea — AI as the studio

Higgsfield — the imagery

The club's photography was redone with Higgsfield's image models: existing shots restored, re-lit, and re-framed into the editorial look the new design needed — instead of settling for the photos that happened to exist.

Claude — the build

The site itself was designed and coded in partnership with Claude — layout, copy and code iterated in conversation. The taste calls — what to keep, what to cut, what it should feel like — stayed mine.

02 — Project

Personal manager

One system for everything that competes for my week: mail, calendar and coursework, pulled through their APIs into a single dataset — then treated as a scheduling problem rather than a to-do list.

The Hobbes weekly board: mail triage and assistant chat panels on top, a Someday tray, and a seven-day grid of task cards with calendar events under each day Mail triage — only the 3–4 % that needs a reply surfaces Plain English in, filed work out — "dentist tuesday 2pm" becomes a calendar event Someday tray — parked until it earns a day Task cards — tap a day chip or drag between days Live Google Calendar mirror — edits write back to the real calendar
The weekly board, shown with example data.
  1. Mail triage — only the 3–4 % of mail that needs a reply surfaces.
  2. Plain English in, filed work out — "dentist tuesday 2pm" becomes a calendar event.
  3. Someday tray — parked until it earns a day.
  4. Task cards — tap a day chip or drag between days.
  5. Live Google Calendar mirror — edits write back to the real calendar.
3.5% of 2,700 messages surfaced — the rest stay out of the way
15 min sync cycle, 24/7 on my own server, every stage logged pass or fail
4 s from a typed sentence to a filed Google Calendar event
0 delete paths in the Gmail code — every action reversible by design
  • Constraint solver Work blocks planned around fixed calendar events with CP-SAT (Google OR-Tools) — priority-weighted due dates and an explicit "didn't fit" report.
    Applied operations research: a solved allocation problem, not a to-do app.
  • Measured, not guessed Inbox backlog treated with Little's Law — arrival rate × time-in-system. The data said reduce arrivals; I had assumed the opposite.
    Measurement before opinion — and a changed mind on record.
  • Mail triage One-tap archive against a 40,000-message account, written back to Gmail, reversible by construction.
    Signal-from-noise filtering at scale.
  • Plain-English capture "dentist tuesday 2pm" — a local model files a real Google Calendar event. Create, update and delete all proven against the live calendar.
    A working language pipeline with real write-back, not a chatbot demo.
  • Weekly board Tasks drag between days; a Someday tray holds the rest. Used every day since it shipped.
    Built for use, not for the portfolio.
  • Self-healing ops Cold-reboot drill passed: six services, containers and cron all came back on their own, and a boot check logs the verdict.
    Run like production infrastructure.

03 — Project

Class notebook

The same system follows me into lecture. A notebook keyed to my real course schedule — courses seed themselves from the calendar — where I can press record and type at the same time.

The class notebook: course and chapter columns on the left, an open lecture page with a red recording button, a live transcript pane, and typed notes below Courses seed themselves from the calendar schedule Record — audio never leaves my server Live transcript — words land seconds behind the professor Typed notes autosave — every change kept as a revision
The notebook mid-lecture, shown with example data.
  1. Courses seed themselves from the calendar schedule.
  2. Record — audio never leaves my server.
  3. Live transcript — words land seconds behind the professor.
  4. Typed notes autosave — every change kept as a revision.

Live lecture capture Live

A record button on every page streams audio to a Whisper model running on my own server; the transcript appears on the page about ten seconds behind the professor. No cloud transcription, no subscription.

Typed notes, versioned Live

Notes autosave as I type and every change is kept as a revision. A page can also be a real Google Doc when sharing matters — the notebook mirrors its text back so summaries stay current.

Executive notes Live

After class, the transcript, my typed notes and uploaded slides are merged into one structured summary — which flags the parts of the audio it couldn't hear instead of guessing. Deadlines it spots are suggestions I accept, never auto-filed.

Lecture audio never leaves the server: transcribed locally, kept thirty days, and excluded from every share and export by design.

04 — Infrastructure

Helping run a real fleet

I work as a co-helper on ThreadSync's infrastructure — a private fleet of Linux virtual machines running real services. It is the part of my experience that no coursework provides: systems that other people depend on, where a mistake has consequences.

Virtual machines

The fleet runs on hypervisors with per-workload VMs — my own among them. I help operate and extend them: provisioning, containerised services behind a reverse proxy, TLS, private networking, and the unglamorous work of keeping things reachable.

The ark file server

A ZFS-backed file server with snapshots and off-site replication. Working around it taught me that storage is a discipline, not a disk — quotas, snapshot retention, and knowing that a backup you have never restored is not a backup.

Reviewed by a second AI

Significant changes get sent to a separate model — Codex — for an adversarial review before they ship. Watching a reviewer find the thing you missed, repeatedly, changes how you write in the first place. This site went through three rounds of it.

None of this is my company or my architecture. I help build and run it, and I have learned more from being in the room than from anything I have been taught.

About

The short version

Industrial engineering at UW–Madison. I build systems I use every day — week planner, class notebook — running on my own server.

Seeking a Summer 2027 IE / operations / supply chain internship — Madison, Milwaukee, or Minneapolis.