5. Team & Build

Find a team & build the thing like an engineer, not a tutorial follower. Every decision should be intentional and documented.

Phase 5: Team and Build (quick-start)

This is the fast, do-it-now version of the team and build step. This is where it stops being planning and becomes real. You assemble a small team and build the system you designed, like an engineer, not a tutorial follower. Use the attached Team and Build doc for the full process, and the separate Community Team-Up SOP for exactly how to find teammates inside the community.

The core idea before you start: you are building a mini startup, not a class project. You will launch it like one and companies will judge it like one, so build it like one.

Step 1: Build a team (do not go solo if you can help it)

A small, reliable team lets you build something bigger, ship faster, and gives everyone a project to launch, which multiplies your reach and grows your network.

• Where to find them: the community first (see the Community Team-Up SOP), then friends and former classmates, then people you meet online.

• What to look for, in order: reliability and follow-through first, then complementary skills, a matching commitment level, genuine interest, and clear communication.

• Size: two to four people is the sweet spot for a one to two month MVP.

• A flaky genius will sink the project. Reliability beats raw talent every time.

Step 2: Set the team up before you write code

Align on the shared goal, who owns what, the timeline and check-in cadence, and your tools (one repo, one board, one comms channel). Agree on expectations, including what happens if someone goes inactive. Everyone is a builder and a launcher, because everyone will post about this.

Step 3: Pass the tutorial test

Here is the hard rule: if you can find a tutorial that walks through building your exact project, it is not good enough, and something went wrong earlier. Real company problems do not come with step-by-step guides, because if they did they would already be solved. If your project is a build-a-chatbot or clone-this-app tutorial, go back and pick a better problem.

You will still use tutorials and docs for individual pieces, like a library or a technique. That is fine. The test is about the project as a whole. No tutorial should exist for the thing you are actually building.

Step 4: Make every decision intentional and documented

As you build, you will hit choices the design did not fully answer: a library, a data model, an API shape, an edge case, a speed-versus-quality tradeoff. For each meaningful one, decide deliberately and write it down: Decision, Options, Choice, Why, Tradeoffs. "I used it because a tutorial did" is a junior answer. "I chose it over that because of these constraints" is a top one percent answer. The build is where you generate those answers, so keep a running decision log.

Step 5: Treat it like a startup

• Build for a real user, not for a grade.

• Ship an MVP, not a perfect product. Scope hard.

• Document as you go: progress, decisions, and demos.

• Care about what startups care about: does it work, does it solve the problem, would someone actually use it.

• Use real engineering practices: version control, a readable repo, a clear README, tests where they matter, and a real deployment. Companies will read your code.

Step 6: Ship in one to two months, working as a team

The timeline is a constraint, not a suggestion. Cut scope to the core of your design, build the smallest thing that proves the value, ship it, then improve.

• Break the design into tasks on a shared board and assign owners.

• One GitHub repo, branches and pull requests, and review each other's code.

• Short check-ins a few times a week, all comms in one channel.

• Integrate early and often, and keep the design doc and decision log as your source of truth.

Step 7: Build the evidence as you go

While you build, capture the raw material for your launch: screenshots, demo clips, the problem and research story, the decisions you made, and any early results. Set up the repo cleanly with a README that explains the problem, your approach, and how to run it.

What you should have when you are done

• A team with clear roles and a timeline, or a deliberate solo decision.

• A working MVP that solves the problem from your brief.

• A clean, public repo with a README.

• An updated design doc and a decision log of your intentional choices.

• The raw material for your launch, and everyone ready to post about it.

Do not move on until it works and you can explain how you built it, decision by decision.

Avoid these

• Building a project that has a tutorial. This is the fatal one.

• Going solo when you could build with a team.

• Picking teammates on skill alone, ignoring reliability.

• No alignment upfront on roles, timeline, and expectations.

• Following tutorials for the whole build instead of making intentional decisions.

• Not documenting decisions, so you lose your interview ammunition.

• Gold-plating and never shipping, or building it like a messy hobby project.

• Letting MVP scope balloon past one month MAX

Go deeper: the docs

This is the quick-start. The attached Team and Build doc covers the full build workflow, the tutorial test, documenting decisions, and shipping like a startup. The separate Community Team-Up SOP gives you the exact process, templates, and checklists for finding and forming your team inside the community. Use them whenever you want the depth.