Onboarding a Dev Partner: The First Two Weeks That Matter

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A seed-to-Series-A SaaS founder who just signed with an offshore dev studio and has no CTO — they approved the budget, countersigned the SOW last week, and now have no idea what they are supposed to do before the first sprint starts

The first two weeks after signing a dev contract are almost entirely on you, the buyer. If you do not hand over working access, a signed acceptance-criteria document, and a named decision-maker before the kickoff call ends, your week-three sprint will stall — and the vendor will bill against the milestone clock regardless of who caused the delay. This playbook walks a founder without a CTO through the six things to run yourself in those ten business days, in the order they matter.

The context for why this is so often fumbled: a hired CTO at seed stage runs $120K–$180K in base plus 1–4% equity and takes three to six months to find, which is why most seed-to-Series-A founders are signing with an offshore studio in the first place. The studio can write the code. It cannot sign your DPA, provision your AWS root account, or decide what "done" means for your checkout flow. Those are buyer jobs, and they are what the next two weeks are for.

The stakes are not theoretical. Nearly 70% of IT outsourcing projects exceed their budgets and timelines, with poorly defined contracts driving overruns averaging 50% beyond initial estimates. McKinsey put poor requirements at the root of 68% of software project failures — ahead of resourcing, tooling, or vendor quality. The common thread in both numbers is a buyer who treated kickoff as a handoff instead of a setup.

Step 1: Lock down a single decision-maker on your side (Days 1–2)

Before anything else, decide who on your team the vendor is allowed to take "yes" from. For most seed-stage founders, that is you. Write it down in an email to the vendor PM: name, email, Slack handle, timezone, and the hours you will reliably respond in. If a co-founder or an advisor is going to approve designs or sign off on feature scope, name them too and specify their domain.

The anti-pattern: three co-founders all giving the vendor contradictory feedback in a shared Slack channel. The vendor will pick whichever answer unblocks them that day, and you will not find out which one until the demo.

You will know this step is done when the vendor's PM has sent you a written confirmation naming you (or your delegate) as the sole approver for scope, design, and milestone sign-off, and you have replied agreeing.

Step 2: Provision real access, not promised access (Days 2–4)

This is the step founders most consistently defer, and the one that most reliably torpedoes week three. The vendor needs working credentials to actually start — not a Calendly link to "figure it out next week." At minimum, before the kickoff call ends:

• Source control: a GitHub or GitLab organization with the vendor's engineers added, repo created, branch protection rules drafted
• Cloud: an AWS, GCP, or Azure account with IAM roles scoped to the vendor team — not your root credentials shared over email
• Design: Figma access with edit rights to the right project, not view-only on a personal file
• Communication: a Slack Connect channel or shared workspace, with a documented response-time expectation on both sides
• Project tracking: Jira, Linear, or whatever the vendor uses — you need a seat, not just status reports
• Third-party services: Stripe test keys, SendGrid, Twilio, any API you expect the MVP to touch

If you do not have a cloud account yet, open one on day one and put billing alerts on it. Do not let the vendor open it under their account "to make it easier" — you will fight about ownership of the environment later, and you will lose leverage during handover.

The anti-pattern: giving the vendor a shared Google account with your root AWS credentials. You now have no audit trail, no least-privilege boundary, and a security review failure waiting for your Series A diligence.

You will know this step is done when a vendor engineer has pushed a commit to the repo, logged into the cloud console under their own IAM user, and posted "access confirmed" in the shared Slack channel.

Step 3: Convert the SOW into testable acceptance criteria (Days 3–7)

Your SOW probably says something like "user authentication module" or "admin dashboard with reporting." That is not a specification. That is a line item. The vendor will build to whatever interpretation gets them to the milestone, and you will discover the gap at demo.

Spend the first week turning each SOW line item into a short list of acceptance criteria the vendor's QA can test against. You do not need a 40-page PRD. You need two or three sentences per feature in the form of "when a user does X, the system does Y, and we can verify it by Z." For auth: "A new user can sign up with email and password, receives a verification email within 60 seconds, and cannot log in until verified." That is testable. "Auth works" is not.

Why this one step pays off disproportionately: 60–80% of software project failures trace directly to poor requirements gathering. Spending four afternoons on acceptance criteria is cheaper than losing a sprint to a rebuild.

The anti-pattern: assuming the vendor's business analyst will "figure it out from the SOW." They will figure out something. It will not be what you had in your head.

You will know this step is done when every milestone deliverable in the SOW has a bulleted list of acceptance criteria attached, both parties have signed it (DocuSign is fine), and the vendor's PM has confirmed in writing that these are the criteria QA will test against for milestone sign-off.

Step 4: Confirm IP assignment and the DPA in writing (Days 4–7)

Your SOW probably has an IP assignment clause. That is not the same as the vendor having actually assigned IP. Specifically, check:

