ARI MORGAN / FRONTEND DEVELOPER

Good interfaces.
Clear thinking.
Useful code.

I build for the person on the other side of the screen. Here’s the work, the decisions behind it, and the code you can explore.

01 Working demos02 Technical case studies03 Source you can read
SELECTED WORK / 2026

From a problem
to a working thing.

Two small frontend projects. Each comes with the reasoning, a live demo and a source download.

Issue Lens working demo with a searchable issue table and status filter
01 / INTERNAL TOOL INTERFACE

Issue Lens

Making a long issue list easier to scan. Search, status filters and a shareable view, without hiding the work behind an account screen.

  • JavaScript
  • URL state
  • Progressive enhancement
Release Log working demo with versioned updates, dates and type filters
02 / PRODUCT COMMUNICATION

Release Log

A changelog built around finding an answer. Filter by change type, search the details and share the view with a teammate.

  • Semantic HTML
  • Search
  • Content structure
HOW I APPROACH THE WORK

Understand it.
Build it.
Make it clearer.

I’m Ari, a frontend developer interested in tools that help people get something done. I like reducing a complicated flow to a few understandable choices, then checking the details that make it usable.

My work starts with the HTML and the task. I add JavaScript where it helps, keep state predictable, and write down the decisions someone else will need to understand later.

Make the next step obvious.

A readable label and a useful empty state often matter more than another animation.

Build for more than the happy path.

Try long text, zero results, narrow screens and keyboard-only interaction before calling it finished.

Leave a clear trail.

Document the setup, the trade-offs and what the project does not do yet.

TOOLS / EXPERIENCE

A practical
starting point.

Experience and résumé →

In the browser

HTML, CSS, JavaScript, responsive layouts, forms and browser APIs.

In the workflow

Git, code review, browser debugging, written decisions and small reproducible tests.

What I’m exploring

Component boundaries, state management and clearer documentation for the next person.

What I value

Thoughtful feedback, readable code and teams that explain the “why.”

HAVE SOMETHING IN MIND?

Let’s build something
worth using.

Demo contact address. Replace it with your own before publishing.