Frame the question
Tell us about the project, target platforms or hardware, and the constraint you are trying to solve. We discuss the context, access requirements and what a useful first investigation would establish.
Working with Traverse
Start with a 16-week commitment.
Ramp-up is part of the engagement. We get established in your codebase and deliver across four four-week sprints, with build reviews every two weeks. Longer projects continue against a roadmap we agree together.
The initial commitment
16 weeks
Four sprints. Ramp-up included.
- Sprint 1Weeks 1–4Ramp-up + delivery
- Sprint 2Weeks 5–8Build + review
- Sprint 3Weeks 9–12Build + review
- Sprint 4Weeks 13–16Build + review
Within every sprintWeek 2: build + reviewWeek 4: build + review
Access, build setup and codebase onboarding start in Sprint 1. We agree ramp-up goals and the first delivery priorities with your leads.
From hello to handover
Always know the next step.
You don’t need a finished statement of work to start. Bring the question, the target and the constraints. We work through the next decisions together.
Start with a short outlinePlan the first 16 weeks
We agree the initial 16-week commitment, scope, acceptance criteria and responsibilities. The plan includes ramp-up, early investigations and the first delivery goals. Where uncertainty is high, a prototype tests the difficult assumptions.
Ramp up in your pipeline
We establish access, build the project, learn the relevant systems and agree ownership with your technical leads. Ramp-up is part of the initial commitment, with progress and dependencies visible from the first sprint.
Build and review together
The initial engagement contains four four-week sprints, with build reviews every two weeks. Work stays in your Perforce or GitHub source control, tracked in your Jira and discussed in your Slack. We align the next goal with your priorities and plan any continuation together.
Continue or hand over clearly
Longer projects continue against an agreed roadmap. Release responsibilities, integration, documentation and support are defined with your team, so ownership is clear at a milestone, handover or renewal.
Your teamPriorities + project context
Direct conversation
Traverse engineersImplementation + technical review
One delivery process
A shared buildSource control / build / review / next goal
An extension of your team
You spend less time passing messages and more time making progress.
Your technical leads speak directly to the people writing the code. Your producers see the roadmap. Your team reviews the result in the pipeline it already uses.
Meet the people behind the workThe practical details.
A clear scope. A build every two weeks. One shared delivery process.
An initial 16 weeks, including ramp-up.
Get established in the project, then deliver through four four-week sprints. Build reviews happen every two weeks. Further work, release and support are planned together.
- Sprint 1Weeks 1–4Ramp-up + delivery
- Sprint 2Weeks 5–8Build + review
- Sprint 3Weeks 9–12Build + review
- Sprint 4Weeks 13–16Build + review
01
Before delivery
Agree the scope.
Your problem, target platforms and a representative build.
- Identify the difficult assumptions
- Agree acceptance criteria and responsibilities
- Plan ramp-up and the first delivery goals
Together, we agreeA plan you can inspect
02
Repeated for each sprint
Inside a four-week sprint.
Traverse engineers implement. Your team reviews. We agree the next priority together.
Ramp-up starts in Sprint 1
Access, a working build, codebase onboarding and the first agreed tasks. Progress is visible from the start.
Weeks 1–2
Build and review
Implement the agreed goal in your codebase.
Runnable build + review
Weeks 3–4
Refine and review
Use the mid-sprint review to refine the work.
Runnable build + review
Review findings shape the next sprint.
After the initial 16 weeks, continue against the agreed roadmap or hand over the completed scope.
03
When the scope is complete
Hand over clearly.
Review the result against the criteria we agreed at the start.
- Integration and documentation
- Agreed release responsibilities
- Support terms and next steps
Your team knowsWhat it owns. What’s next.
Inside your pipeline, throughout.
Direct access to the engineers. A visible roadmap. Your review gates.
- Source control
Perforce - Source control
GitHub - Tracking
Jira - Conversation
Slack
Scope and prototype
We start with the problem, the target and a representative build. A scoped prototype tests the risky assumptions before the work becomes a production commitment. The output is something the client can inspect and a roadmap based on what the investigation found.
The first 16 weeks include ramp-up
The initial engagement is a 16-week commitment, organised into four four-week sprints. Ramp-up starts in the first sprint: access, build setup, understanding the relevant systems and taking ownership of the agreed work. Its goals and dependencies are planned with your team.
Build reviews happen every two weeks. Early reviews cover the working baseline, findings and first changes; subsequent reviews track delivery against the roadmap. Sixteen weeks is the initial commitment, while the full project may continue for as long as the agreed work requires.
Your pipeline
We adopt your source control, build infrastructure, review gates and milestones. In practice that usually means Perforce or GitHub for source, Jira for tracking and Slack for the day-to-day conversation, and for Unreal projects it means working in your engine branch rather than a fork of our own. We use the tools your team already uses; we do not ask you to adopt ours.
There is no account layer between your technical team and the people implementing the work. Questions reach the engineers who can answer them.
Ship and support
Shipping responsibilities, acceptance criteria and support are agreed as part of the scope. A release is not the moment to discover that two teams understood the handover differently.
Transparency, iteration, alignment
Transparency means live roadmap access and direct discussion of the implementation. Iteration means reviewing the work through runnable builds. Alignment means working inside the client’s delivery process and making technical trade-offs against the project’s own priorities.
Licensing and confidentiality
Traverse is licensed on every major console platform. Platform details, access and NDA handling are agreed with the client before the work begins. Public case studies use only approved project information.
Before we begin.
What should we bring to the first conversation?
A short project outline, target platforms or hardware, the main technical question and any timing constraints. A representative build or capture can help later; we agree access and confidentiality before sharing sensitive material.
Can we start with a focused investigation?
Yes. A focused investigation can be the first workstream within the initial 16-week engagement. We agree the question, ramp-up needs, deliverables and review criteria together.
How many sprints will our project need?
We start with a 16-week commitment, covering four four-week sprints and including ramp-up. Your scope determines the overall project duration. Further work is planned together, with build reviews every two weeks throughout delivery.
Is ramp-up included in the 16 weeks?
Yes. Access, build setup, codebase onboarding and the initial investigations are part of the commitment. We agree the ramp-up goals and dependencies up front rather than assuming every project needs the same onboarding time.
Who handles release and ongoing support?
Responsibilities, acceptance criteria and any support period are agreed as part of the scope. We discuss those boundaries before delivery so the handover is clear to both teams.