Portrait of Frank Yan
Frank Yan · New Zealand · Electronics + systems

Building systems that survive contact with reality.

I’m an electronics engineering student exploring where embedded systems, sensors, software, and AI meet the physical world.

  • Embedded systems
  • Sensors
  • Automation
  • AI workflows
  • Human agency

FOCUS MAP

The interesting work starts when these layers have to cooperate outside the demo.

DOMAIN NOTE

cool as.

A Kiwi phrase. A personal URL. A reminder to keep the interface human.

01 / NOW

Current focus

The things getting most of my attention right now.

LEARNING

Embedded systems

From MCU code to observable hardware behaviour.

  • C/C++
  • PCB
  • Sensors

BUILDING

Automation with consequences

Small systems where outputs must become real-world state change.

  • Control
  • Tooling
  • Verification

EXPLORING

Human-aware AI

Automation that earns trust through evidence, reversibility, and clear boundaries.

  • Agency
  • Evals
  • Recovery

02 / SELECTED WORK

Built, tested, still learning.

Embedded coursework, client web delivery and systems research, with evidence and limits for each.

EMBEDDED SYSTEMS · COURSEWORK

Microcontroller Lab

Arduino Uno experiments connecting sensor inputs to visible outputs: ultrasonic proximity indication, joystick-driven RGB lighting and state-machine control.

Evidence includes breadboard photographs, submitted C++ and calculator serial results. Hardware accuracy and reliability have not been quantified.

  • Arduino / C++
  • Sensors / PWM
  • State machines
View experiments and evidence

CLIENT WEBSITE · LIVE

BONNIELASS

A responsive website for an Auckland beauty and bespoke fashion business. Built with plain HTML, CSS and JavaScript, with English and Chinese pages and an enquiry interface.

Public result: a live site presenting both services. Enquiry delivery and final client acceptance are not verified here.

  • HTML / CSS
  • JavaScript
  • Responsive web
Visit BONNIELASS live site

SYSTEMS RESEARCH · EARLY R&D

MAELE

Home automation research exploring when a system should act, suggest, ask, or do nothing. Work includes a Python research simulator and software checks under synthetic conditions.

Simulation checks do not establish real household benefit or complete system acceptance. The public overview introduces the project; it is not a test report.

  • Python
  • Simulation
  • Verification
Read MAELE public overview

03 / PATH + DEFAULTS

How I got here — and how I work

Not a tidy résumé. More like a chain of environments that changed what I notice.

01Electronics manufacturing · production / quality

Factory floor

Manufacturing taught me that variance and failure are part of the system, not exceptions to it.

02Apple · Genius

Customer floor

Diagnosing devices with people standing in front of me made edge cases, clarity, and recovery very concrete.

03vivo · product / market

Market

Product perception and market work added another layer: the technical problem is not always the human problem.

04NZSE · electronics engineering

Back to engineering

Now reconnecting hardware, software, control, and AI with a stronger sense of what has to work outside the demo.

WORKING DEFAULTS

Three rules, one loop.

Reality first

Elegant models still have to answer to evidence.

Agency by design

Useful automation should reduce burden without quietly taking over.

Complexity earns its keep

Simpler systems start with an advantage if they can do the job.

Observe→Build→Verify→Repeat

OFF THE CLOCK

Swimming · Bachata & Urban Kiz · turning daily friction into engineering questions.

04 / CONTACT

Interested in work where software has to answer to physical reality.

If you’re building around hardware, sensing, automation, systems integration, or applied AI, I’m interested in comparing notes — especially where verification matters as much as the demo.

  • Embedded systems
  • Sensing
  • Automation
  • Systems integration
  • Applied AI