Michael Tyler Smith
Discuss a problem

Michael Tyler Smith

Software Engineer & Technical Problem Solver

I turn difficult technical and operational problems into reliable software.

Backend systems, automation, integrations, internal tools, and the investigation needed to improve existing systems without making them harder to own.

View work GitHub Résumé

Alabama-based · Working across software, data, devices, and operations

Michael Tyler Smith
01

Software across boundariesHardware · applications · workflows

~8 min → ~3 secMeasured AutoCAD workflow

2,000+ linesProduction AutoLISP application

Hardware → UIRV-C/CAN data verified on devices

End-to-endPublic full-stack commerce demonstration

01 / Selected work

Evidence, not a technology list.

Three examples of understanding a difficult system, making the consequential engineering decisions, and delivering a usable result.

Engineering automation · Clayton Homes

Turned an eight-minute drawing workflow into a three-second command.

A repetitive production-preparation process and a geometry-heavy plan-reversal problem needed dependable automation inside an existing AutoCAD workflow.

Measured workflow~8 min → ~3 sec
Problem
Print-pack preparation combined image capture, boundary selection, drawing setup, text fields, and printing. Reversed floor plans also needed corrections that a simple mirror could not provide.
Engineering decisions
Gathered requirements from engineering and office users, then encoded the workflow in a 2,000+ line AutoLISP application. A separate tool classified entities and applied object-specific translation, reflection, rotation, and structural corrections.
Result
The measured print-pack workflow fell from approximately eight minutes to about three seconds. The tools supported day-to-day engineering and office work and removed the need to redraw reversed plans.

Connected systems · Firefly Integrations

Made raw RV telemetry understandable—and kept the interface responsive.

Multi-battery hardware had to become clear application state while frequent device updates were creating visible interface lag.

Telemetry window500 ms
Problem
An Ionic application consumed data from batteries, inverters, generators, and other RV equipment. The system needed pack-level identification, individual state-of-charge values, and smoother high-frequency updates.
Engineering decisions
Inspected RV-C/CAN messages, translated payload fields, and traced device identifiers through the existing system. Added Xantrex multi-battery handling, a selectable radial display, and 500-millisecond processing windows.
Result
The interface could distinguish battery packs and show their state individually. Batching addressed the observed UI lag, and displayed values were checked against connected hardware.

Full-stack delivery · Independent project

Built a complete commerce workflow, then simplified how it runs.

A small-business storefront needed customer, payment, fulfillment, and administration workflows without making server maintenance part of day-to-day operation.

Deployment statePublic demo
Problem
The application had to coordinate persistent carts, accounts, checkout, orders, inventory, address validation, email, and administration across several external services.
Engineering decisions
Built the application with Next.js and PostgreSQL, integrated Stripe, USPS, and Resend, and separated customer and administrator workflows. Migrated the original Docker-first deployment to Vercel and Neon after evaluating the project’s hardware and maintenance constraints.
Result
The application is publicly deployed as a functional demonstration. Stripe remains in test mode, there is no established commercial transaction volume, and those limits are documented rather than presented as traction.

02 / Capabilities

Useful where the problem is messy.

Technologies change by context. The durable capability is understanding the system, choosing the right intervention, and leaving it more reliable than it was.

Ambiguity → working software

Turn incomplete requirements into a system model, explicit constraints, and a practical implementation path.

Requirements gathering · end-to-end delivery

Backend systems & APIs

Design server-side workflows, persistent data, authentication, and service boundaries that remain understandable as a product grows.

Next.js · PostgreSQL · REST APIs

Automation

Convert slow, repetitive operational work into repeatable tools without losing the edge cases operators know matter.

AutoLISP · AutoCAD · manufacturing workflows

Integrations & data

Trace data across devices, protocols, APIs, and databases; translate it into a contract the rest of the system can trust.

RV-C / CAN · Stripe · USPS · Resend

Investigation & debugging

Trace symptoms across protocol fields, device identifiers, telemetry, and application state, then verify behavior against connected hardware.

RV-C/CAN inspection · UI-lag diagnosis · hardware verification

Internal tools

Build around the people who operate the process: their sequence, failure modes, maintenance burden, and verification needs.

Engineering and administration tooling

Practical AI engineering

TODO: Add a public case study covering the actual task, evaluation, safeguards, and operating results before presenting this as demonstrated work.

Not presented as demonstrated experience

03 / Engineering approach

Reason from evidence. Build for use.

The approach is consistent whether the system is a vehicle network, an engineering drawing, or a checkout pipeline.

  1. 01

    Understand the whole system.

    Map the path from input to outcome before changing code. The useful bug is often at the boundary between components.

  2. 02

    Design for the operator.

    A technically valid system can still be wrong if it creates an unrealistic maintenance or workflow burden.

  3. 03

    Verify against reality.

    Check behavior at the source of truth—connected hardware, persisted state, actual geometry, or the person doing the work.

  4. 04

    Make limits visible.

    Document responsibility boundaries, untested assumptions, and missing validation so the next decision is based on evidence.

04 / About

Built for the real system.

I’m an Alabama-based software engineer whose professional work has crossed connected hardware, manufacturing operations, and full-stack product delivery.

I do my best work when the code is only one part of the problem.

That has meant reading protocol documentation and raw CAN messages, learning how people prepare engineering drawings, tracing state through an existing mobile application, and choosing infrastructure that reduced the application’s maintenance burden.

I earned a B.S. in Computer Science from Purdue University Global in 2023 with a 3.9 GPA. My background also includes public-safety work and service in the U.S. Navy Reserve and Army National Guard.

View full résumé

Experience snapshot

  1. Independent Software DeveloperDopamineDrip Studios
  2. Software Developer — Engineering AutomationClayton Homes
  3. Software DeveloperFirefly Integrations

05 / Contact

Bring me the technical problem.

If a workflow is slow, systems do not agree, critical software is hard to change, or an idea needs an implementation path, send me the context and constraints.

Email Michael LinkedIn GitHub