Make it work.Make it better.Make it accessible.

University computer labs track hundreds of components — RAM sticks, GPUs, peripherals — across dozens of rooms. Until Procurvin, it was all paper audits and spreadsheets. Adding an AI chat interface wasn’t on the original spec.

The problem was obvious after the first demo: the client’s lab technicians didn’t want to learn a new UI. They wanted to type “How many DDR4 sticks are low in Room 204?” and get an answer.

I built the chat layer with Groq’s LLM API for speed — it’s noticeably faster than OpenAI for structured queries. The architecture is straightforward: natural language in, parse intent, query PostgreSQL via Prisma, return formatted answer. The tricky part was teaching the model the schema. I ended up writing a prompt that injects the relevant table relationships dynamically based on detected intent.

What surprised me: users didn’t just ask inventory questions. They asked “What’s been broken most this month?” and “Which room needs maintenance first?” — questions that required joins across four tables. The chat became a reporting tool I didn’t plan to build.

If I were doing it again, I’d instrument the queries to log which questions are most common. That data would tell me which dashboard widgets to build next. But for a v1, shipping a working natural-language interface to a relational database felt pretty good.

The hero headline cycles through: "Make it work." / "Make it better." / "Make it accessible." It ends on "accessible." because that's the longest word — locking the resting width avoids a layout shift. But it only advances when you scroll.

I used to reach for setTimeout and CSS animation delays to sequence a headline. The problem: those fire whether the user is looking or not. A timer-driven fade-in finishes before a slow scroller has read the first frame. Worse, it competes with the background strips for attention instead of composing with them.

Now both the strips and the headline are driven by one number: a 0–1 scroll `progress` captured with a passive rAF loop on the 240vh hero section. The strips clip their columns with that value; the headline slides its flex column with `translateY(${-progress}em)`. One source of truth, one animation frame, one mental model. Scroll faster and the headline keeps pace; stop and it holds; under `prefers-reduced-motion` it skips the animation entirely and shows the static multi-line tagline.

The trickiest part wasn't the transform — it was keeping the phrase centered while words of different widths swapped. Each sentence is a `max-content` row inside a box locked to the width of the widest sentence, so the headline never re-centers mid-scroll. That's the kind of constraint that only shows up when you stop animating from timers and start animating from intent.

Learning Chinese characters means reviewing at the right intervals — too soon and you waste time, too late and you forget them. Hanzi Loop applies spaced repetition to schedule each character’s reappearance based on recall accuracy.

The algorithm is SM-2, the same one behind Anki and SuperMemo. Each card gets an ease factor that increases or decreases based on whether you remembered. The interval grows exponentially: one day, then four, then ten, then thirty, and so on. What I added on top was a progress view that shows exactly which characters are “due” versus “learning” versus “mature” — so you can see the system working.

I went keyboard-first from day one. Spacebar to flip the card, 1–4 for recall quality, J/K to navigate. No mouse required. This was a deliberate constraint: I wanted Hanzi Loop to feel faster than a physical flashcard deck. If reaching for the mouse slows you down, you’ll switch back to paper.

The hardest part was handling scheduling edge cases — what happens when you review five minutes late? Should the interval adjust? I decided: yes, proportionally. What about cards you’ve reviewed fifty times and know perfectly? Maximum interval of 365 days, manually adjustable.

My old portfolio was the textbook create-next-app template. Blue gradient hero, typewriter tagline, “Available for opportunities” green-dot pill, const developer = {...} code window, uniform three-column project grid. Every piece of it screamed “I used a template.”

The redesign started with a rule: nothing that appears in the top twenty DevPortfolio templates is allowed. No typewriter. No gradient. No code window. No “passionate developer” bio. These aren’t design choices — they’re default behaviors. A portfolio should tell me who you are, not which template you picked.

I replaced them with: one bold headline, one CTA (“View Projects”), inline text social links, warm orange accent, and full-width case studies instead of card grids. The About section says specific things — “based in Pangasinan, Philippines (GMT+8)” — not generic things.

The real shift was mental: stop treating the portfolio as a resume extension and start treating it as a product. Products have opinions. A resume lists facts. The portfolio should feel like something only I would make, not something anyone could generate.

Celiadon POS runs a small electronics shop. Every completed sale deducts stock and generates a receipt. The backend is a standalone REST API handling product CRUD, transaction processing, and dashboard analytics. React on the frontend, Express plus PostgreSQL on the backend.

The lesson: a small shop needs zero-bullshit reliability more than it needs features. The owner didn’t care about pretty charts. They cared about the receipt printing correctly and the inventory number being right at 6 PM when they reconciled the drawer.

That shaped every decision. I used PostgreSQL with ACID transactions — not because I love SQL, but because a sale that deducts stock halfway and crashes would be a real problem. Every transaction is wrapped in BEGIN, COMMIT, ROLLBACK. The receipt ID is generated from a database sequence, not a UUID, so it’s human-readable and sequential.

What I’d change: I should have built an offline mode from the start. The shop’s internet goes down occasionally, and when it does, the POS becomes a paper system again. A PouchDB-backed offline queue with sync-on-reconnect would have been the right call.

I’ve built Procurvin (AI lab tracker), Celiadon POS (point-of-sale system), and Hanzi Loop (spaced repetition flashcards) alone — from database schema to deployment. Here’s the most important thing I’ve learned.

Scope is a creative constraint, not a limitation. Every one of these projects would be better with a team. Hanzi Loop could have better algorithm tuning. Procurvin could have richer analytics. Celiadon POS could have an offline mode (I genuinely regret skipping that). But shipping something real beats planning something perfect. Deadlines — even self-imposed ones — force you to decide what actually matters.

The frontend is where users judge you. I’m a full-stack developer but I live in the frontend. Why? Because users don’t see your Prisma schema or your API design — they see the button. They see the loading state. They see whether tabbing through the form works. The best backend in the world doesn’t save a bad first impression.

Know when to stop. I kept adding features to Hanzi Loop for months — dark mode, stats charts, custom decks, streak tracking. At some point I realized I was avoiding the hard work: validating whether anyone would actually use it for language learning. Shipping and getting real feedback (even if it’s “this is confusing”) is always more valuable than one more feature.