Back

Presto

AI content creation hub

This case study covers how I designed and built Presto, from the first PRD to a live product that publishes to LinkedIn. I did all of it myself: the research, the product spec, the design system and every screen in Figma, then the front end, back end and deployment.

Highlight

You set up your voice once. Presto writes a month of posts that sound like you, puts them on a calendar, and publishes them when they're due.

Visit Presto

Problem

Context

I'm a product designer, and I want to post on LinkedIn regularly: 3 to 5 posts a week about design craft, design systems and the work itself. But writing one post was never the hard part; doing it every week, month after month, was.

  • Generating. Posts were written by hand, so I only did it when I had spare time, which wasn't often.
  • My voice got lost. Plain AI tools wrote like AI tools, because they knew nothing about how I write.
  • Nothing was organised. I had no single place to see what was drafted, what was scheduled and what had gone out.

So the job was to make consistent posting a system that runs on its own, not something I have to find the willpower for.

Who is this for?

The first user

The first user was me, and I designed for that on purpose. I knew the problem well, I'd be using it every week, and I could tell when a generated post sounded wrong.

Writing the PRD made the target user clear:

  • Busy with client or product work, so posting always comes second.
  • Has opinions and stories worth sharing, but no time to write them.
  • Wants the posts to sound like them, not like a template.
  • Wants control over everything that gets published, but doesn't want to babysit it.

The idea

Presto runs as a pipeline with four steps.

Your tone, rules, topics, a few posts you've already written, and any reference material.

1. Teach it once

Say how many posts you want, or pick the dates, and they come in one by one.

2. Generate in batches

Every post lands on a date. Edit it, move it, regenerate it or turn it back into a draft.

3. Organise on a calendar

When a post is due, it goes out to your connected account without you doing anything.

4. Publish automatically

Two principles:

  • The system does the work. It shouldn't just assist you.
  • You can step in at any point. Every post is editable, and nothing publishes unless you've scheduled it.

Projects

A project is a folder. Each one has its own voice, references, calendar and connected accounts, so a personal brand and a product account can run side by side without leaking into each other.

Creating the first project, from the empty state
A new project starts with a short tour of each section

Instructions

This is the most important screen in the app, because it decides whether the posts sound like you. It has three cards.

  • My voice: tone, content rules, post structure, things to avoid, and the topics you write about. If you'd rather write it all in one place, you can switch to a single prompt.
  • My writing style: paste in posts you've already written, link to them, or upload a file. This is where Presto learns how you write.
  • References: material you want the posts to draw on.
Every field saves on its own as you go

Nothing on this screen has a save button. A burst of quick edits is queued so they save in order, which means a slow network response can never write old content over new.

With an empty voice setup, Presto sounds like every other AI tool. With three of your real posts in it, it gets close enough that editing takes two minutes instead of twenty. That's why the writing style card is there.

Generate

There are two ways to generate:

  • By number. Pick a count from 1 to 31 and Presto spreads the posts out for you.
Generating by number, with the model and the account picked on the same page
  • By calendar. Choose a range of days, pick specific dates, or choose whole months and then skip the days you don't want.
Generating by calendar, by range or by picking days

This page took the most iterations. Skipping dates across several months means showing several calendars at once, so they sit in a carousel that scrolls sideways. You can drag it, it stretches a little at the edges, it stays in calendar order, and calendars slide in and out as you select and deselect months.

Skipping dates across several months

You also pick the AI model and the account on this page. You can use the built-in model, or bring your own key from Anthropic, Google, OpenAI or Groq. Your own key is encrypted at rest and never sent to the browser.

The posts come in one at a time as they're written. Each card can be edited inline, regenerated (with a different topic if you like), re-dated or deleted.

Posts arrive one at a time as they're written

Content

The content calendar has three tabs. Which tab a post sits in depends on what actually happened to it:

  • Queued: scheduled and waiting to go out.
  • Published: sent, with a link to the live post.
  • Draft: no date yet.

You can view your posts as a Kanban board, one column per day, or as a calendar of day chips. Tap a chip and that day's posts fan out of it like a deck of cards being dealt. Close it and they fly back into the chip.

The same posts as a Kanban board and as a calendar
A day's posts dealt out of its chip

From the deck you can open a post's own page, move it to drafts, change its date or regenerate it. If an edit moves a post off that day, the card flies home first and then the remaining cards close the gap.

A post on its own page

Dashboard

The dashboard answers one question: am I on track this month?
  • Total posts, split into draft, queued and published
  • A month grid showing which days are covered
  • What's going out next and what went out recently
  • What you've been posting about, by topic and by platform
  • A setup checklist for new projects

