All your bottles, one ritual

Pielio is a personal skincare-routine tracker. Build an AM/PM routine from the products you actually own, check it off morning and night, and keep a record of what you've used with a rating and a note. I wanted an app you'd open without sighing first.

A few things shaped how I built it: two years running an e-commerce business selling skincare products, being a skincare freak myself, and building it live with Claude Code instead of working from static mocks.

You can check out the app at pielio.netlify.app.

The two patterns behind Pielio came from two different places.

The first came from the store. I ran a skincare e-commerce shop for two years and spent a surprising amount of it talking to customers about their routines. Some had five or more active products on different schedules: a retinol on certain nights, a mask once a week. They coped with sticky notes on bottles or a checklist taped inside the bathroom cabinet.

The second came from my own research into how people actually live with skincare: YouTube videos, articles, and especially the comment sections under them. That's where a different kind of struggle kept showing up. These people had a dead-simple routine and knew exactly what to use, but on a hard day even applying a cream felt like a big step. The PRD has a name for this segment: “low-energy / mental-health-aware users.”

Two different problems, really. One is remembering what goes where and when: AM vs PM, which days, what you already tried and liked. The other is just showing up, especially when you're tired or struggling.

The second is the one I kept finding in comment sections: people who knew exactly what to use and still couldn't make themselves do it on a hard day. A reminder doesn't fix that. The app has to make doing the routine feel lighter than skipping it.

I write the PRD, then build directly in the browser with Claude Code. There's no separate design phase before the build phase. It's one continuous loop: every decision gets checked against a real, running screen instead of a static mockup.

Claude writes the code. My job is everything around it: deciding what to build and in what order, spotting what's wrong on a real screen, turning “this feels off” into a specific instruction, and writing settled decisions into the project's rule files so they hold. The design work moved to the edges: into the spec before a screen exists, and into the review once it renders.

Onboarding is built around one decision: no questions. Many apps in this space open with a long intake quiz, skin type, concerns, goals, before you've seen anything. I wanted the opposite feeling, short, fun, informative enough to make you curious what's next. So it's three slides and you're in.

The second decision: nobody should land in an empty app. Straight after the slides, the user is guided into adding their first product, and a spotlight coach-mark then points at Routine, where that product lives. By the time onboarding is over, there's already something real on the screen.

Today — the daily checklist and the app's home screen

Today is the daily AM/PM checklist and the app's home screen: a progress bar, the current week, and a tap-to-check list.

This is the screen that has to solve the motivation problem. Checking off a step takes one tap. The progress bar fills as you go and finishing sets off a small celebration. I left out streak counters and guilt copy on purpose, so a skipped day costs nothing beyond the day itself. Someone opening the app after a rough week sees one thing: what's left tonight.

Routine — the AM/PM builder

Routine is the AM/PM builder. New products auto-sort into canonical skincare order, drag to reorder manually, tap the pencil for a full edit sheet (name, brand, type, schedule), and swipe left to remove a product — it moves to History, nothing is deleted.

History — the archive

History is the archive: everything you've removed from an active routine, with a rating and notes, so you remember what worked before repurchasing. One tap adds a product back to Routine; swiping left reveals the one truly permanent action, deleting it for good.

Goal: find out where a new user gets stuck in the core loop, onboarding through building and checking off a routine, and gauge interest in a few future ideas.

Flow: a short moderated session. Open the app, work through a few goal-based tasks without being told where to tap, then sort future-feature ideas by how useful they'd be.

What's next: PostHog is now wired into the app, so the next round of decisions gets real usage data behind it. The first questions I'm watching: do people come back the next day, how often a started routine actually gets finished, and where in the routine builder people stall.

Resolving what testing found: reversible removal isn't the same as deleting

The last two findings pointed at a decision I hadn't actually made: in this app, “remove” means two different things. Taking a product out of a routine is reversible. It moves to History with its rating and notes, and can come back anytime. Deleting it from History is not. The build treated both the same way: red trash icon, scary confirmation sheet. No wonder testers couldn't tell them apart.

So the two actions stopped sharing a look. Removal got an archive-box icon, calmer copy (“moved to History, add it back anytime”), and a swipe-left gesture borrowed from Mail and Reminders. Delete kept the red trash icon and an explicit “this can't be undone.”

The same split fixed the third finding. History items got a one-tap “add back to routine” control, so returning a product is the removal gesture run in reverse instead of re-typing everything from scratch.

“Once settled, the rule went into DESIGN.md, so the next feature that needs a 'remove' doesn't have to relearn it.”

The list mixes my own ideas with requests from testers. I sorted it by one question: does this make the daily loop stronger, or does it just add surface area? That's also why streaks landed in nice to have rather than must have. For the low-energy user this app cares about most, a broken streak punishes exactly the person it's meant to help.

Working with Claude Code taught me as much about process as about the product. Everything below I figured out halfway through and wish I'd had from the start:

That's basically what this project's CLAUDE.md, AGENTS.md, DESIGN.md, and MEMORY.md ended up being: a working style guide and a running decision log.