Make the geometry work.
Passage direction, plate alignment, separate fluid paths, seals and the nozzle interface all have to agree in the assembly.
Matthew Liepins / Personal portfolioDenver, Colorado
Rockets, robots
and software.
High school student. Hands-on builder.
I'm a sophomore at Rock Canyon High School interested in aerospace engineering, robotics and programming. Explore my projects, engineering decisions and work in progress.
01 / Independent aerospace engineering
In development
Stratum
A reusable rocket.
Built from first principles.
At the millimeter scale
Stratum is entirely my own project: a reusable vertical-takeoff-and-landing demonstrator, from the engine design to the software used to explore it.
I'm working through the engineering at the component level: injector geometry, manufacturing constraints, interfaces and the analysis that connects them.
Inside the injector assembly.
My exploded CAD view shows the upper components separated from the chamber body, exposing the interfaces in my developing design.
This is a design model; fabrication and testing are still ahead.
View full-size exploded view
Latest work
Rethinking the injector.
At 45 mm OD, features for a traditional swirl injector would be too small for me to machine. My rounded-hex chamber preserves six straight, flow-metering shims along the walls.
CAD exploration and a Python screening tool connect the geometry to its assumed flow behavior, helping me evaluate a candidate before the next hardware decision.
Read the engineering case studyInside the engineering
The decisions behind the design.
Check before optimizing.
Keep the intended geometry as a baseline and verify the current part dimensions. Use early calculations to expose assumptions before resizing a design.
Document the decision.
My October 8 review records the dimensions, tolerances and assembly risks I assessed. My conclusion was that the earlier design needed a redesign.
02 / Team engineering · BEST Robotics
Code that meets the physical world.
BEST Robotics
School teamI led the coding team developing manual and autonomous features for our school's BEST Robotics robot, alongside teammates building the hardware.
My contribution: Python driving modes and vision work, with encoder navigation in development.
The control code includes arcade, tank and button-based driving, selectable speeds and camera-based AprilTag detection. The case study follows a specific mode-switching decision through to the source code.
03 / NASA HUNCH · Student software team
Exploring predictive maintenance for lunar rovers.
Our project explores how AI might help identify equipment or system issues before they cause failures, supporting more informed maintenance decisions in a remote environment.
AI predictive maintenance
Early-stage projectI participate as a student software team member, exploring the engineering problem and proposed software direction. The project is still early, with substantial technical implementation ahead.
04 / Software · Sievum
Keep up with what changed.
I'm building Sievum, an agentic news and analytical tool that delivers personalized news on niche topics. It brings research and source-backed analysis together so a brief has context beyond a single headline.
Latest work
The codebase includes topic preferences, company watchlists, a brief reader and archive, source-backed follow-up questions, and scheduled email delivery. My work spans the product interface and the research-to-brief workflow.
Current work
The project is in development, with a private beta access flow implemented. The next step is validating the briefing experience with testers: which changes deserve attention, and whether the sources support the summary.
Visit Sievum05 / More software work
Hatchbench, my studio.
My independent software studio, with the goal of making software that is both fun to use and useful. It's home to tools for people who build things.
Quarry
BetaVersion control for hardware.
Branching, merging and visual diffs for STEP files, schematics and bills of materials. A software project about tracking both the files and the reasoning behind hardware changes.
Designed & built by me
Explore the UI collection ↗Interfaces with their own character.
Seven original UI concepts, from engineering workspaces to playful component kits. I designed the visual systems and built the interfaces.
Fieldwork / Operational interface concept
01 / Interface system
Fieldwork UI
An engineering workspace built around clear hierarchy, status signals and connected detail panels.
Glyph / Hardware-inspired component kit
02 / Component system
Glyph UI
Tactile controls, graphite surfaces and dot-matrix details inspired by physical hardware.
03 / Game-inspired patterns
Lore UI 2
Quest boards, dialogue and navigation patterns extracted into standalone React components.
Visit Lore UI 2 ↗
04 / Playful interaction
Bounce
A colorful kit exploring soft shapes, offset shadows and squash-and-stretch interaction.
Visit Bounce ↗
05 / Graphic interface
Shonen UI
A manga-inspired visual system with ink outlines, expressive type and hard shadows.
Visit Shonen UI ↗
06 / Tactile component kit
Roam UI
A bright React kit with expressive shape masks, a live accent picker and playful motion.
Explore Roam UI ↗
07 / Theatrical component kit
Rebel UI
A Persona 5-inspired kit with angular paper layers, original artwork and theatrical motion.
Explore Rebel UI ↗
06 / About & approach
Hey, I'm Matthew.
I'm a sophomore at Rock Canyon High School in Colorado. My goal is to understand as much as possible through creation, from the physics of a rocket engine to the details of a software interface.
I like the point where an idea meets a real constraint. The work here includes CAD review, written analysis, code revisions and problems that still need testing. Each project makes me ask a better next question.
School
Rock Canyon
Class standing
Sophomore
Interests
Aerospace & robotics
Approach
Build to learn
07 / Notes from the work
What the projects are teaching me.
Check the assumptions first.
Stratum's first-pass study exposed how much a result depends on an unconfirmed dimension or an assumed coefficient. A useful model has to make those limits visible before its output can guide a design.
Make control behavior explicit.
In the robot code, changing driving modes first stops the motors. Small decisions like that connect what the driver expects with what the software actually commands.
08 / Contact
Let's build something.
For engineering opportunities, project questions or a conversation.
matthew.liepins@gmail.com