• As team captain for a NYC recreational soccer league, identified that managing attendance over WhatsApp, schedules over email, and enrollment through a Google Sheet was unnecessary friction, and built an app to address it
• Built a React Native iOS MVP in TypeScript covering player accounts, schedule viewing, game RSVPs, push notifications, league enrollment, team management, and an admin dashboard
• Currently in alpha: replacing dummy data with real league data and validating the push notification system before pitching to the league and submitting to the App Store

I joined a recreational soccer league in NYC, took on the role of team captain, and decided to build an app after noticing how much friction the league's current setup created. Managing attendance meant chasing RSVPs over WhatsApp, game times arrived via email two days before kickoff, and players enrolled in new seasons through a Google Sheet linked on the league's website. Most leagues in the city already have a dedicated app for this, and it seemed like a natural gap to fill.

I built a React Native iOS MVP in TypeScript, covering the core player-facing and admin workflows: player accounts and authentication, schedule viewing with a calendar grid, game RSVPs, push notification reminders, league enrollment, team management, and an admin dashboard with CSV export. It's currently in alpha; I'm replacing dummy data with real league data and verifying the notification system end-to-end before pitching it to the league and deploying to the App Store.

• Built five modular C++ ROS 2 (Robot Operating System 2) packages from scratch in a 6-hour coding challenge: clock pose issuer, GUI pose issuer, motion controller, and two coordinate frame transformers
• Designed the system so a robot follows pose inputs from multiple sources (clock-based positions or user-selected GUI poses) and reaches each target via a motion controller
• Handled coordinate frame conversion between the normalized world frame and the robot's local body frame to keep each package decoupled from the simulation's internals
• Delivered a full documentation suite, system connectivity diagram, test suite, and shell scripts for building and launching the system

For a 6-hour robotics coding challenge, I designed and implemented a ROS 2 (Robot Operating System 2) stack in C++ where a robot follows pose inputs from multiple sources and reaches each target using a motion controller. I built five packages from scratch, each with a focused responsibility. The clock pose issuer converts clock time into 6D positions on a unit circle. The GUI pose issuer gives the user a manual interface to issue pose commands directly, with a spacebar reset. The motion controller subscribes to both pose sources and converts the target pose into velocity commands. Two transformer packages handle coordinate frame conversion, mapping between the normalized world frame and the robot's local body frame, so each component stays decoupled from the simulation's internal coordinate system.

I also wrote a full documentation suite covering installation, build and run instructions, and testing and formatting procedures, and included a system diagram showing how all five packages connect through their ROS 2 topics. I kept each package's structure consistent and straightforward to extend: adding a new package or controller means following a clear pattern rather than reverse-engineering existing code. The submission included a test suite and shell scripts for rebuilding and launching the system.

• Designed and demonstrated a multi-agent path planning and collision avoidance system on Michigan's physical M-Bot robots, built on the CBS (Conflict-Based Search) algorithm for completeness and optimality guarantees
• Led path-following logic implementation, TCP (Transmission Control Protocol) server-client architecture, and PID (Proportional-Integral-Derivative) controller configuration for robot operation
• Owned the testing effort: designed the QA test plan, test scenarios, simulation field, and testing matrix; ran six successful trials across varying levels of map complexity; produced a video walkthrough of the system

