Skip to content
Delivery5 min read

Onboarding a software development partner: the first 30 days

A first-month plan for onboarding a new development partner: access and accounts, environments, documentation, the first sprint, the meeting rhythm and early warning signs.

By COO, Coretus Technologies

Short answer

Plan the first 30 days with a new development partner on purpose. In week one, grant access and share honest documentation. In week two, get environments working and run a small, real first sprint. By week four, the meeting rhythm should be steady and you should have seen working software. Watch early for silence, missing questions and access delays.

The first 30 days with a new development partner set the pattern for the rest of the engagement. Sort out access, accounts and documentation in week one, run a small but real first sprint in week two, and by the end of the month have a steady meeting rhythm and working software you have seen in a demo. Most first-month delays come from small things: an account nobody created, an environment the team can't deploy to, or a product question that waits days for an answer.

Before day one: what to have ready

A partner can't start well if the first week goes on waiting. Have these ready before kickoff:

  • A signed agreement covering IP ownership, confidentiality and how your data will be handled. Our post on protecting IP when outsourcing covers what it should say.
  • A named product owner on your side who can answer questions within a working day.
  • A rough, prioritised list of the first few weeks of work.
  • A list of every system the team will need, and the person who can grant access to each one.
  • Introductions to the people the team should meet, such as your technical lead, your security contact and a few key users.

With Coretus, an NDA can be signed before you share anything sensitive, and your ownership of the code, designs and IP is written into the service agreement. A scoped project can kick off in 1–2 weeks once the deliverables and milestones are agreed.

Week 1: access, accounts and documentation

Access checklist

  • Source code repositories, with branch protection and review rules already set up.
  • The issue tracker and the board the team will work from.
  • Shared chat channels, and calendar invitations for the regular meetings.
  • A non-production cloud environment, with only the access each role needs.
  • The CI/CD pipeline, monitoring, error tracking and logs.
  • Design files, analytics and sandboxes for third-party services such as payments or messaging.
  • VPN or device setup, if your security policy requires it.

Give everyone a named account, and never share logins. Keep a simple access register showing who has access to what, when it was granted and by whom. It makes security reviews easier, and removing access is quick if someone leaves the project.

Documentation to share

You don't need perfect documentation. You need honest documentation. Share what exists, and say which parts are out of date:

  • An architecture overview, even if it is a photo of a whiteboard.
  • How to run the system locally and how it is deployed.
  • Known problem areas, technical debt and anything fragile.
  • The main users and workflows, and the business rules that matter most.
  • Past technical decisions and the reasons for them, if they were ever written down.

Ask the partner to write up what they learn and to fill gaps in the documents as they find them. A good partner will send you a short summary of the system within the first couple of weeks. It also shows you how much they have understood.

Week 2: environments and the first sprint

By the second week, the team should be able to build, test and deploy to a non-production environment without help. If they can't, fix that before anything else.

Keep the first sprint small and real. Pick a few low-risk items that touch the main parts of the system, such as a bug fix, a small feature and a new automated test. The goal is to prove the whole path works, from ticket to code review to deployment to demo, not to deliver a lot. A first sprint built around a large feature hides onboarding problems behind deadline pressure.

For how sprints, backlogs and ceremonies run once the team has settled, read running agile with an external development team.

Weeks 3 and 4: a steady communication rhythm

Agree a rhythm early and keep to it, even in weeks with little to discuss. A typical one:

  • A daily stand-up in shared working hours, focused on blockers and decisions.
  • Sprint planning and a demo at the start and end of each sprint.
  • A weekly status update on the same day each week. Our post on status reports clients actually read includes a one-page template.
  • A retrospective each sprint that covers how the two teams are working together, not just the code.
  • A monthly check-in between senior people on both sides about the relationship rather than the backlog.

Our managed engineering squads keep at least four hours of overlap with the client's working day for these conversations, and they work inside the client's Slack, Jira and GitHub.

What a good partner does in the same month

Onboarding isn't only your job. In the same 30 days, expect the partner to:

  • Confirm the goals, how success will be measured and how progress will be reported.
  • Agree a definition of done with you that includes tests, code review and documentation.
  • Map the system and write down the first technical risks they find.
  • Ask for decisions early, each with the date it is needed by.
  • Name one person on their side who is accountable for delivery.

Early warning signs in the first month

Problems that later sink a partnership usually show up in the first few weeks. Watch for these:

  • No questions. A new team that asks nothing in its first week either hasn't started properly or is guessing.
  • Silence between meetings. You only hear from the team at the stand-up.
  • No working software by the end of the first sprint. Plans and diagrams don't count.
  • Everything green. Every project has early risks. A partner who reports none either isn't looking or isn't saying.
  • Different people. The engineers you met at kickoff aren't the ones doing the work.
  • Access still being requested in week three. This one is often on the client's side, and it is worth fixing fast.

Raise these at the first retrospective rather than at the end of the month. A good partner will want to hear them early, while they are still cheap to fix.

Where to start

Make the access list now, before the contract is signed, and name the person who will answer the team's product questions. Those two steps prevent the most common first-month delays. To talk through how a Coretus team would start on your project, book a free 30-minute call.

About the author

Ravi Dadhaniya, COO

COO at Coretus Technologies. Runs delivery across client projects: planning, coordination across time zones, quality and compliance.

LinkedInLeadership team

FAQ

Straight
answers

Have a different question? Ask it on a 30-minute call.

Book a call

Plan for about a month before a new software development partner is fully settled. Access, accounts and documentation come in the first week, a small first sprint runs in the second, and the meeting rhythm should be steady by the fourth. With Coretus, a scoped project can kick off in 1–2 weeks once deliverables and milestones are agreed.

In practice

All case studies
  • FinTechSaaS & Software

    Digital banking security: Ready for post-quantum cryptography

    We made a digital banking core ready for post-quantum cryptography, with swappable encryption, hybrid ECC and NIST ML-DSA signatures, and automated key rotation. The core now has 100% NIST alignment, and there was no service downtime during the change.

    NIST alignment
    100%
    Service downtime
    0
  • FinTechSaaS & Software

    Embedded B2B lending: Invoice financing inside a supply chain platform

    We added invoice financing to a supply chain SaaS platform, so suppliers get credit decisions and payouts inside their invoice workflow. Supplier retention rose 24%, and decisions come back in under 850ms.

    Higher supplier retention
    24%
    Credit decision time
    <850ms
  • HealthTechSaaS & Software

    Healthcare operations: One portal for referrals, records and tasks

    We built a custom operations portal for a healthcare services provider. Referrals, administrative records, documents, internal tasks, status changes and reporting now sit in one workflow.

    Connected experience
    One
    Business visibility
    Live

Keep reading

All articles

Turn ideas like these into working software

Tell us where you are. We'll suggest the right team and a rough quote range.