# Writing a progress post

A progress post on Upvera is one honest line about the work, and a little context if it helps. People read many of them in a row, so the best ones say what changed in the first line and stop when there is nothing more to say. This is the voice of building in public: specific, calm and checkable.

## Choose the kind

The person picks the kind when they publish in the app. Write with it in mind:

| Kind | Use it for |
|---|---|
| **Post** | Anything about the day's work. The default. |
| **Update** | Progress or something finished. |
| **Feature** | One feature, with a status: Live, Beta or Soon, and what comes next. |
| **Launch** | Something shipping to people. What it is and why it matters. |

## The shape

1. **First line: what changed.** Concrete and from the user's side. One sentence, ideally under 90 characters.
2. **Then one to three short lines** if they add something: why it matters, how it works, or what comes next.
3. **Numbers only if they are checkable.** A before and after the founder measured is great ("3 seconds, it used to take 40"). Never invent a number, never estimate one, and prefer numbers that come from a connected source.
4. **Link the evidence** when there is one: the release, the commit, the store page.

## The voice

- Write in the founder's voice and in the language they post in. Upvera is used in Turkish and English; don't translate their post into another language unless they ask.
- First person, plain words, sentence case.
- Honest days count. A day spent chasing a bug is worth a post if it says what was learned.
- One good post a day is enough. More posts are not better posts.

## Avoid

- Hype: "excited to announce", "game-changing", "huge day", walls of emoji, exclamation marks.
- Vanity: follower counts, "our metrics are exploding", screenshots of numbers nobody can check.
- Talking about Ranks instead of the work: "my value went up", appeals for wings or Prime. The post is about what was built.
- Commit-speak: `fix(api): handle null in parser` means nothing to a reader. Translate it into what a user notices.
- Anything private: customer names, revenue, internal disagreements, unless the founder explicitly wants them public.
- Promises on someone else's behalf.

## From commits to a post

Group related commits, skip merges, chores and dependency bumps, and ask: what would a user of this product notice?

Commits:

```text
feat(checkout): collapse payment steps into a single view
feat(checkout): apple pay as default method
fix(checkout): keep receipt on the same screen
chore: bump deps
```

Post:

```text
Checkout fits on one screen now.
Apple Pay comes first, card second, and the receipt shows up on the same page. Fewer taps between wanting it and having it.
```

## Examples

Good:

```text
Bank import now takes 3 seconds; it used to take 40.
Parsing moved to a background worker, so the screen stays responsive while it runs.
```

```text
Spent the day on the signup bug that only hits Android 12.
Not fixed yet, but it's down to one library and I can reproduce it every time.
```

```text
Offline mode is in beta.
Notes you write on a plane sync when you land. Next up: conflict handling when two devices edit the same note.
```

In Turkish, for a founder who posts in Turkish:

```text
Ödeme ekranı tek sayfaya indi.
Apple Pay önce, kart sonra; makbuz da aynı ekranda.
```

Not like this:

```text
HUGE DAY!!! 🚀🚀 Shipped tons of improvements and our numbers are exploding. Lend us a wing before it's too late!
```

It has no specific change, unverifiable claims, hype, and it asks for wings as if they were a bet. Every rule above is broken.

## Before you save the draft

- Does the first line say what changed?
- Can every number be checked?
- Is it in the founder's voice and language?
- Is there anything private or anything about money, value or wings? Take it out.
- Save it as a draft. The founder publishes.