Every figure comes from the posts themselves. I didn't include likes or reach, because Presto doesn't track them, and I didn't want the dashboard to imply it did.

Connections

Connect your LinkedIn account once per project. Presto shows every state a connection can be in: connected, expiring soon, expired and revoked. Each one tells you what to do next.

X is built but turned off. More on that below.

The small things

Most of the time on this project went into details nobody would notice unless they were missing.

  • Feedback on every click. Anything that takes time shows a pending state straight away. Deletes disappear from the screen immediately, and come back with a toast only if the server call fails.
  • Squircles everywhere. Purely a design decision: every rounded corner uses Figma's corner smoothing instead of a plain CSS radius. The one exception is fully round pill shapes, which have no straight edge for the smoothing to blend into.
  • Offline handling. If your connection drops, you get a toast saying you're offline, and it clears on its own when you're back. Before this, a dropped connection told you that you'd entered the wrong password.
  • Motion with a reason. Toasts pop in with a slight overshoot, tooltips grow out of whatever you hovered, and the day deck deals its cards from the middle out. Each value was tuned live and then locked in, and each one was checked against Emil Kowalski's animation principles.
  • The chrome locks during generation. While posts are being written, the sidebar and navbar fade and stop responding, so you can't accidentally cancel a run by navigating away.
The offline toast clears itself once a request gets through

Building it

I designed in Figma and built with AI coding agents (mostly Claude Code). Three things made that work at this size.

All colours, spacing, radii and type are exported from Figma as tokens. The code can only use those tokens: no hex codes, no px values. If a value isn't in the token files, the agent has to ask me before using one.

A strict design system

The Figma API's rate limits on the free plan made it unusable for this, so I built my own plugin. It exports a frame's structure, token bindings, a screenshot and its assets to a local folder the agent can read.

Figma Bridge

The project keeps three logs, and every agent session reads them and adds to them.

Writing things down

The tokens kept a handful of Figma frames and 49,000 lines of code looking like one product.

The three logs:

  • INTERFACE.md: every design decision that's been settled.
  • LEARNINGS.md: each bug, written as symptom, cause and the rule that prevents it.
  • EXECUTIONS.md: what was done, step by step.

That's how a solo project stays consistent over three months and dozens of agent sessions. Later in the project I ran several features in parallel, each on its own branch and worktree.

By the numbers

3 months, 162 commits, 37 test suites, and four AI providers supported.

What broke

The parts I learned the most from.
  • The app said 76 posts were published. None were. "Published" meant the scheduled date had passed, which says nothing about the post. Now a post only counts as published once LinkedIn confirms it.
  • A fake API key looked valid. An AI gateway quietly answered with free models on its own account, so a made-up key passed. I removed it and call each provider directly: a key is valid if it can list the provider's models.
  • 800 lines of scroll code lost to two lines of CSS. Every fix to my landing-page scroll engine broke another case. The browser's native scroll snapping fixed all of it.
  • X charges per app, not per user. The first real post came back 402 credits depleted. Rather than pay, X is switched off and says "coming soon" instead of failing quietly.
  • Publishing for real meant designing for no undo. LinkedIn can't take a post back, so published posts are read-only and failed or overdue posts get a visible marker.

What's next

Presto is a work in progress. These are the features I'm building now.

  • Post headings. A post gets a clear point before it has a body.
  • Media. Attach an image or a video to a post.
  • Generate from a heading. You write the line, and Presto writes the post around it.
  • Generate from a draft. You write a rough version, and Presto shapes it into a finished post in your voice.

The last two change who starts the post. Right now Presto writes from your instructions and topics. With these, you bring the idea or the first draft and Presto does the rest, so the post starts with your own thinking instead of the model's.

View on Github

Lessons

  • Write the spec first. The PRD cut out a lot of back and forth. The agent never had to guess what a screen should do.
  • Constraints make AI-built software better. Locked tokens, a fixed stack, and "ask before adding a package" kept the agent from drifting.
  • Keep the log while you work. Turning bugs into rules in LEARNINGS.md meant the same mistake rarely happened twice.
  • Label states by what happened, not by what the clock says. The fake "published" count taught me that.
  • Use what the browser already does. Native scroll snapping and the Web Animations API beat my own versions every time.
  • Being the first user is a cheat code. I knew straight away when a post sounded wrong, because it was supposed to sound like me. That's also where the next features came from: I kept wanting to start a post from my own words.

Thanks for reading!