Core concepts

Pikku Studio Cloud is built around a handful of words you'll see everywhere. None of them are technical; each is just a name for something simple. Learn these and the whole product clicks into place.

They split neatly into two halves. How your app gets made — chat, knowledge, milestone, sandbox. And where it runs — stage, deployment. Project is the container around both.

Labeled map diagram: on the left a "Build" column showing Chat feeding a Knowledge base, the knowledge base producing Milestones, and the milestones building inside a dashed-border Sandbox. On the right a "Run" column showing Staging and Production stage boxes. One arrow between them labeled "Publish". Caption: "You build on the left. You publish to the right."

Project

A project is your whole app — everything that makes it work, in one place. Its code, its written record, its sandboxes, its stages, its settings and data.

Everything else on this page is either how a project gets built, or where a copy of it is running.

How your app gets made

Chat

Chat is the conversation you build in. Not a step you pass through — it's where you stay. It makes the decisions and shows you them being made, one question at a time, and your job is to correct it rather than to specify everything up front.

There's no plan document to approve at the end and no Build button to press. Decisions get settled as they come up, and building starts on its own once enough is settled. See Chat.

Knowledge

Every decision Chat makes is written down immediately as a note in your project's knowledge base — what your app is, what it's made of, and why each call was made.

This is the part that makes Pikku Studio Cloud different from a chat window that happens to write code. The notes aren't a summary of the conversation; they're the actual specification the builder works from. You can read them at any time, in plain language, months later. See Knowledge.

Milestone

A milestone is one shippable piece of your app — small enough to see working and judge before the next one starts. Not a task or a ticket: a piece of your product that stands up on its own.

Your app is built one milestone at a time, in the background, while the conversation carries on. Each milestone carries the user journey it has to satisfy, and that journey becomes a real automated test — passing it is what "built" means. See Milestones.

Sandbox

A sandbox is a private copy of your whole app — yours to play in. All of the above happens inside one. You can experiment, try a wild idea, or break something completely, and nothing you do touches your live app.

This is the safe place to be brave. See Sandboxes.

Your live app on one side and a dashed-border duplicate labeled "Sandbox — your private copy of the whole app" on the other, with no arrow between them. Note: "There is no route from here to production. Publishing is the only way across."

Where your app runs

Stage

A stage is a deployed copy of your app, and each one is a branch of your repository. That's the whole model — you add a stage by pointing it at a branch.

Which kind of stage it is follows from which branch it is:

• Production — your production branch. The real thing, live to your actual customers. A project has at most one.
• Environment — a named, long-lived stage like staging. As many as you want. This is where you check a build before customers see it.
• Preview — any other branch, deployed on its own address. Temporary, for looking at one piece of work.

Each stage has its own address, its own database, and its own secrets and settings, so nothing leaks between them. Changes flow one way: check in staging, then promote to production. See Stages & environments.

Deployment

A deployment is one tracked shipment going live — a single, recorded "this exact version, shipped at this moment." Because each one is tracked, you can always see what changed, when, and roll back to an earlier deployment in one click. See Deployments.

Publishing is the bridge

Nothing crosses from build to run by itself. Publishing is the one deliberate step that does it: it checks your work, commits it, and ships it to a stage you choose. By default, shipping to production stops and asks for your approval even after every check has passed — and you can switch that off per stage once you trust the checks.

How they fit together

1. You talk, in Chat, inside your project.
2. Decisions land in the knowledge base as they're made.
3. Enough decisions settle a milestone, which gets built in your sandbox.
4. You publish it to a stage — staging first, then production.
5. That go-live is recorded as a deployment you can roll back.

Concept	What it is	Live to real users?
Project	Your whole app and everything in it	— (it's the thing itself)
Chat	The conversation you build in	No
Knowledge	The written record the builder builds from	No
Milestone	One shippable piece of your app	Not until published
Sandbox	A private copy to build and experiment in	No
Stage	A deployed copy, one per branch	Only the production stage
Deployment	One tracked shipment going live	Yes, when it ships to production

Only one of these is ever live to your customers: the production stage. Everything else is a safe space to build and check first.

Where to go next

• Chat — the conversation everything starts in.
• Knowledge — the record of what your app is and why.
• Milestones — how a conversation becomes working software.
• Publishing — the step that takes it live.