Skip to content
AboutHyderabad · remote

I build the whole thing,
then I have to live with it.

solder to type

I'm a Senior UX Architect and UX Engineer. I work on enterprise telemetry, IoT hardware interfaces, and the full-stack applications that sit on top of them — usually the kind of system where the hardware and the software argue with each other, and somebody has to own both sides of the argument.

Sathvik Reddy
Hyderabad
9
Systems shipped

the registry in full — nothing here is a concept

5
Layers I work across

hardware, firmware, data, interface, design system

1
Needed all five

Farm OS

The stack

What “the whole thing” actually means.

Five layers, from the solder to the type. Every count below comes from the same registry the work index renders, so you can check any of it by opening the case study behind it.

Cells are shipped systems that required me to own that layer, out of 9 — a count, not a proficiency score. Select a layer to see what it meant and which systems needed it.

Solder to type

Five layers, 9 systems. Farm OS needed all five — hardware through to the type on the dashboard.

Each system, and how many of the five layers it needed.

Experience

Where the work happened.

Rows with a case study behind them link through. The rest don't — a history where most entries dead-end costs more trust than a short honest one.

  1. Spectrum

    Senior User Experience Designer

    Leading end-to-end UX architecture for enterprise products and scaling the design system.

    2026 —Enterprise SaaS

  2. Natural Meat

    Founder & Product

    Built and ran a direct-to-consumer meat business around a 30-minute freshness promise.

    2025D2C E-Commerce

  3. Winsupply

    UX Designer

    Designed and front-ended the purchasing platform for ~600 local companies, and themed its PrimeNG component library to the brand.

    2022 — 2025Design Systems

  4. Savannah College of Art and Design

    UX Designer

    B2C student portal for schedules, financial aid and assignment tracking — research through to documented design-system components.

    2019 — 2022Higher-Ed Platform

  5. Mahindra Logistics

    UX Designer

    Real-time tracking dashboards; 25% improvement in operational visibility.

    2019Fleet & Warehouse

Systems notebook

How I think about building systems.

Three tenets from field deployments, enterprise pipelines and hardware prototyping. Each one has a working demonstration rather than a claim.

Tenet 01Offline UX

Design for the worst connectivity

Offline-first SQLite caching is what kept field operations running in dusty poultry sheds when the cell signal dropped to nothing.

StatusOnline — synced
ACID transaction queue0 records
Tenet 02Physical UX

Hardware is just physical UI

A printed PETG enclosure and a status LED need the same rigour as a mobile screen. The seams between them are where users get hurt.

Passive airflow vents

45° angled louvers that prevent water ingress while still sampling ambient gas.

Tenet 03Token pipeline

Design tokens as living code

A token that only exists in Figma is a suggestion. One the build reads is a contract — and the difference shows up as hand-off friction.

Live token
--color-dd-sky#D0F2FF

Enterprise telemetry — dashboards, alerting, device fleets

These are this page's actual tokens, read from the same source the stylesheet compiles from — not a mock-up of one.

How I got here

I started in logistics, building real-time tracking dashboards for a fleet operation that could not afford to guess where anything was. That is where the habit formed: if a system can't tell you its own state, everything downstream of it is speculation.

Design systems came next: at Winsupply I built a multi-tier token pipeline linking Figma to component contracts — the tenet above, in production rather than in a slide.

Then I went and built Farm OS, which forced me out of the IDE entirely. Understanding the specific panic of a 40°C afternoon in an environmentally controlled poultry shed is not a research method you can run over a call. The decisions that mattered were not screen decisions: where to physically mount a sensor head, what a node should do when its own network is gone, whether an alert should be allowed to wake somebody at 2am.

Owning everything from the solder on the board to the type on the dashboard is what made that product cohesive. It is also what convinced me that hardware and interface are not two disciplines meeting at an API. They are one product, and the seams are where users get hurt.

Working together

Three shapes this usually takes.

01

Audit

You have a system that works and an interface that argues with it.

A read of the whole stack — data model, states, failure modes, and the screens sitting on top. What comes back is what is actually wrong and in which order, not a redesign.

02

Embedded

You have a team and a gap where the systems thinking should be.

Inside your process and your repo, design and front-end both. Specs handed across a wall are where the seams appear, so I don't hand them across a wall.

03

Full build

You have a problem and there is no system yet.

Solder to type: hardware if it needs hardware, the data model, the interface, and the design system that stops the whole thing forking six months in.

What I'm good for

Systems with real operational consequences, where the interface is one layer of a stack that includes firmware, data and a physical environment. I'm least useful on work that is purely visual and has no state to reason about.

If any of this sounds like your problem.

Tell me what the system does, what it does wrong, and who it hurts when it does. That is enough to start from.

sathvikkotha@gmail.com