About

I build across the seams.

I'm a software developer with full-stack range, working where interface behavior, data models, system boundaries, and delivery decisions meet.

The throughline is making complex products understandable—and keeping the claims around them as honest as the software.

The throughline

Make the work legible.

I work best in the ambiguous middle, where a useful product depends on both clear interface decisions and careful system judgment.

01

Model what must be true.

Clarify the workflow, constraints, data, and ownership boundaries.

02

Build the useful path.

Turn that model into an interface and system people can actually use.

03

Verify the real behavior.

Check the rendered product, edge states, and operating conditions.

Work in context

Three ways I've applied that approach.

01Professional product engineering

Jakomu

My work spans Showroom brand controls, a multi-tenant backend, AI-assisted website delivery, and CRM-ready lead-data workflows.

Read the case study
02Client product delivery

Move With Musto

I built a responsive real-estate experience around buyer and seller journeys, property search, reviewed listing data, and publishing guardrails.

Read the case study
03Owned product

Synapse

I shaped a media-evidence workspace that connects playback, transcript moments, source links, reviewer states, and a typed processing boundary.

Read the case study

Academic foundation

Formal training behind the systems work.

Two computer-science degrees form the academic through-line. The product, data, and verification examples are later professional applications—not coursework claims.

20232025B.S. → M.S.
Formation / 02 credentialsComputer science
01 / Undergraduate

Bachelor of Science in Computer Science

Southern New Hampshire University

02 / Graduate

Master of Science in Computer Science

Merrimack College

Operating principles

What I optimize for.

  1. Make the product usable before making it ornate.
  2. Treat compliance and user trust as product requirements.
  3. Verify visible behavior, not only successful logs.
  4. Write down the system decisions future maintainers will need.