Your First Steamworks Playtest Branch in One Evening - A 2026 Beginner Pipeline for Friends-and-Family Builds

Discord zips die in three clicks. Steam playtest branches give you one password, one install path, and build IDs you can reference in bug reports. You do not need a publisher or a QA department—you need one evening and a checklist.
This Tutorials & Beginner-First pipeline assumes you already have a Steamworks app ID and a PC build (Unity or Godot). It does not replace the deeper depot and beta branch discipline guide—read that after tonight when you add a second branch.
Why this matters now (May 2026)
- October 2026 Next Fest — You want strangers on a stable demo branch, not your accidental
defaultwork-in-progress. - Truth before traffic — Seven-day store truth audits need a real install testers can compare to store copy.
- Evidence habits — Release-evidence folders should include
marketing-and-demo/playtest/with branch name and build id. - Partner questions — Even pre-publisher, “how do you playtest?” is answered with a branch name + password policy, not “we email builds.”
Direct answer: Create branch playtest-ffa-2026 → upload build → set password → three installs verified → log proof in release-evidence/.
What you will have after one evening
- Named beta branch separate from
default - One live build id on that branch
- Password shared with 3–5 trusted testers
PLAYTEST.mdinstructions (store link + password + what to test)- Screenshot of Steamworks branch page in
release-evidence/ - At least three successful installs logged
Time budget: about 3.5–4.5 hours (first time); 2 hours on repeat.
Prerequisites (honest)
- Steamworks partner access for your app
- SteamPipe set up at least once (you have uploaded any build before, or budget extra hour for first upload)
- Windows PC build folder ready (
.exe+ data) matching your depot layout - Three people with Steam accounts who can test tonight or tomorrow
- You are admin on the Steamworks app
You do not need Steam keys for sale, trailer polish, or Deck Verified yet.
Evening timeline (model)
| Hour | Block | Done when |
|---|---|---|
| 0:00–0:30 | Read depot map + pick branch name | Name written in README |
| 0:30–1:30 | Build VDF / upload via SteamCMD or GUI | Build id exists |
| 1:30–2:00 | Create beta branch + assign build | Branch live in Steamworks |
| 2:00–2:30 | Password + tester doc | PLAYTEST.md sent |
| 2:30–3:30 | Three install verifications | Log rows complete |
| 3:30–4:00 | Evidence folder + operating note | Zip-ready proof |
Mental model — branches vs depots vs builds
Beginners confuse three Steamworks nouns. Use this table all evening:
| Term | What it is | Your job tonight |
|---|---|---|
| Depot | File bucket (Win64, etc.) | Upload correct folder once |
| Build | Immutable uploaded snapshot | Copy build id to evidence |
| Beta branch | Pointer to a build testers see | Create playtest-ffa-2026-05 |
Packages and store visibility are downstream. Tonight you only need testers installing the branch build.
Before you start — Steamworks clicks map
Have these pages open (names paraphrase Valve UI):
- App admin → SteamPipe / Builds
- Depots — confirm Win depot id
- Branches — where you add
playtest-ffa-2026-05 - Installation — general settings if testers cannot see game
If you have never uploaded, budget +60 minutes for first SteamCMD setup following official docs—do not guess depot IDs from a tutorial screenshot.
Step 1 — Name the branch (20 minutes)
Naming convention (beginner-safe)
playtest-ffa-2026-05
playtest— purpose obviousffa— friends-and-family (not public)2026-05— month stamp for rollback clarity
Never use default for experimental builds. Never reuse public beta names from old games.
Record in release-evidence/marketing-and-demo/playtest/branch-registry.md:
| Branch | Purpose | Password owner | Max testers |
|--------|---------|----------------|-------------|
| playtest-ffa-2026-05 | FFA May slice | <you> | 5 |
Cross-check depot discipline so depot IDs in upload match this branch intent.
Step 2 — Prepare the build folder (30–45 minutes)
Unity 6.6 / Godot 4.5 common layout
Your uploaded depot root should look like:
MyGame/
MyGame.exe
MyGame_Data/ (Unity)
OR
MyGame.pck + MyGame.exe (Godot)
Checklist before upload:
- [ ] Version string visible in main menu (build
481or similar) - [ ] No dev console / cheat keys unless documented in
PLAYTEST.md - [ ] Saves go to user folder—not repo-relative paths
- [ ] Matches truth audit claims for demo scope
Content builder note (conceptual)
SteamCMD app_build VDF references depot IDs from Steamworks → Depots. If this is your first upload, follow Valve’s SteamPipe documentation and paste depot IDs from your app’s depot page—do not invent IDs.
Log depot_id, build output folder, and git rev in release-evidence/01-build/playtest-evening/.
Step 3 — Upload and capture build id (45–60 minutes)
- Run upload (SteamCMD or Steamworks web flow your team already uses).
- Wait until build status Available.
- Copy Build ID (numeric) into evidence README.
- Do not set branch live until Step 4—note build id first.
If upload fails (common first-night issues)
| Error class | Beginner fix |
|---|---|
| Depot mismatch | Re-read depot VDF path vs disk folder |
| Missing redistributables | Include VC++ / DirectX per Unity export docs |
| Wrong OS depot | PC build only on win depot |
| File path too long | Shorten project folder name before build |
Attach error log snippet to evidence folder—partners respect honest logs.
Step 4 — Create beta branch in Steamworks (20 minutes)
In Steamworks → your app → SteamPipe → Branches (wording may vary by UI revision):
- Add new branch → name
playtest-ffa-2026-05 - Assign today’s build id to that branch
- Set password (generate 16+ chars; store in password manager)
- Leave
defaultbranch unchanged unless it already matches fest demo (usually it should not)
Screenshot the branch page showing build id + branch name → branch-screenshot.png.
Password policy (beginner)
- Rotate monthly or after leak
- Do not post password on public social—DM or email
- Max five testers for first evening—scale later
Step 5 — Tester instructions (20 minutes)
Create PLAYTEST.md at repo root or docs/:
# Playtest — May 2026 FFA
1. Install Steam client (logged in).
2. Open: steam://install/<APP_ID> (or store page → wishlist → use beta code flow per Steam UI)
3. Enter beta branch password: <sent separately>
4. Select branch **playtest-ffa-2026-05** if prompted.
5. Launch game — confirm main menu shows **Build 481**.
6. Play 15 minutes — note bugs in shared doc <link>.
7. Do NOT stream publicly; build is NDA among friends.
Known issues:
- (list honestly)
Align “Known issues” with vertical slice honesty if store page exists.
Sample app_build VDF skeleton (Windows)
Adapt paths and IDs from your Steamworks depot page—this is structure only:
"appbuild"
{
"appid" "1234560"
"desc" "playtest ffa 2026-05 evening"
"buildoutput" "C:\\steamworks\\output\\"
"contentroot" "C:\\builds\\MyGameWin\\"
"setlive" ""
"preview" "0"
"depots"
{
"1234561" "depot_build_1234561.vdf"
}
}
"DepotBuild"
{
"DepotID" "1234561"
"FileMapping"
{
"LocalPath" "*"
"DepotPath" "."
}
"FileExclusion" "*.pdb"
}
Leave "setlive" empty until you assign build to branch in UI—reduces accidental default promotion mistakes beginners make.
Security and NDA basics (friends still count)
Even FFA playtests deserve:
- Written “do not redistribute build” in
PLAYTEST.md - Password rotation if a tester streams by accident
- No public posting of passwords in Discord channels with open invites
You are practicing publisher diligence hygiene early.
What to ask testers (15-minute session script)
Give testers one focus per session:
- Install path only (tonight) — can they launch?
- First 10 minutes (later) — compare retention rebuild notes patterns
- Store parity (after page live) — does demo match short description?
Tonight is only install path. Do not overload with surveys.
Step 6 — Three install verifications (60 minutes)
Each tester sends:
- Screenshot of Steam Library → Properties → Betas showing branch
- Screenshot of in-game build string
- One-line: “Installed OK” or error text
You log:
| Tester | Steam ID (optional) | Install OK | Build seen | Notes |
|--------|---------------------|------------|------------|-------|
| A | | Y | 481 | |
| B | | Y | 481 | |
| C | | N | — | error: ... |
Gate: do not invite more testers until three Y rows or you fix blocker and re-upload.
Release-evidence folder
release-evidence/marketing-and-demo/playtest/
README.md
branch-registry.md
branch-screenshot.png
build-id.txt
install-log.md
PLAYTEST.md
Link from taxonomy root README.
Operating review hook
Friday Block 4 Marketing:
- “Playtest branch live:
playtest-ffa-2026-05, build 481, 3/3 installs OK.”
After the evening — what not to do
- Do not merge playtest branch into
defaultwithout capsule / fest calendar review - Do not change depot layout same night—upload new build to same branch first
- Do not skip playtest note triage when bugs arrive
Godot vs Unity (same evening, different export)
| Engine | Extra 10-minute check |
|---|---|
| Godot 4.5 | .pck beside exe; smoke launch on clean user account |
| Unity 6.6 | Scripting backend matches depot; don’t upload Mono build to IL2CPP depot |
Both: confirm redistributables and input preflight if testers use Deck.
FAQ
Is a playtest branch the same as Steam Playtest (feature)?
Terminology overload: this article means beta branch + password on your app. Valve’s separate “Playtest” product features may apply to some apps—verify Steamworks UI labels for your app type.
Can we use Steam keys instead?
Keys are for distribution at scale; branches are better for iterating builds with one password rotation.
How many testers before Next Fest?
Start with 3–5 FFA, then 20–50 on playtest-nextfest-2026 branch after truth audit—separate branch names.
Do we need a store page live?
Helpful but not required for FFA branch testing if testers have direct install instructions and app visibility settings allow.
Second evening — iterate without chaos
When build 482 is ready:
- Upload new build → new build id
- Point same branch
playtest-ffa-2026-05to new id - Post in tester channel: “Steam will update — verify build 482”
- Append row to
install-log.md
Do not create playtest-ffa-2026-05-b unless you need parallel experiments—branch sprawl confuses attribution tags.
Fest branch fork (planning, not tonight)
Before October Next Fest, clone naming pattern:
playtest-nextfest-2026-10
Freeze that branch during truth audit week. FFA branch can stay messy; fest branch cannot.
Integration with AI and live-ops features
If generative dialogue ships in playtest:
- Point testers to known AI quirks in
PLAYTEST.md - Align with prompt registry freeze before widening tester count
- Update AI disclosure if touchpoints changed
Block 4 marketing row (copy-paste)
- Playtest: branch playtest-ffa-2026-05, build 481, password rotated 2026-05-16
- Installs: 3/3 OK
- Evidence: release-evidence/marketing-and-demo/playtest/
- Next: playtest note triage Friday
Printable upload gate checklist
- [ ] Branch name registered in
branch-registry.md - [ ] Build id in
build-id.txt - [ ]
defaultbranch untouched or intentionally documented - [ ] Password stored outside chat logs
- [ ]
PLAYTEST.mdsent - [ ] 3/3 install log
- [ ] Screenshot in evidence folder
- [ ] Operating review note scheduled
Common beginner myths
| Myth | Reality |
|---|---|
| “Wishlisters auto get playtest” | They need branch password / beta access |
| “Upload = live for everyone” | Only branch assign makes it live for testers |
| “Same as itch zip” | Steam handles updates and depots—different ops |
| “I’ll fix depots after fest” | Wrong depot on fest week wastes days |
Glossary
| Term | Meaning |
|---|---|
| FFA | Friends-and-family playtest cohort |
| Build ID | Numeric Steam content snapshot |
| Beta branch | Named pointer testers opt into |
| SteamPipe | Valve upload/delivery pipeline |
default |
Public default branch—protect it |
Extended FAQ
Mac/Linux testers tonight?
Only if you uploaded those depots. Otherwise say “Windows only this branch” honestly in PLAYTEST.md.
Can family use Steam Deck?
Yes if build is Deck-capable; run input preflight before inviting Deck-only testers.
Early Access vs playtest branch?
EA uses default or named EA branch with store visibility. Playtest branch is hidden iteration—different social contract.
How does this connect to four Friday operating sheets?
Log playtest branch status in Block 4 weekly—partners see marketing/ops discipline.
Troubleshooting
| Symptom | Likely cause |
|---|---|
| Beta tab missing | App type / no build on branch |
| Download 0 bytes | Depot empty / wrong OS |
| Wrong game version | Tester still on default |
| Password rejected | Typo or branch not saved |
| Game crashes on launch | Missing VC++ / GPU driver |
Hour-by-hour beginner script (read aloud while working)
0:00 — Open Steamworks, write branch name in branch-registry.md.
0:15 — Confirm depot id on paper; open export folder from Unity/Godot.
0:45 — Start upload; do not multitask engine changes during upload.
1:15 — Upload completes; paste build id into build-id.txt.
1:30 — Create branch; assign build; set password.
1:45 — Write PLAYTEST.md; DM password separately.
2:00 — Tester A installs; stay on voice chat until title screen.
2:20 — Testers B and C; log table.
2:45 — Screenshot Steamworks branch page.
3:00 — Commit evidence folder; add operating review reminder.
If any step fails, stop the chain—fix before inviting more people.
Steam client beta opt-in (tester-facing steps)
Because Steam UI shifts, give testers both paths:
Path A — Properties
- Library → right-click game
- Properties → Betas
- Enter password when asked
- Select
playtest-ffa-2026-05from dropdown - Wait for update download
Path B — Store + code
- Wishlist or own app placeholder if required
- Use beta access code if Steamworks generated one for your app type
- Confirm download size > 0 MB
Ask for screenshot of Betas tab—saves you guessing which path they used.
Build string discipline
Main menu must show:
v0.4.2 (481)
Where 481 matches build-id.txt. Testers reporting “no number” means you shipped wrong scene or debug overlay hidden—fix before scaling testers.
When to delete or archive a branch
After fest:
- Document final build id in
branch-registry.md - Disable password or rename branch
archived-playtest-ffa-2026-05 - Never delete historical build ids from evidence—partners may ask what shipped
Liability and comfort (non-legal, practical)
PLAYTEST.md should list:
- Expected crashiness
- No monetization in playtest if true
- How to send saves/logs (folder path)
- Contact email for install failures
Reduces “is this malware?” DMs from friends.
Pairing with Discord vs Steam
Discord is for conversation; Steam branch is for binary truth. Do not replace branch with Discord attachments mid-evening—you lose build id traceability and train testers to ignore updates.
Success criteria (qualitative)
| Outcome | Pass |
|---|---|
| Three installs | Required |
| Same build string | Required |
| One bug filed with build id | Bonus |
| Zero store page required | OK for FFA |
| Evidence folder committed | Required |
Anti-patterns from 2026 beginner forums
- Upload to
default“because faster” - Share password in public tweet
- Skip install verification—“it worked on my machine”
- Rename branch mid-week without telling testers
- No build string in game—reports unusable
Save data and playtest resets
Tell testers whether saves persist between builds. If you break saves nightly, say so in PLAYTEST.md to prevent false “progress lost” bugs. Document save path (%APPDATA%/<Company>/<Game>/) so you can ask for files when investigating.
Crash dumps (optional tenth hour)
If you have time after three installs:
- Enable Windows crash reporting or Godot/Unity log path in
PLAYTEST.md - Ask one tester to reproduce one crash and upload
.log - Store under
release-evidence/01-build/playtest-evening/crash-one/
Not required for first evening—install proof comes first.
Contrarian note
Some indies skip Steam until “launch day.” The 2026 counter-argument is integration risk: first Steam upload during fest week combines depot stress with marketing stress. One evening branch now buys calm in September.
Tomorrow morning (15 minutes)
- Read tester notes into triage bridge
- Update Block 1 engineering with top crash if any
- Schedule second build only if blocking install issues resolved
Store visibility note (beginner)
Some unreleased apps hide install buttons until certain Steamworks flags are set. If testers cannot see the game at all, check Coming Soon vs Playable state in partner docs before blaming the branch password. Log the resolution in install-log.md so you do not relearn the same UI trap before Next Fest.
Wishlist and playtest together
FFA testers can wishlist while on the branch—good practice for capsule iteration later. Ask them not to review publicly on a passworded build unless you are ready for sentiment you cannot patch overnight. Thank testers by name in install-log.md—small teams run on goodwill long before marketing budget exists, and named thanks make the second invite easier.
Related reading
- Steam depots discipline
- Store page ninety-minute QA
- UTM source tagging experiment — tag playtest invite links
- Publisher diligence packets
Close: Your first Steam playtest branch is a habit, not a milestone trophy. Name the branch, upload once, verify three installs, and file the screenshots in release-evidence/ before you ask strangers to trust your October demo. The dogs only playtest what actually launches—and they should all see the same build string on the title screen. Repeat the same branch name for weekly builds until fest branch forks, and never confuse “upload finished” with “testers can install.” If install proof is not in the folder, the evening is genuinely not done yet.