Choosing a team package is less about picking the cheapest configuration and more about matching capacity to the shape of work ahead. A team that is heavy on developers but light on delivery management will ship code fast and lose track of priorities. A team with a project manager but no quality assurance will move quickly and accumulate debt.
This guide walks through how to think about role mix, headcount, and timing — whether you start from a pre-built package or build your own on the Faraway Team pricing page.
Start with the work, not the headcount
Before choosing roles, write down what the team needs to accomplish in the next ninety days. Not a job description — a list of outcomes. Examples: ship the payments refactor, launch the mobile app beta, reduce support ticket backlog, or build the admin dashboard from scratch.
- Outcome-heavy roadmap with clear deliverables → developers plus a project manager.
- New product with undefined user experience → add a designer early, not after development starts.
- Production system with frequent releases → add a quality assurance engineer before the first major launch.
- Infrastructure or deployment pain → add a DevOps engineer when deploy frequency becomes a bottleneck.
Common package shapes and when they fit
Most clients land in one of three configurations. These map to the pre-built packages on our pricing page, but the logic applies whether you choose a bundle or build custom.
- Startup MVP (2 developers, 1 project manager): validating an idea or shipping a first version with limited budget.
- Growth Squad (3 developers, 1 designer, 1 project manager): scaling an existing product with design and delivery coverage.
- Full Product Squad (4 developers, 1 designer, 1 quality assurance engineer, 1 DevOps engineer, 1 project manager): running a production system at scale with full delivery coverage.
Mistakes we see repeatedly
- Skipping the project manager to save budget, then losing a senior engineer to coordination overhead.
- Hiring designers after development starts, forcing expensive rework on flows and layouts.
- Adding quality assurance only after a bad release, instead of before the next one.
- Treating the team as temporary contractors instead of long-term capacity — context never compounds.
- Under-specifying the first two weeks, then wondering why velocity is low in week one.
“The best team package is the smallest one that covers your biggest bottleneck. You can always scale up next month — that is the point of a subscription model.”
How to ramp without losing momentum
Plan for a two-week onboarding window. Week one: access, environment setup, codebase walkthrough, and meeting the team. Week two: first small tickets, first pull requests, first design reviews. By week three, most teams are shipping at meaningful velocity.
Use the package builder on our pricing page to model different configurations and see the monthly total update live. When you are ready, send your configuration through the get-started form and we will propose a vetted team within one business day.