Making marathon carb loading simpler with carbs.

Marathon participation is growing. The 2025 London Marathon saw 56,640 runners finish, setting a world record at the time. Strava’s 2025 Year in Sport report also recorded a 3.5-fold increase in running clubs on its platform.

Runners track distance, pace and training. Tracking race-week fuel can be harder. How do you know whether you have eaten enough carbohydrate before race day?

Carb loading increases the glycogen stored in the muscles, helping delay fatigue during prolonged endurance exercise. HPRC’s carb-loading guidance explains its role in preparing for events lasting 90 minutes or more. Tracking intake makes progress towards a planned target visible, rather than leaving it to guesswork.

Carb-loading calculators provide a target. I focused on what comes next: turning that target into meals, snacks and drinks, then tracking intake throughout the day.

I designed carbs. to connect those tasks: plan your load, log what you eat and see what remains.

I designed and built carbs., from product direction and visual design to onboarding, food logging and implementation.

I also designed how targets change, entries are saved, storage failures are handled and runners return to their plan.

The free beta gives runners a working product to try and helps me identify what to improve.

Onboarding has three steps: personal details, race details and plan review.

The app uses body weight and a selected loading rate to calculate a daily target. Weight entry supports kilograms, pounds, and stone with additional pounds.

Onboarding helps runners understand their loading duration and daily carbohydrate intake before committing to a plan. The review brings together a two- or three-day loading window and a choice of 8, 10 or 12 g/kg per day, translating the selected rate into a daily target in grams. Contextual guidance explains the choices, while an example day helps runners picture what that intake means in food and drinks. They can adjust their target later.

The profile only asks for information the plan uses, leaving out gender, predicted finish time and dietary preferences.

The race date also gives the experience a clear timeline. Before loading starts, Today shows a countdown. During the loading window, it becomes a diary with separate days. Race-day breakfast has its own target and context.

The Today screen gives the daily target a clear visual centre: a progress ring showing what has been logged and what remains.

Logging a meal updates the ring, connecting the action to its result. Food is grouped into breakfast, lunch, dinner and snacks, making the diary easier to scan than a single undifferentiated list.

The diary also shows progress against suggested meal amounts. These give the daily total a more manageable shape while keeping the overall target visible.

A small confetti moment marks crossing the target. It runs when the runner reaches that point, rather than every time a completed day is reopened, and respects reduced-motion preferences.

Optional meal descriptions let runners log several foods in everyday language, then review the foods and portions together.

The catalogue comes first. Familiar descriptions resolve locally. When local matching cannot understand the description, AI can identify foods, quantities and preparation details. Those items are matched back to the catalogue for their carbohydrate values. Interpreting a description and calculating nutrition are separate steps.

Missing details become questions rather than hidden assumptions. A description such as “my usual bagels with jam and a large glass of apple juice” can lead to a follow-up about the amount of jam. Ordinary portion replies are handled locally; another AI request is an explicit choice if a reply still needs interpretation.

Runners review the result before saving. They can amend catalogue matches and portions, then check the total before Confirm & save. A separate “Estimate with AI” option for unmatched foods shows an approximate carb amount, its serving basis and assumptions. It remains editable and requires acceptance followed by final diary confirmation; saved entries retain an “AI estimate” label.

The feature is off by default in Profile. AI runs only on an explicit request, with “Checking your request…” and “Identifying foods…” making the wait understandable. Errors and cancellations keep the description available, and no unconfirmed entry is added to the diary. Search, barcode lookup and manual entry remain available.

The experience now continues beyond race day. A completed-load recap brings together the carbohydrates logged during the loading window, the days represented and food highlights. Race-morning food is counted separately, so the summary preserves the distinction between loading and race-morning fuel. Runners can also leave themselves a note about what to repeat or change next time.

Runners can plan another race without losing the previous one. Starting a new plan archives the earlier race, its targets and shopping list. Progress includes a race selector to revisit previous plans, daily records and recaps, while recent foods remain available for the next load.

Records stay in the browser, and exports include both the current plan and previous races.

A diary needs to preserve the meaning of what has already been recorded. When a runner changes their plan, logged days keep their saved targets; changes apply to days they have not logged yet.

Future dates are read-only, while existing entries can be amended. Confirmation dialogs protect unsaved changes, deletions and imports.

If a storage write fails, the app retains the form and rolls back the unsaved change. Backup imports are validated before replacing current records, and unreadable browser data opens a recovery flow. This is less visible than the progress ring, but just as important: an interface should not imply that a meal has been saved when it has not.

Keyboard reviews and automated accessibility checks informed improvements to focus handling, text contrast, form controls and mobile navigation. Those checks help refine the experience; full accessibility conformance still needs manual assistive-technology testing.

The roadmap focuses on easier preparation, reliable records and testing demand for paid race tracking. Some improvements can progress independently.

Sharing, reminders and native apps are proposed opportunities. They need validation alongside feedback from runners, rather than a fixed release date.