# Rebuilding the Trophos UI in a week

> Our first build worked but felt generic. Here is how we rebuilt the look, the screens and the food model, and shipped it to testers in a week.

Canonical: https://trophos.ai/blog/the-trophos-redesign
Markdown: https://trophos.ai/blog/the-trophos-redesign.md
Status: Trophos is in waitlist phase. The app is in closed testing, is not publicly downloadable, and has no paid offering yet.

---

By The Trophos team · Published 2026-05-28 · Tags: design, product, engineering

## From prototype to product

The first version of Trophos worked. It also felt like a first version. The
whole app was tinted Garden green, the home screen was built around a calorie
ring, and most screens did their job without much character. We kept opening it
and feeling a little flat.

Our testers landed on the same thing in their own words. A few of them said it
reminded them of the trackers they were already trying to leave. That was the
note that stuck, because they were right: we had built something competent that
blended into a crowded shelf.

So we set the surface aside as its own project and rebuilt it from the tokens
up.

## One system, chosen on purpose

We started from a mood and let it decide everything: maritime. Fog-gray light,
deep navy ink, and a single cobalt that does the pointing. Primary buttons go
near black so the main action is always obvious, while cobalt stays the accent
for highlights and links. Each macro gets its own color, so protein, carbs and
fat read at a glance.

<Palette />

Type does the rest of the work. Inter carries everything you read, JetBrains
Mono carries every number you scan, with tighter tracking on the big headings.

<TypeScale />

## The screens people live in

We rebuilt the high-traffic screens first. Each one moved from simply showing
data to having a clear point of focus.

<Compare before="/blog/home-old.png" after="/blog/home-final.png" caption="Home is now a deck of swipeable cards over a time-of-day photo. Each card is a different lens on your day: calories and macros, micros, the weight trend, wearables, the next smart move. We wanted the first screen to feel alive and to surface the one thing worth seeing right now, instead of a single static ring." />

<Compare before="/blog/diary-old.png" after="/blog/diary-final.png" caption="The diary opens on a live day score that grades the day as you log, backed by a real micronutrient panel rather than macros alone. Below it, one time-ordered feed shows food, water and exercise together. We wanted you to read how the day is going in a second, then see everything in a single thread." />

<Compare before="/blog/trend-old.png" after="/blog/trend-final.png" caption="Progress became Trend, and it tells a story instead of drawing one line. Your photos, the weight line, a logging-consistency heatmap and a milestone journey sit in one view. We wanted progress to feel like something you are building, with proof you can scroll through." />

<Compare before="/blog/search-old.png" after="/blog/search-final.png" caption="Search leads with food and shows a photo on every result, with foods and recipes split into their own tabs. We wanted you to recognize a food by sight and log it in a couple of taps, the way you actually think about meals." />

<Compare before="/blog/food-old.png" after="/blog/food-final.png" caption="Food detail puts a real photo and the numbers that matter up top, with serving sizes as quick chips and the full micronutrient breakdown below. We wanted it to answer two questions fast: is this good for me, and how much am I having." />

## A food model that thinks in meals

We reworked the data underneath too. Foods now split into raw ingredients and
ready-to-eat items. Raw ingredients combine into recipes, so a chicken power
bowl logs as one item instead of five. Every food also carries a full canonical
micronutrient profile, which is what powers the diary's micro read and the
trend insights.

<Figure src="/blog/recipe-final.png" alt="Recipe detail with photo and grouped ingredients" caption="A recipe logs as one item, photo and macros included." maxWidth={230} />

## How it shipped in a week

The speed came from a workflow with clear lanes for design, code and review.

We explored directions in Paper, our design tool, and used MCP so the same
assistant could read the Paper file and the codebase in one place. Design and
implementation stayed in a single conversation, which is usually where time
gets lost.

Coding agents then turned the agreed direction into real screens, tokens and
seed data, always working against a live web build so we were looking at the
running app instead of a static mock.

Everything moved through one path. A Linear issue captured the intent, a pull
request carried the work, and an automated review ran on every PR before it
merged. We leaned on Codex and CodeRabbit to audit each change on GitHub, flag
bugs and catch the small regressions that slip through when you move fast. That
review net is a real part of why a week was enough, and why moving quickly did
not mean shipping carelessly.

Every screenshot in this post comes straight from that build.

## See for yourself

The demo on the [homepage](/) is this exact app, running on real data. Open it
and have a look.