Milestones

Pikku Studio Cloud doesn't build your whole app in one go. It builds it in milestones — one shippable increment at a time, each small enough to see working and judge before the next one starts.

A milestone is not a task or a ticket. It's a piece of your product that stands up on its own: one thing the app is about, the people who use it, and an action one of them takes.

Annotated screenshot of the Milestones panel in the builder: a list of milestones with coloured status dots — one green "Built", one amber "Dispatched" with a pulse, one blue "Proposed" — each showing a title, a one-line description, and the entities it touches. One is expanded to reveal its user journey written as Given/When/Then steps. Callout: "Every milestone carries the journey it has to satisfy."

What makes a milestone

The first milestone of any app is the smallest thing that proves the shape is right: one thing the app is about, the people who are actually in it, and one action they take — recorded when it happens.

That sounds modest, and it's deliberate. An app that can do one recorded thing has a database, sign-in, and rows that belong to someone. Everything after that is addition rather than foundation.

One kind of person is a complete first milestone. Plenty of apps have exactly one — it's yours, you're the only one in it — and that's a finished product, not a half-built one. Pikku Studio Cloud never invents a second person to make a milestone look richer; someone else appears in your app when you say they exist, and not before.

Each milestone carries:

• What it's about — the entities it touches. Three at most, and one is normal. If it needs four, that's two milestones.
• Who's involved — the kinds of people in your product, however many that turns out to be. They're not decoration: each one becomes a real user who signs in, so a journey runs as a named person. If a second kind ever appears, a journey can then say what the owner may do that they may not.
• The journey it has to satisfy — written as plain Given/When/Then steps about a named person. Given the owner has no entry for today, when they record their day, then it's saved as one entry.

That last part matters more than it looks. The journey isn't a description of the milestone — it's turned into a real automated test, and passing that test is what "built" means. See User flows (scenarios).

The life of a milestone

Every milestone moves through three states, and the console shows you which one it's in:

• Proposed — written down, not yet started. Only one milestone is ever proposed at a time; the next is written when the conversation settles it, not banked up in advance.
• Dispatched — handed to the builder and being built right now.
• Built — finished, with its journey passing.

Dispatch happens in the background, so the conversation never stops to wait. You keep talking about version four while version one is landing on screen.

You don't press a Build button

There isn't one. When the conversation has settled enough for a milestone to be real, it gets written down and dispatched — you'll get one plain sentence saying so, not a progress report.

The one thing you are asked first is whether you want to see the screen before it's built. Say yes and you get two or three actual looks sketched in the Design tab to pick from; whichever you choose is recorded on the milestone and is the one that gets built. Say "just build it" and it skips straight to building.

Sketching takes a minute or two, so the Design tab will say it's still working before the options land. That's expected, not broken.

What the builder receives

The milestone note is the brief. There's no second summary in between that could disagree with it — the builder gets the note's entities, its people, and its journey, exactly as written.

Which means a milestone is only ever built as well as its note is written, and the system is strict about that on purpose. A dispatch is refused outright if the journey is missing, if it's written in the first person, if it names a kind of person who was never declared, or if the milestone tries to cover more than three things. A refusal comes back as one sentence saying what to fix — these are all things the builder couldn't have recovered from on its own, caught before any code is written rather than after.

Where to go next

• Knowledge — where milestone notes live, and what else is written down.
• User flows (scenarios) — the journeys a milestone has to pass to count as built.
• The Weave — watch a milestone's pieces land as it builds.
• Publishing — taking built milestones live.