Skip to content
5 free audits openClaim a spot →
Hiring a Partner

Your First Two Weeks With a New Product Partner

Tanjim Islam

Founder & CEO · · 5 min read

Summarise with AI
Blog cover with a chalk doodle, titled Your first two weeks with a new partner.

This post covers what happens after you sign, the last step in our guide to hiring an AI engineering partner.

Why do the first two weeks matter so much?

Because they set the pattern for the rest of the project.

If decisions are slow in week one, they will be slow in week ten. If you see nothing until week three, you will probably see little in week twelve. The good news is that the first two weeks are also the easiest time to fix the pattern, because nothing big has been built yet.

What happens at kickoff?

The kickoff turns the brief into a shared plan. Expect a call of an hour or two with the people who will do the work, not only the people who sold it.

Four outputs of a kickoff: a named decision maker, a one sentence goal, open questions with owners, and a meeting rhythm
Illustrative diagram based on this article. Not product UI, not real data.

By the end you should have:

  • One decision maker on your side, named in writing.
  • The goal for the first piece of work, in a sentence. For example: "a clickable prototype of the approval screen, tested with three support agents."
  • A list of open questions, with an owner for each.
  • A meeting rhythm: a weekly demo, plus a chat channel for daily questions.

The Scrum Guide describes the same idea for its own short work cycles: "Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint" (The Scrum Guide, November 2020, fetched 25 Oct 2026). You do not need to use Scrum. You do need a written goal.

What access does the team need in week one?

Access is often where first weeks lose days. Prepare it before kickoff if you can.

  • Code and hosting: a repository and cloud account in your name, with the team invited.
  • Design files: a shared workspace you own.
  • Data: sample records the AI or product will use, with personal details removed where you can.
  • Existing systems: test logins for any tool the product connects to.
  • People: two or three users the team can talk to in week one.

Keeping accounts in your name from day one means nothing needs moving later. At Gr8r, clients own everything once it's paid for.

What should you see by the end of week two?

Something you can react to. A clickable prototype, a first working screen, or, for an AI feature, the model running on a sample of your real data with the results laid out.

Here is an illustration, not a real client project. A healthcare operations team hires a partner to add an AI summary to its referral screen. By day ten, the team shows twenty real referrals, anonymised, with the AI summary next to each and a mark for right, partly right or wrong. That page tells everyone more than a month of meetings would.

For longer research phases, the UK Government Digital Service says "around 4 to 8 weeks is typical" for discovery and "You should not start building your service in discovery" (GOV.UK Service Manual, How the discovery phase works, fetched 25 Oct 2026). That guidance is for public services. A startup's first piece is usually shorter, but the rule holds: learn first, then build.

What does a good weekly demo look like?

Short, concrete and ending in decisions.

The Scrum Guide puts the purpose of its review meeting as "to inspect the outcome of the Sprint and determine future adaptations." In plain terms: look at what was built, then decide what changes.

A good demo has three parts:

  1. Show working screens, not slides. Click through them live.
  2. Name what is still open, with a date for each answer.
  3. Write down the decisions and send them the same day.

If you leave a demo without written decisions, ask for them before the end of the day.

What should you watch for in the first two weeks?

Good signs are the same people from the sales call, questions about users and data, something to react to by week two, written decisions, and accounts in your name.

Healthy signWarning sign
The people on the sales call are on kickoffNew faces you have never met
Questions about users and dataQuestions only about features
Something to react to by week two"Next week" twice in a row
Decisions written down after each demoDecisions living in someone's memory
Accounts in your nameAccounts in the partner's name

The longer list of warning signs is in red flags when hiring a software partner. The engagement model you signed shapes week two as well; see fixed scope or time and materials for your AI build.

What is your job in the first two weeks?

Answer fast. A partner waiting a day for each answer loses a week by Friday. Keep your decision maker free for the weekly demo, send the data you promised, and say early if something feels off.

If you want a first piece of work scoped this way, see product discovery or talk to us.

Frequently asked questions

What happens in the first week of a software project?

A kickoff call, access to the systems and data the team needs, a written goal for the first piece of work, and early sketches or questions. By the end of the week you should know who decides what, and when you will see something.

What should you prepare before kickoff?

Your one page brief, a named decision maker, access to data and existing systems, a list of users the team can talk to, and any designs or prototypes you already have.

When should you see working software?

Within the first two weeks you should see something you can react to, such as a clickable prototype or a first working screen. After that, expect a demo every week.

What if the first two weeks go badly?

Say so at the weekly demo, in writing. Name what is missing and agree what the next week must show. If the second week looks the same, use the exit terms in your contract.

Who should attend the weekly demo?

The person who makes product decisions, someone who knows the users, and the partner's designer and engineer. Keep it short and end with written decisions.

About the author

Tanjim Islam is the founder and CEO of Gr8r Studio. He founded the studio in 2023. Here he writes about how Gr8r approaches hiring, product design and AI engineering. More on the About page.

To see what a written review looks like, read our UX audit of Veluno, a supplier onboarding product we built and then reviewed the way we review client products. Built by Gr8r for its own portfolio. Not client work.

If you want help with this, book a 30 minute call.

Written by

Tanjim Islam

Founder & CEO

Book a call with our CEO.

Pick a time that suits you. A product idea or a workflow that slows your team down: a clear problem is enough, no full specification needed.

Your call is with Tanjim Islam, our CEOA free 30-minute conversation about your problem, not a sales pitch.

Calendar not loading? Open the booking page