how i work · depth

how i workeli5 it · learn it · ship it slow

ServeIT builds target WCAG 2.1 (resume) · deeper AA notes on the accessibility page focus software engineering · accessible web 专业发展 · SWE · Informatics @ IU Luddy · May 2027

Throughline first: my focus is the work that keeps systems usable after the visible part is finished ... reliable handoffs, maintainable builds for partners without in-house engineering support, and clear technical communication for people who need accuracy over presentation. One instinct from a family restaurant floor into Serve IT (Laurie McRobbie Serve IT Nonprofit Clinic), Luddy’s university-run technology clinic, and into builds I test on myself before anyone else’s opinion. Three rules before the process memo: if you can’t ELI5 the codebase, you’re not done yet; if you don’t understand it, learn it; slow progress is the best progress. 福州 roots stay in the culture, not in any lab claim. Short version for hiring: ServeIT on the homepage.

Plain-English version first: I build websites and tools, mostly for nonprofits, and I make sure they’re easy for everyone to use. I also build demo sandboxes and integration prototypes when software needs to prove itself before production. The rest of this page is the detailed, behind-the-scenes version. If you’re not technical, read the intros of each part and skip the code-level bits ... that’s the ELI5 test in action.

I use AI-assisted editing sometimes. It speeds up the work. It does not replace what I decide or what I sign off on. Drafts may be AI-assisted. Accountability is entirely mine.

part 1

the sandwich runbook

computers do exactly what you write, never what you meant. if you can’t eli5 the instruction, the sandwich fails.

my cs professor's peanut-butter-sandwich drill is the foundation. vague inputs produce unstable outputs. that lesson carries into frontend architecture, demo sandboxes, and any AI-assisted draft. below is the runbook i actually follow ... ELI5 the instruction, learn the gaps, ship in small steps.

five steps

  1. write the constraints

    explicit bounds, edge cases, expected outputs. if the instruction has gaps, the system fails into those gaps.

  2. ai proposes / human evaluates

    the model suggests architecture or drafts. i evaluate. never swap these roles.

  3. read every diff

    inline edits or multi-step agent runs: i stay in the diff and validate before anything lands.

  4. check boundaries

    logic, fit, edge cases, WCAG 2.2. if an edge case can fail, assume it will.

  5. human sign-off

    nothing ships without a human reading it and saying yes. major decisions get documented.

when it goes wrong

AI sounds confident when it is guessing. when i catch a bad output, i do not just patch the result. i go back to the prompt. the error is usually a missing step in the instruction. fix the instruction, run it again.

what the sandwich taught me

building WCAG-compliant pages for bloomington nonprofits means hunting unspoken gaps. IU Rivet and Cascade chunks are not obstacles. they are a lesson in precision: outline assumptions, test margins, ship what you can defend.

part 2

building nonprofit pages, piece by piece

Plain version: At Serve IT we build free websites for nonprofits. IU gives us a set of ready-made building blocks (the tools are called Cascade and Rivet). Instead of hand-coding each page, I treat those blocks like LEGO: figure out what each part of the page needs to do, then snap the right blocks together so the page stays on-brand and easy to use.

The detailed version: i treat Cascade WCMS and Rivet as an enterprise component matrix, not a page builder. reverse-engineer the page into modular chunks. keep brand fidelity and accessibility. layout is composition, not hard-coded glue.

the chunks

text

anchor core narratives without layout noise. zero chrome when the story needs to land first.

callout

flag warnings, mission-critical shifts, or action items readers must not miss.

cta

one primary action per view. no twin competing CTAs fighting for the same click.

stat

metrics for scanning eyes. place high so recruiters and stakeholders get numbers fast.

accordion

secondary specs compressed. keep the first viewport clean; tuck deep docs behind expand.

cascade chunk map · golden paste order

when building a partner page in cascade, i pick chunks in this order so the viewport stays one job at a time:

  1. top of page

    text block · the hook

    open with the core narrative. no layout chrome.

  2. above the fold

    stat panel · the scanning metric

    1-3 metrics for scanning eyes. stakeholders get numbers fast.

  3. mid-page

    callout · the warning

    one warning or action item. never decoration.

  4. decision point

    cta unit · the singular action

    exactly one primary action per section. zero twin-button competition.

  5. below the fold

    accordion · the appendix

    secondary specs and long docs. keep the first viewport pristine.

rivetIU design system · layouts, components, utilities web frameworkCascade WCMS · page types, publishing, sitekube chunkstext, callout, CTA, panels, stats, tables serveit · serveaiIU nonprofit tech clinic · accessible client builds · public-interest AI accessibility notemixed-language DOM · density · multilingual household framing

part 3

doing it responsibly · business, technology, law

Plain version: before I build, I check the boring-but-important stuff: the rules of the tools we use, the school’s policies, the law, and whether the result will actually be usable for everyone. I treat fairness and access as requirements from the start, not something to fix at the last minute.

The detailed version: i read vendor constraints, institutional policy, and accessibility norms alongside user stories. ethics and access are non-functional requirements (things a product must do well even though they aren’t a visible feature), not a late QA scramble.

dimension focus how it runs
business stakeholder management name key players early. align architecture with the goal that actually ships value, not the one that only looks clever in a deck.
technology traceability & auditing document engineering assumptions so someone else can trace decisions later. ship in small increments with human sign-off when stakes are high.
law risk & compliance scan vendor constraints, institutional policy (IU Rivet / Cascade), and compliance coursework. keep a living risk register so innovation never means no one is accountable.

the habits underneath:

  • name stakeholders early.
  • treat ethics and access as non-functional requirements.
  • read vendor and institutional constraints alongside user stories.
  • document assumptions for traceability ... if you cannot ELI5 the decision, rewrite it.
  • ship in small increments with human sign-off when stakes are high. slow progress that holds up.

A public notebook sits next to this memo: madrid-ai-ethics (systems friction and public-service AI ethics). Essay pointer on zhao-langxi.

part 4

what that looks like in practice

Luddy LINK (Digital Humans Project Lead): Luddy LINK is Luddy’s applied-project programme. From February 2025 I have researched digital humans (AI-driven virtual personas) for business use cases, including how organisations might deploy them in customer-facing and operational contexts.

Serve IT Clinic (Website Team Lead): Lead 5+ nonprofit web projects for partners without in-house developers; ship WCAG 2.1-compliant sites and Python/PostgreSQL ETL pipelines designed for long-term maintainability. Founded ServeAI (PIT-UN): responsible generative AI tools and plain-language guides for community organisations.

accessible builds

partner sites on the ServeIT roster: WCAG 2.1 baselines (resume), with Cascade/Rivet composition notes in the process memo above. staff-maintainable, visitor-hearable. see the accessibility note for mixed-language DOM work.

demo sandboxes

one job per viewport, 48px touch targets, primary CTA reachable on a phone. pitch rooms and subway thumbs use the same sandwich rule as Cascade chunks.

live proof

Quackr (duck farm) is a React + TypeScript social media site I just keep as a portfolio sandbox on this site ... UI I test myself. Not a launched product, not a D3 canvas demo. The twin classroom lives on matchaxmoxie (cookie classroom · Faculty and Staff for Student Excellence (FASE) Mentor Apprenticeship Program (MAP)).

global rules define the fence line. local modules run free inside it.