A Transparent Look at How We Start Working With Software Teams
Most agency onboarding experiences sound polished from the outside. A kickoff call happens, access is exchanged, and work begins somewhere behind the scenes. What is often missing is visibility into how the relationship actually takes shape during those early days.
At Pepperplane, the first two weeks are less about “starting design” and more about building alignment. The goal is to understand how the team operates, reduce friction early, and create enough shared context for delivery to move smoothly afterward.
This is what the first 14 days typically look like when a new software team starts working with us.
Why the First Two Weeks Matter More Than Most Teams Realize
The beginning of a project tends to set the tone for everything that follows.
When onboarding is rushed, teams often move into delivery before roles, workflows, and expectations are fully aligned. Questions surface later that could have been clarified earlier. Design decisions become disconnected from implementation. Communication patterns form reactively instead of intentionally.
The issue is rarely effort. Most teams are moving quickly because they are trying to maintain momentum.
What often gets underestimated is how much long-term stability comes from slowing down just enough at the beginning to create shared understanding.
That said, onboarding is not identical across every engagement.
A two-week onboarding rhythm is most common for larger engagements that may run for six months or longer, where the delivery environment is more complex and there are multiple moving parts to integrate into. For shorter or more focused projects, this process may happen much faster. In some cases, the same alignment can happen within a week.
The structure scales with the size and complexity of the engagement, but the principle remains the same. Strong delivery starts with shared context.
Day 1–2: Async Preparation Before the Kickoff
Before the kickoff meeting happens, the team begins with asynchronous preparation.
This usually includes reviewing existing materials such as product documentation, current workflows, sprint structures, user flows, roadmaps, and any active design or development environments. Access is exchanged early so the conversation can begin with context rather than discovery from scratch.
This phase is intentionally lightweight, but it is important.
By the time the kickoff happens, the goal is for the team to already have a working understanding of the product landscape, the delivery environment, and the areas where alignment may already be needed.
This changes the quality of the conversation significantly.
Day 3: The Kickoff Session
The kickoff itself is usually around 60 minutes, but the goal is not to “cover everything.”
The session is designed to align around how the team works, how decisions are made, and where UX will integrate into the delivery process. Some conversations focus on immediate priorities, while others focus on operational rhythm, communication flow, sprint timing, stakeholder involvement, and development coordination.
This is also where patterns begin to emerge.
Every software team has its own cadence. Some teams are highly synchronous and collaborative. Others rely heavily on asynchronous workflows. Some projects move in tightly structured sprint cycles, while others evolve more fluidly.
Understanding that rhythm early matters because embedded UX works best when it adapts to the system already in motion rather than forcing a completely new one.
Day 4–6: Access, Systems, and Workflow Alignment
Once the initial kickoff is complete, the focus shifts toward operational integration.
This is usually where access to tools and systems is finalized. Figma workspaces are connected. ClickUp structures are reviewed. Slack channels are organized. Existing sprint workflows and ticket structures are mapped out so UX can integrate directly into the current delivery environment.
This stage may not look particularly exciting from the outside, but it is one of the most important parts of the onboarding process.
A large amount of delivery friction comes from disconnected systems, unclear ownership, or missing context between tools. The earlier those gaps are addressed, the easier it becomes for the team to move together later.
This is also where the team begins identifying how information naturally flows across the organization. In many cases, this reveals opportunities to simplify communication and reduce unnecessary back-and-forth before work fully ramps up.
Day 7–10: The First Deliverable Moves Into the System
By the second week, the focus shifts toward producing the first active piece of work.
Depending on the engagement, this may be an early UX audit, a refined user flow, interaction updates tied to the current sprint, design explorations, or structural recommendations connected to a product area already in development.
What matters most at this stage is not the size of the deliverable. It is how the work moves through the system.
This is usually the first moment where the team sees how UX integrates into tickets, communicates decisions, collaborates with development, and supports implementation without creating additional process overhead.
The first deliverable often becomes less about the output itself and more about establishing trust in the workflow.
Day 11–14: Learning the Team Behind the Product
By the end of the second week, something important usually becomes visible.
The team is no longer just learning the product. The team is learning each other.
Patterns around communication, approvals, development timing, feedback cycles, and stakeholder involvement become clearer. Some assumptions made during kickoff turn out to be accurate. Others evolve as the real working rhythm becomes more visible.
This is also where embedded UX begins to feel less external.
Instead of operating as a separate design function, the work becomes increasingly connected to how the product team already moves. Conversations become faster. Clarification becomes easier. The gap between design and implementation starts to narrow naturally.
That shift is often subtle, but it changes the experience of delivery significantly over time.
What Radical Transparency Actually Looks Like
One of the reasons onboarding can feel difficult in agency relationships is that many teams hide the operational reality behind polished process language.
The result is often uncertainty. Clients do not fully know what to expect, how communication will work, or how quickly the relationship will become functional.
Transparency removes a large amount of that uncertainty.
Rather than promising a perfect process, the goal is to make the process visible. That includes how decisions are made, how workflows integrate, where communication happens, and how delivery actually moves from day to day.
In practice, this tends to build trust faster than polished promises ever could.
Final Thought
The first 14 days of a partnership are rarely about speed alone. They are about building enough clarity, rhythm, and alignment for the work to scale sustainably afterward.
When onboarding is treated as part of delivery rather than an administrative step before delivery, teams move forward with fewer disconnects and a stronger shared understanding of how the work will happen.
That foundation becomes increasingly valuable as products grow more complex and delivery cycles move faster.
If you want to see how this approach works in practice, you can explore some of our recent work here: https://pepperplane.com/work/
And if you are exploring how embedded UX could fit into your own workflow, you can book a discovery call and we can take a closer look together.
