i'm amelia

every part-number changeover on the line required tool & die involvement, a side effect of how the mold's water-system was routed, adding 1.5+ hours of downtime per change across 1,500+ annual changeovers.

redesigned the exchangeable mold inserts to remove the water-system interference entirely, then built the cost-justification case myself, pulling component measurements and weight data programmatically from siemens nx and trial records to support the pricing validation. scoped the fix around what the floor could actually adopt without new equipment, since a redesign nobody could implement on the existing line wasn't worth proposing.

floor technicians shouldn't need to pull in a specialized team for a routine changeover. removing that dependency meant faster changeovers on the floor and freed up tool & die for work that actually needed them.

~$67,500 saved annually, with the case built on real trial data rather than estimates.

raw telemetry came in as messy CSV and MATLAB logs, noisy enough that it was hard to trust damper readings during chassis and suspension validation.

engineered a python pipeline that processes raw logs automatically, computing damper velocity via numerical differentiation and applying signal smoothing to cut sensor noise, then piped the cleaned data into a shared team viewer for real-time analysis during testing. scoped it around what the chassis sub-team actually needed first, damper velocity and noise reduction, rather than trying to build out every possible telemetry channel at once.

chassis decisions are only as good as the data behind them. the team needed to trust what the dampers were saying before validating suspension changes on the actual car.

real-time damper analysis during testing sessions, feeding directly into the torsional stiffness validation work (~1,200 nm/deg).

a moldex3d simulation was predicting 2.77% shrinkage on a part, against a validated real-world baseline of 1.4%. that gap would have sent tooling decisions down the wrong path.

ran the full mold-flow workflow myself, pulling part geometry, hot runner, and cooling-line CAD from siemens nx into moldex3d, then traced the discrepancy back to pressure: the simulation was running pack pressure at 39.7 MPa against an input of 56.2 MPa. iteratively tuned the pack pressure across simulation revisions and validated each pass against CMM measurements from a real physical mold trial, checking four tracked dimensions until the simulated shrinkage lined up with the actual parts.

more pressure means less shrinkage, since it holds the plastic from coiling back as it cools. if the simulated pressure is wrong, the shrinkage number is wrong, and every downstream mold decision inherits that error.

confirmed pack pressure, not part or mold geometry, is the primary driver of shrinkage prediction accuracy, and got simulated shrinkage to line up with real CMM-measured parts. presented the validated calibration loop at DENSO's North America College Program, with the recommended next step being to keep calibrating across more parts and move it from proof-of-concept into a consistent simulation tool.

finding a compatible study group at umich is mostly informal, group chats, flyers, word of mouth, with no structured way to match on both hard logistics (course, section, availability) and softer fit (study style, goals).

modeled the matching problem as constraint satisfaction: hard constraints (course, section, verified availability) handled with rule-based logic, softer signals (study style, group fit) inferred conversationally over text. own concept, legal setup, naming, campus validation, and marketing, plus hands-on coding and AI tooling work; my collaborator leads the backend and matching logic.

most students won't download a new app for something this occasional. texting a number is a lower-friction front door, which meant the matching logic had to do more of the work than a swipe-based interface would.

ran informal interviews to validate demand, now targeting a winter pilot with EECS 183 and CHEM 130.

the ply tracker (which composite ply goes where, in what order, on the car) and the hole tracker (which holes get drilled, with which inserts) both lived in one dense spreadsheet, technically organized, but overwhelming to actually use in the moment. the ply tracker had no way to show which part of the car a piece belonged to, and the hole tracker buried its safety notes in a wide row easy to scroll right past.

talked through goals directly with the team's lead on manufacturing tracking, then reviewed last year's spreadsheet and came back with a full redesign: one ply per card instead of a full grid, each card showing a zone render, orientation sketch, layer sequence, core buildup spec, and any notes specific to that piece. a "mark done" action that auto-advances to the next ply, and a short "up next" queue standing in for the old 20+ column table.

iterated from there: split the status flow into two modes, material prep and layup, instead of one long list of six status states. for the hole tracker, proposed a hard gate so an insert can't be marked done until its hole is confirmed first. also proposed building the 3D car renders once and reusing them across both trackers instead of duplicating the work.

someone standing at the layup table doesn't want to scan a 20+ column table to find their next step, they want to know what's next and confirm it's done. designing around "what do i do right now" instead of "here's everything at once" meant the tool actually matches how the work happens on the floor, not just how it's recorded after the fact.

currently building a demo of the ply tracker, targeting mid-september so the team has real time to iterate before manufacturing starts.

a tattoo artist offers ink in exchange for sourdough lessons, a haircut, or a new portfolio website, and someone with that skill claims the trade instead of paying cash. that behavior already happens informally, scattered across DMs and comment sections with no discovery and no way to find a want that matches a have. In-Kind gives it a real home: a browse feed, a full listing page, a propose-a-trade flow, and trade status tracking.

researched existing barter platforms and found the same gap in every one, no structure for comparing services that aren't equal in value. found a live r/AskUK thread describing almost this exact scenario, and a barter app in Spain (SACO) that launched the same week i started this project, which told me the problem was real, not invented.

mapped the site in two passes: discovery (search, browse, filter, all converging into one shared feed) and the trade lifecycle (propose, accept, decline, or counter, looping back instead of dead-ending). caught a real trust gap mid-build, my first version let one person mark a trade "complete" without the other confirming they'd received their end. rebuilt it so both sides confirm independently, with a waiting state and a dispute path if someone never does.

research kept surfacing the same blocker across every platform: no good way to compare unlike services at a glance, most force a rigid 1:1 credit system or leave it fully to negotiation. so each listing states specific offers and specific wants up front, tagged, readable in under 30 seconds with zero back-and-forth needed to understand the terms.

trust concerns centered on no-shows and quality, not fraud, since no money is ever at stake. so profiles lead with rating, trade count, response time, and distance instead of just a name and photo, and that same logic extends into the trade itself with two-sided confirmation before anything closes.

the matching problem here is basically constraint satisfaction with soft signals layered on top, hard constraints like category and location, soft ones like fit and trust. that's the same lens i bring to a physical build. different material, same throughline.