• The clause assigns IP on creation or on payment of each milestone — not "on project completion," which gives the vendor leverage if a dispute arises mid-project
• The clause covers subcontractors and individual engineers, not just the vendor entity (ask for the engineers' signed assignment agreements if your diligence will need them later)
• Any open-source components the vendor plans to use are disclosed, with licenses listed — a GPL dependency in your proprietary SaaS is a problem you want to find now, not during an acquisition
• If you process any user data in the EU, UK, or California, a Data Processing Agreement is signed before any production data touches the vendor's environment

This is not legal advice — have your startup lawyer review the actual clauses, especially if you are raising a priced round in the next twelve months, where IP chain-of-title will be diligenced. The point here is procedural: do not let kickoff happen before the paperwork is actually signed, not just agreed in principle.

The anti-pattern: "We'll sign the DPA next month, let's just get started." You will not sign it next month. You will sign it the night before a customer's security review, under pressure, with whatever the vendor's lawyer proposes.

You will know this step is done when the countersigned IP assignment and DPA are in your document system, dated before any code is written, and your lawyer has confirmed the chain-of-title language is clean.

Step 5: Agree on how "done" gets signed off and invoiced (Days 7–10)

Milestone disputes are the single most expensive thing that goes wrong in month three. The fix is cheap and goes in week two: agree, in writing, on the exact process for approving a milestone and triggering an invoice.

A workable template:

1. Vendor demos the milestone against the acceptance criteria from Step 3, in a recorded call
2. You have five business days to raise defects in writing, referenced to specific acceptance criteria
3. Defects that match the criteria are the vendor's cost to fix before sign-off; changes that go beyond the criteria are a change request with its own estimate
4. Milestone is signed off and invoiced only after defects are closed, with a hard deadline (e.g., 10 business days) past which silence counts as acceptance

The last clause protects the vendor from a founder who disappears for three weeks. The defect clause protects you from paying for something that does not match what you signed off on. Both of you need both.

The anti-pattern: no written sign-off process. The vendor emails "milestone complete, please pay," you reply "it's missing X," the vendor says X was never in scope, and now you are negotiating under invoice pressure.

You will know this step is done when the sign-off and change-request process is written into a one-page addendum to the SOW, both parties have signed it, and you have a shared template for the milestone demo and defect log.

Step 6: Set the operating cadence before sprint one (Days 8–10)

Finally, agree on the meeting rhythm. For an offshore engagement with meaningful time-zone overlap problems — which industry data suggests increases project delays by 15–20% — the cadence that works for most seed-stage founders is:

• Daily: async standup in Slack, posted by the vendor PM, read by you within your workday
• Weekly: 30-minute sync with the vendor PM — progress against the sprint, blockers you need to unblock, decisions you owe them
• Every two weeks: sprint demo against acceptance criteria, with the recording shared
• Monthly: milestone review, invoice sign-off, retrospective on what is slowing you both down

The non-obvious part: write down what the vendor should do when you are unreachable. Default decisions, escalation paths, whether to pause work or proceed with their best judgment. You will go dark for a week at some point — fundraising, a conference, a sick kid. The vendor needs a protocol, not a guess.

The anti-pattern: "We'll just Slack as things come up." This works for the first three weeks. By week six, you have 400 unread messages across four channels and the vendor is building to decisions you never actually made.

You will know this step is done when the meeting calendar is on both teams' calendars for the next 90 days, the async-standup template is agreed, and the "what happens when the founder is unreachable" protocol is written in the shared workspace.

What a realistic two-week timeline looks like

Illustrative, for a founder running this alongside their day job: Steps 1–2 take two to four days of elapsed time but maybe four hours of your focused work. Steps 3 and 5 — acceptance criteria and sign-off process — are the real time sink, likely a full day each if you have never written acceptance criteria before. Step 4 depends on how responsive your lawyer is; budget a week and chase. Step 6 is a 90-minute planning call plus follow-through.

If you compress all six into ten business days, you start sprint one with the vendor actually able to build, and with the paperwork that protects both of you already signed. If you skip any of them, you are relying on goodwill — which lasts until the first disputed invoice. The research on large-project overruns is unambiguous: the cost of fixing a problem late is multiples of the cost of surfacing it in week two.

If you are evaluating partners who do this well, the signal to look for in reference calls is whether the vendor pushed their previous clients through a structured onboarding like this one, or whether they let the client set the pace. The ones who let the client set the pace are the ones whose projects show up in the 1-in-6 "black swan" statistic. For a sense of how structured onboarding plays out in practice across different domains, the GimBooks, Vahak, and Cashpo builds all started with versions of these six steps compressed into the first fortnight.

Frequently Asked Questions

How long should the first two weeks actually take if I have a day job?

Realistically, ten business days of elapsed time with about three to four days of your focused work spread across them. The access provisioning and operating cadence are fast; the acceptance criteria and sign-off process are what take real thinking time. If you cannot find those days, delay the kickoff — do not start the sprint clock on a foundation you have not built.

Can the vendor write the acceptance criteria for me?

They can draft them, and a good vendor will offer to. But you have to review and sign off, because acceptance criteria are the contract for what you are paying for. If you rubber-stamp the vendor's draft, you are agreeing to build what they interpreted, not what you wanted. Treat their draft as a strawman and spend an hour per feature pushing back on anything ambiguous.

What drives the cost of a dev partner engagement, and what should I ask to turn a range into a quote?

The cost model is driven by scope specificity (vague scope widens the range dramatically), integration count, data migration complexity, compliance requirements, and whether you need the vendor to take on product and design decisions or just execute to a spec. The three things that turn a range into a real quote: a feature list with acceptance criteria, a list of third-party systems to integrate, and a decision on whether you own cloud infrastructure or the vendor does. Any studio quoting a fixed price without those three inputs is quoting a number they expect to renegotiate.

What if the vendor pushes back on signing the DPA or IP assignment before kickoff?

That is a signal, not a scheduling problem. A vendor who routinely builds for startups has these documents on a shelf and signs them in a day. One who stalls is either disorganized or has clauses they do not want examined. Either way, have your lawyer review before you proceed — this is not an area to take legal advice from a blog post, and the cost of a two-hour lawyer review is trivial against the cost of a disputed IP claim at your Series A diligence.

Who owns the cloud account — me or the vendor?

You do, always. The vendor gets scoped IAM access to build and deploy, but the account root, billing, and ability to revoke access stay with you. The only exception is a short discovery or prototype phase where the vendor spins up a sandbox they will tear down. Anything that will touch production, user data, or outlive the engagement goes in an account you own from day one.