I chose EECS 467: Autonomous Robotics as my capstone (Michigan's Major Design Experience, or MDE) because I had a strong interest and academic background in robotics by senior year. Our team of four designed and demonstrated a multi-agent path planning and collision avoidance system on Michigan's physical M-Bot robots. We built on the CBS (Conflict-Based Search) algorithm for its completeness and optimality guarantees, implementing path-following logic that translated a 2D path array into linear and angular velocities over a TCP (Transmission Control Protocol) server-client architecture, and configured a PID (Proportional-Integral-Derivative) controller for each robot to ensure smooth operation.

My primary contributions were leading the path-following logic implementation, TCP communications, and PID controller configuration, as well as owning the testing effort. I designed the QA test plan to verify the system worked end-to-end in the real world: creating test scenarios, designing the simulation field, and building the testing matrix. We ran six trials across varying levels of map complexity, and the system performed successfully. I also led the team's technical documentation, including producing a video walkthrough of the system.

• Implemented occupancy grid mapping, particle filter localization, and path planning on a LiDAR-equipped M-Bot
• Built forward and inverse kinematics models to translate between joint space and physical robot motion
• Fused odometry and LiDAR data for accurate real-time localization
• Tuned PID controllers for reliable low-level motor control on physical hardware
• Demonstrated end-to-end autonomous maze navigation on a physical robot

EECS 467 was a lab-based robotics course built around the M-Bot, a four-wheel-drive robot equipped with a LiDAR (Light Detection and Ranging) sensor. Working with one partner, I implemented the core stack for SLAM (Simultaneous Localization and Mapping) based autonomous navigation across a series of labs that each built on the last.

We started with low-level control: odometry and PID (Proportional-Integral-Derivative) tuning to get the robot moving accurately, then moved up to occupancy grid mapping, where the robot used LiDAR readings to build a 2D map of its environment. From there we added localization using a particle filter, so the robot could track its position within that map in real time. Path planning came last, tying everything together so the robot could navigate autonomously, finding its way through a maze it had never seen before. The robot navigated the maze end-to-end at the final demo.

• Designed and implemented a reactive autonomous Rocket League algorithm using real-time computer vision input
• Wrote the computer vision Python script detecting AprilTags and field colors for real-time robot state estimation
• Led C implementation of embedded components: magnetometer, gameplay timers, PS2 controller SPI communication, and USB-to-Serial adapter
• Scoped and demoed a goaltending robot under time pressure after a last-minute team setback
• Produced systems engineering diagrams, a milestone report, and the project poster

EECS 373 was an embedded systems design course concluding with a month-long team project. Our team of four chose to build a real-life version of Rocket League, the car-soccer video game, where a human-controlled robot competed against an autonomous one on a physical field. My primary ownership was the autonomy algorithm: a reactive system that used a computer vision Python script to detect the ball and field state in real time and feed that directly into the robot's decisions.

On the embedded side, I led the C implementation for several components: a magnetometer for orientation, gameplay timers, PlayStation 2 controller SPI (Serial Peripheral Interface) communication for the human-controlled robot, and a USB-to-Serial adapter for system communication. The computer vision side was Python; I wrote the script that detected AprilTags (QR-code-style markers used for position tracking) and colors on the field to feed real-time state into the robot's decisions. I also designed and implemented the full autonomous Rocket League algorithm, though the demo circumstances meant it never got validated and tested in time. My documentation contributions included systems engineering diagrams, a milestone report, and the project poster.

Two days before the demo, it was clear a critical piece of a teammate's work wasn't going to be ready. The rest of the team pulled an all-nighter to stabilize what we could, which left no time to validate the full autonomy algorithm. I made the call to scope it down to a goaltending robot that used the CV (computer vision) system to track the ball and move to intercept it. It worked, though latency in the pipeline meant it struggled with fast shots. The lesson I took from it was practical: trust teammates but verify progress early, and test in small integrated chunks throughout a project rather than waiting for full system tests at the end.

• Replicated Zhang et al.'s "Colorful Image Colorization" CNN architecture, training on a 90,000-image subset of the MIT Mini Places dataset
• Investigated the impact of loss function choice by substituting the authors' Cross Entropy loss with MSE (Mean Squared Error)
• Tuned ADAM (Adaptive Moment Estimation) optimizer parameters to compensate for reduced computational resources and training data
• Demonstrated that MSE produces visibly duller, more monochromatic outputs than Cross Entropy on a pixel classification task

EECS 442 covered the core theory and methods of computer vision, including convolutional neural networks, image processing, and deep learning approaches to visual understanding. The course culminated in an independent research report, for which I chose to replicate a published deep learning colorization model and use it to investigate how loss function choice affects output quality.

The model, originally from Zhang et al.'s "Colorful Image Colorization" (ECCV 2016), uses a CNN (Convolutional Neural Network) architecture (a class of neural network that applies learned filters across an image to detect patterns) with downsampling and upsampling layers to compress and reconstruct spatial information, batch normalization to stabilize training, and Leaky ReLU (Rectified Linear Unit) activation functions that introduce non-linearity so the network can learn complex mappings. My replication trained on a 90,000-image subset of the MIT Mini Places dataset using a tuned ADAM (Adaptive Moment Estimation) optimizer, an adaptive gradient descent algorithm that adjusts learning rates per parameter during training, and deliberately omitted the authors' class-rebalancing method to isolate the variable I was testing: replacing their Cross Entropy loss function with MSE (Mean Squared Error).

The results were clear. MSE produced consistently duller, more monochromatic outputs; only blues retained any vibrancy across test images. My explanation was that MSE, designed for regression problems where outputs can range across any value, converges much more slowly on a classification task like colorization than Cross Entropy, which is purpose-built to penalize confident wrong predictions. The experiment confirmed that loss function choice is not just a technical detail: it has a direct, visible impact on what a model actually learns to produce.

• Built the original site in summer 2022 using HTML, CSS, and JavaScript, customizing an HTML5 UP template as a foundation
• Identified a gap between the site and my personal brand, then redesigned the entire UI from scratch
• Introduced a two-layer content model (modal and longform toggle) so the reader actively chooses how deep to go, keeping the main view skimmable by default
• Rebuilt the visual design to reflect a clear personal brand: an engineer who thinks logically and communicates clearly
• Documented the engineering and design process in a write-up

I built the first version of this site in summer 2022 using HTML, CSS, and JavaScript, customizing an HTML5 UP template as a foundation. It did the job of displaying my work, but returning to it later, I realized the layout was harder to read than it should have been; even I struggled to skim it, and I wrote the material. The visual design didn't reflect how I think about my own work, and nothing about it communicated a clear point of view.

In spring 2026, I decided to redesign it from scratch, starting by defining my personal brand: an engineer who approaches problems logically and communicates clearly. I used that as the design brief and built the entire UI myself. The most important structural change was introducing a two-layer content model: all detailed content is now hidden behind both a modal and a longform toggle, so the reader actively chooses how deep to go rather than being confronted with everything at once. The main view stays clean and skimmable by default. The visual design I built from scratch to match that brand now feels like it belongs to someone with a specific point of view rather than a generic portfolio template. I documented the full engineering and design process in a write-up.

• Built an ACC (Adaptive Cruise Control) system in Simulink with three autonomous operating modes: manual, fixed-velocity, and lead-car position-following
• Deployed the system onto an S32K144 microcontroller via Simulink's automatic C code generation, running on a physical driving simulator
• Developed a haptic interface embedded controller across earlier assignments using C, SPI protocol, and NXP software
• Designed PID controllers and vehicle dynamics models in Simulink to represent systems of differential equations
• Debugged subsystem behavior by analyzing oscilloscope waveform responses from sensor inputs

EECS 461 was an embedded control systems course built around progressively complex assignments, each adding a layer toward the final project. Throughout the semester, my partner and I developed a haptic interface embedded controller using an S32K144 microcontroller, C, and SPI (Serial Peripheral Interface) protocol in an NXP software workspace, writing C code to read from and write to hardware registers directly. We designed flow logic, PID controllers, and vehicle dynamics models in Simulink to represent complex systems of differential equations, and used an oscilloscope to analyze subsystem waveform responses for debugging.

The final project brought all of it together: an ACC (Adaptive Cruise Control) system with three operating modes and auto-steering active throughout. In Manual mode, the user controls speed and path through a potentiometer and haptic wheel. Velocity mode sets a fixed traveling speed via dip switches on the microcontroller. Position mode activates automatically when a lead car enters a preset distance and is traveling slower, matching its speed. We built the entire system in Simulink using scaffolding provided by the course instructors, then used Simulink's automatic C code generation to deploy it onto the S32K144 microcontroller running on a physical driving simulator.

{"The system performed successfully at the demo"=>"all three modes triggered and transitioned correctly, and the position-following behavior worked as intended."}

• Benchmarked five character classifiers in Python using scikit-learn against the EMNIST (Extended Modified National Institute of Standards and Technology) dataset (60,000 training samples): KNN (K-Nearest Neighbors), SVM (Support Vector Machine), Naïve Bayes, Decision Trees, and a LeNet CNN (Convolutional Neural Network)
• Selected the LeNet CNN for the full-scale model based on accuracy, speed, and MATLAB interface compatibility
• Implemented the LaTeX (a document typesetting language used widely in technical and academic writing) document formatting subsystem in MATLAB to convert classifier output into a structured, formatted document
• Led the project plan, defining subsystem ownership and deadlines across a five-person team
• Wrote the majority of project documentation across GitHub and the team website

EECS 351 was a digital signal processing course with a team project component. Our five-person team chose to build a pipeline to convert whiteboard lecture screenshots into formatted LaTeX (a document typesetting language used widely in technical and academic writing) documents, motivated by a real problem we had during COVID: students who miss class and rely on lecture recordings often can't read what's written on the board. The system ran in four sequential stages: image processing and filtering, character isolation, character classification, and LaTeX document generation.

I led the character classification subsystem, where I benchmarked five classifiers in Python using the scikit-learn library against the EMNIST dataset (a standard handwritten character dataset with 60,000 training samples): K-Nearest Neighbors, SVM (Support Vector Machine), Multinomial Naïve Bayes, Decision Trees, and a LeNet CNN (Convolutional Neural Network), each implemented in their own Jupyter Notebook. SVM achieved the highest accuracy at 90.87%, but I selected the LeNet CNN for the full-scale model because SVM's training and testing time was prohibitively slow and the CNN had a cleaner interface with the broader MATLAB codebase. I also owned the LaTeX document formatting subsystem, which I implemented in MATLAB to take the classifier output and generate a structured document with metadata fields and LaTeX syntax support like superscripts. I led the project plan as well, defining subsystem ownership and deadlines, and wrote the majority of the documentation across GitHub and the team website.

The full pipeline worked end-to-end on block handwriting under good lighting conditions. The main failure modes were light-colored markers, slanted writing, and ambiguous character pairs like O vs. 0 and l vs. 1, limitations we documented and attributed primarily to training data constraints rather than architectural issues.

• Co-authored a research paper with a partner analyzing an autonomous bicycle robot model in Simulink, covering the Pure Pursuit control system, vehicle dynamics, and PRM (Probabilistic Roadmap) path planning algorithm
• Tested PRM robustness across three maps of increasing obstacle coverage (20%, 50%, 73%), varying node count and connection distance across 10,000 trials per configuration
• Found that higher node counts consistently outperformed longer connection distances for path-finding success, with success rates ranging from 100% to 0% depending on map complexity and node count
• Identified diminishing returns beyond 100 nodes, suggesting an optimal node count exists for any given map
• Implemented a custom bicycle plant model in Simulink using continuous time integration, producing smoother paths than the original discrete time implementation

MATH 462 was a mathematical modeling course in which my partner and I chose our own research topic for the final paper. We decided to investigate an autonomous bicycle robot model in Simulink, focusing on three areas: the existing control system, the vehicle dynamics, and the robustness of the PRM (Probabilistic Roadmap) path planning algorithm.

The PRM algorithm distributes randomly placed nodes across a map, connects any two nodes within a specified Euclidean distance, and uses Dijkstra's algorithm to find the shortest path from start to goal. To test its robustness, we varied node count and connection distance across three maps of increasing complexity: 20%, 50%, and 73% obstacle coverage. The results were concrete: on the simplest map with 100 nodes and a long connection distance, the algorithm found a valid path in 100% of trials. As map complexity increased and node count dropped, success rates fell sharply, to 0% on the most complex map with only 5 nodes. We also found that increasing node count from 100 to 300 produced diminishing returns on path quality, suggesting an optimal node count exists for any given map beyond which additional nodes only increase computational cost without meaningfully improving the path.

On the vehicle dynamics side, we implemented our own plant model in Simulink using continuous time integration to solve the bicycle's kinematic equations, the system of differential equations governing its x/y position and heading angle. Compared to the original model's discrete time integration, our version produced a smoother path, which we attributed to continuous integration better capturing the underlying dynamics of a physical bicycle.

• Built the back end of a functioning superheterodyne AM radio from discrete components: bandpass filter to isolate a target frequency range, envelope detector to demodulate the AM (Amplitude Modulation) signal, and output amplifier to boost audio, all wired in series to a speaker

EECS 216 was an introduction to continuous-time linear systems, covering convolution, Fourier series and transforms, frequency response and filtering, the sampling theorem, and Laplace transforms with poles and zeros. The course tied theory directly to application; lectures covered analog communications and feedback control alongside the mathematical foundations, and five labs put those concepts on physical hardware.

The final lab was the one that brought the most of it together: building the back end of a functioning superheterodyne AM radio from discrete components. Starting from the antenna input, I wired a bandpass filter built from resistors and capacitors to isolate a specific frequency range, an envelope detector using a diode and capacitor to demodulate the AM (Amplitude Modulation) signal by extracting the audio from the carrier wave, and an output amplifier using op-amps to boost the recovered audio signal before sending it to a speaker, all connected in series. To tune to a station, I adjusted the local oscillator frequency to shift a target broadcast into the bandpass filter's range.

• Implemented SillyQL, a simplified SQL (Structured Query Language) query engine in C++, supporting table creation, row insertion, and queries on large datasets
• Made data structure design decisions based on space and time tradeoff analysis to meet performance constraints at scale

EECS 281 is Michigan's core data structures and algorithms course, centered on understanding and navigating the space and time tradeoffs in algorithmic design. The curriculum covered hash tables, binary search trees, graph algorithms, sorting algorithms, priority queues and heaps, and dynamic programming.

The final project was SillyQL, a simplified version of SQL (Structured Query Language, the standard language for querying relational databases). The core challenge was parsing large datasets efficiently: the project required designing a system that could create tables, insert rows, and execute queries, all while choosing the right underlying data structures to meet performance constraints. I used hash tables for fast lookups and binary search trees for ordered queries, selecting between them based on the access pattern the query required.

• Took an unpaid internship before college to get firsthand exposure to engineering research; supported PhD students studying hydrophobic aluminum treatment methods for arctic-bound container ship hulls
• Designed and built an experiment at the end of the summer to test how different phase change materials retained heat under varying ambient conditions, using lab facilities and materials from the PhD team's own research

The summer before starting college, I took an unpaid internship at a mechanical engineering research lab at George Washington University, mostly to get a firsthand sense of what research looks like before deciding how much to pursue it in college. The day-to-day was unglamorous: compiling notes from research papers, washing labware, preparing samples, and taking observations during experiments. I supported PhD students studying hydrophobic aluminum treatment methods to prevent hull cracking in container ships bound for arctic regions.

At the end of the summer the team gave me free rein to pick a topic related to the research and use the lab facilities to explore it. I designed and built a metal block with a grid of drilled cavities to test how different phase change materials (materials the PhD students were evaluating) retained heat under varying ambient conditions. The experiment involved heating the block for a set duration, then measuring how long each material held its temperature once removed from the heat source.

• Compiled and synthesized hundreds of testing documents into executive summaries conveying key Lessons Learned to Navy leadership in the Unmanned Maritime Systems Program Office (PMS 406)
• Collaborated with senior engineers to organize a multi-day leadership conference for Unmanned Undersea Vehicle (UUV) Homeport program managers
• Recognized for exceptional communication and documentation skills by the Strategic Capabilities Office (SCO); PMS 406 extended a part-time continuation offer into sophomore year, which I accepted

I joined the Navy's Unmanned Maritime Systems Program Office (PMS 406) after my freshman year of college. I independently synthesized hundreds of testing documents into executive summaries conveying key lessons learned, delivering them directly to Navy leadership within PMS 406. I also collaborated with senior engineers to organize a multi-day leadership conference for UUV (Unmanned Undersea Vehicle) Homeport program managers. The Strategic Capabilities Office recognized my communication and documentation work at the end of the summer, and PMS 406 offered a part-time continuation into my sophomore year, which I accepted.

• Identified ODRI's original electronics architecture as the primary driver of cost and capability constraints; proposed and led a full electrical redesign replacing it with the MicroDriver v2 and Master Board system, quadrupling communication capabilities and motor control bandwidth while reducing costs by over 91%
• Built out the technical documentation foundation for external collaborators: cost analysis, wiring schematics, circuit tutorials, and a bill of materials on GitHub
• Co-authored a research paper documenting the redesign and presented findings at Michigan's SURE symposium

The Open Dynamic Robot Initiative (ODRI) is an open-source research effort to develop a low-cost quadruped robot as a platform for researchers worldwide to build and test control systems on, the goal being to lower the financial and educational barriers that have historically made robotics research inaccessible. I was one of two undergraduates selected to join the interdisciplinary research team through Michigan's SURE (Summer Undergraduate Research in Engineering) program.

My first contribution was improving the technical foundation for other collaborators: conducting a statistical cost analysis, creating wiring schematics, assembling circuit tutorials, and compiling a bill of materials on GitHub to track research progress. Once that foundation was in place, I identified that ODRI's original electronics architecture, built around TI evaluation boards requiring separate hardware per motor pair connected to the host PC via CAN, was the primary driver of both cost and capability constraints, and proposed replacing it with the MicroDriver v2 and Master Board system. I led the electrical redesign, reworking the robot's circuitry, computing, communication, and motor control systems: the Master Board manages all motor drivers simultaneously over a high-speed SPI bus and adds WiFi and Ethernet communication to the host PC in place of CAN, quadrupling communication capabilities and motor control bandwidth while reducing costs by over 91%. We documented the mechanical and electrical redesigns in a research paper and presented our findings at Michigan's SURE symposium.

• Completed the primary internship assignment within the first month: built LabVIEW GUIs to automate RF (Radio Frequency) characterization data collection across multiple ADI technologies, including a two-tone intermodulation distortion measurement GUI; authored a ZCG (Zero Code GUI) tutorial guide adopted by other ADI RF testing teams
• Independently identified and automated the senior engineering team's manual test results analysis process while manager was on vacation: built MATLAB parsers that generated RF characterization reports, compiled thousands of raw data files into spreadsheets, and produced hundreds of plots for the design team, saving days of engineering effort per input analyzed

I joined ADI's Aerospace and Defense team as an RF (Radio Frequency) test engineering intern, with a primary assignment to standardize RF characterization data collection for new chips onto a single platform: Zero Code GUI (ZCG) by Soliton Technologies. After completing LabVIEW Core 1 and 2 training, I built GUIs (graphical user interfaces) in National Instruments LabVIEW to automate data collection across multiple ADI technologies, including a GUI to measure 2nd and 3rd order two-tone intermodulation distortion using two signal generators. A ZCG tutorial guide I authored helped other ADI RF testing teams adopt the platform; I also contributed weekly UI improvement suggestions to the ZCG development team. The entire assignment was done within my first month.

With my manager on vacation for much of the summer, I spent the remaining time on a problem I had identified while going through the test results analysis process myself; it was slow and largely manual for the senior engineering team. I built several MATLAB programs to automate it: one parsed large datasets to generate RF characterization reports with tables of key statistics, and another sifted through thousands of raw data files to compile spreadsheets and hundreds of plots for the design team. My manager returned to find the work completed with a few days left in my internship. The automation saved the team days of engineering effort per input analyzed, and my accompanying MATLAB documentation left them equipped to tackle similar projects on their own.

• Promoted from Associate Autonomy Engineer within eight months, a track that typically takes 2+ years.

• Identified that the existing Python/Dash stack couldn't support internal deployment and independently rebuilt the application from scratch as a React TypeScript + Python FastAPI + PostgreSQL full-stack web application, designing the database schema and migrating 2GB of data
• Built a frontend geospatial Mapbox layer to both let users explore the full source dataset (flight network routes, projected emissions, infrastructure, and airport data) and visualize the optimizer's output: rendering which airport upgrade combinations unlocked which route sets, encoding CO2 savings as route line thickness and upgrade cost as airport marker size
• Identified that senior Boeing sustainable aviation stakeholders had no way to directly query the underlying dataset and built a high-performance data explorer using AG Grid: backend-driven filtering (value, keyword, sort, column reorder) over several GB of joined flight and airport data; URL-encoded query state for shareable links; JSON-serialized saved queries for fast state switching; and aggregate summary statistics across filtered results
• Owned all coding changes to extend the CP-SAT decision model with time-dependent logic, co-developing the math with the senior engineer who originally built the framework, allowing optimal technology selections to persist across multi-year planning horizons
• Designed targeted case studies for Boeing's senior sustainability team modeling the cost and emissions impact of key sustainable aviation technology investments across specific scenarios they wanted to explore, built an analysis tool suite producing charts like cost per kilogram of CO2 saved, consolidated everything into a 30+ page report, and presented findings to 25 engineers at a sustainability workshop in Seattle
• Produced the program's first comprehensive documentation suite for an 8,000+ line CP-SAT optimization codebase, enabling future developer onboarding on a mathematical framework too complex to approach without it; received an Aurora immediate recognition award

• Won first place in a two-week engineering hackathon by diagnosing and restructuring the Non-CO2 module: eliminating redundant queries and recomputations, cutting runtime from 17m 50s to 4.3s (99.6% improvement), and unblocking the module for customer deployment; received an Aurora immediate recognition award

• Selected among five Aurora engineers in a competitive downselect to continue the program, and placed on the highest-priority workstream: delivering the ICD (Interface Control Document), coordinating across six companies, architecting the documentation format, and driving on-time content merging for a hundreds-of-pages primary deliverable
• Built two automated verification tools to validate the ICD: a Groovy Cameo macro cross-validating thousands of message schema references against the reference architecture, and a Python Word parser flagging prose inconsistencies; recommendations from the latter were adopted into the program's syntax guidelines; received an Aurora immediate recognition award
• Designed Level 1 compliance requirements and a C2 (Command and Control) authority model for autonomous distributed systems; both passed Change Review Board across all participating companies

Aurora Flight Sciences is structured as an R&D company, meaning engineers rotate across programs rather than owning a single product long-term. In my time there I worked across six programs, earning a promotion from Associate to Autonomy Engineer in eight months, a track that typically takes two or more years.

• Assumed full technical ownership as the sole engineer on the reconciliations product, the foundation of Basis's core accounting workflow, when the previous lead departed two months after I joined.
• Owned end-to-end delivery of two 0→1 features for thousands of customers: defined product requirements by driving alignment across accountants and PMs, led system design with tech lead sign-off, implemented with unit/integration tests, authored QA plans, and shipped to production.
  • Custom-Month Reconciliations: replaced hardcoded calendar-month logic with support for any close cadence, unblocking Basis from acquiring customers whose books don't close on calendar months; authored a finalized product description for non-technical stakeholders and presented to the customer-facing support team ahead of rollout.
  • Future Periods: allowed accountants to view and plan up to 12 months ahead, backfilling all existing Tasks and Reconciliations into the future window with permission controls on future-month actions.
• Inherited a half-built Reconciliation Editor from a departing contractor, diagnosed and fixed blocking issues across frontend and backend, designed the QA test plan, and drove it to production.
• Resolved 30 customer bugs and 4 system-level performance issues using test-driven debugging practices, becoming the on-call production incident escalation contact as the reconciliations subject matter expert.

I shipped 3 features to production for thousands of customers and owned the entire reconciliations product area at Basis AI: a fully AI-native accounting startup that recently reached unicorn status. Within two months of joining, the engineer leading reconciliations departed mid-project, and I assumed full technical ownership as the only engineer actively working on one of the most critical parts of the product. All three features touched the full stack: TypeScript/React frontend, Python backend, and PostgreSQL database.

I drove 2 features through the same end-to-end ownership pattern, starting with product scoping: I worked with accountants and the PM to define clear principles for what the feature can and cannot do, covering business logic, user flows, scope boundaries, and open questions, and coordinated with the design team on Figma designs for new UI states, then secured sign-off on the product document before touching the code. Technical scoping followed: I documented the architecture approach as a sequenced milestone plan, where each milestone represents a complete workflow goal with steps, time estimates, and validation criteria, then got the engineering pod's tech lead's sign-off. Next, I worked through each milestone using coding agents in planning mode: reviewing the proposed architecture before any code was written and pushing back on anything deviating from the plan, adding unit and integration tests where steps touched business logic, and running QA validation after milestones that warranted it. Finally, I wrote the full-feature QA test plan, worked through it with the QA team to distinguish fixes from expected behavior, then enabled the feature flag for production rollout.

Custom-Month Reconciliations: I enabled the codebase, originally hardcoded to perform reconciliations only from the first to the last day of a calendar month, to support variable close cadences (e.g. quarterly (March, June, September, December) or annual), directly unblocking Basis from acquiring customers whose books don't close on calendar months. Because the change unblocked a new customer segment, a wide range of stakeholders had strong, conflicting opinions about what the product logic should do, and managing that alignment was the hardest part of the project. Technically, the hardest piece to pin down was the cadence change logic: defining what happens to existing reconciliation work when a user changes a reconciliation's cadence, and when that change is or isn't permitted. I authored a finalized product description for non-technical stakeholders and delivered an internal presentation to the customer-facing support team before driving it to production.

Future Periods: I extended the platform's planning horizon from the current month to 12 months ahead, enabling accountants to view and plan upcoming Tasks and Reconciliations proactively. Accountants interact with the platform by selecting a month to see all associated Tasks and Reconciliations; previously the furthest forward they could look was the current month. I backfilled database tables for all existing Tasks and Reconciliations to populate the full future window, and added layered permission controls: frontend guards for UX and backend enforcement at the service level. I also built user-facing messaging and redirect flows to handle restricted states.

In parallel, I took over the Reconciliation Editor, a replacement UX for the live editor, originally built by a contractor who left before finishing it. The code had been sitting dormant: core UI interactions were broken, including file linking that failed to resolve the correct month and category folder, and any change required mirroring updates across both editors simultaneously. I diagnosed and resolved the blocking issues across frontend and backend logic, designed the QA test plan to verify the feature end-to-end before rollout, and drove it to production.

On the production stability side, I resolved 30 customer bugs (including production hotfixes and database migrations to clean up duplicate records and session context errors) using test-driven debugging practices: writing tests to reproduce each failure before implementing a fix, then expanding the test suite to prevent regressions. I became the default escalation contact for on-call production incidents, and wrote detailed root cause analyses after each one. I also diagnosed and fixed four system-level performance issues: line item matching timeouts, database query bottlenecks in orchestration services, and chronic background job failures, unblocking jobs that had been failing entirely.

I left once the reconciliations area reached a stable state and I had fully handed it off. The experience of being the sole engineer on a high-priority product area accelerated my growth significantly, and it clarified what I was looking for next: a role where I could bring that same ownership mentality while also getting to collaborate with other engineers.

• Authored three developer guides covering Coral Care's existing no-code platform by tracing the full system layer by layer: mobile frontend, mobile backend, and a combined web app and database layer; surfaced undocumented behavior that now directly informs bug triage and maintenance across the team.
• Building the new full-stack TypeScript platform alongside a team of senior engineers, collaborating on architecture decisions and implementation as we replace the live no-code system.

Coral Care operates an in-home pediatric therapy marketplace connecting families to licensed speech, occupational, and physical therapists, serving thousands of daily active users across parents and providers. They have built a defensible position in an exceptionally hard niche: at-home pediatric care with insurance coverage, at a scale no competitor has matched. The engineering team, founded in March 2026, is rebuilding the platform as a unified full-stack TypeScript application, replacing a no-code solution across three separate tools that has become slow and unintuitive at the product's current scale. I joined as the fourth engineering hire.

My first project was documenting the existing no-code platform, which had no documentation and an unusual architecture: three tools covering a fragmented split of mobile frontend, mobile backend, and a shared web app and database layer. I worked through it one layer at a time, tracing data flows and mapping how the pieces connected. The guides now serve as the team's reference for diagnosing bugs and making maintenance decisions, and the investigation surfaced concrete details about system behavior that shortened debugging time on issues that previously had no clear starting point.

In parallel, I have been building out the new TypeScript codebase alongside the rest of the engineering team. We work through architecture decisions together and shape how the product's software is structured collaboratively. Working closely with senior engineers with deep experience building scalable systems has accelerated both my TypeScript expertise and my broader understanding of how to reason through architectural tradeoffs at scale.

• Tutored guitar to Detroit students through a University of Michigan nonprofit providing free music education in underserved communities, freshman through senior year
• As Director of Music, coordinated tutor and student attendance across multiple locations, managed financial expenditures, and planned end-of-term public showcases giving students a real performance experience

I started tutoring guitar at Seven Mile during my freshman year of college because I resonated with their mission of providing equal access to arts education in underserved communities. A few hours a week watching students grow, as musicians and as people, was one of the most rewarding parts of my time in college.

In my senior year, I stepped into the Director of Music role to get more involved. That meant coordinating tutor and student attendance across multiple locations, managing financial expenditures, and planning public musical showcases at the end of each term where students could perform for their communities. The showcases were the highlight of each term, bringing together tutors, students, and venues to give students a real performance experience and a chance to celebrate their progress.