What a week with the team looks like
With a dedicated team, the backlog is yours and the team works from it. A typical week runs like this:
One named contact
If you add a product owner to the team, questions, priority changes and the weekly release go through them, and they manage the developers. If not, one named person in the team is your contact.
An open task list
You can see what’s done, what’s next and who is on it whenever you like.
A working version every week
On the same day each week, you get a version of that week’s work that you can open and try.
New requests in writing
When something new is added to the list, you get its time and budget impact in writing within 24 hours.
How the team gets to know your product
Any team joining an existing product first has to learn the code, the tools and how decisions get made. We usually run that period in this order:
- 01
Access is set up
We get access to your code repository, task tracker, test environments and communication channel. You decide how much access to give.
- 02
The team reads what exists
The team goes through the code, the architecture and any documentation, and collects open questions in a single list.
- 03
Small tasks first
Picking small, well-defined tasks for the first weeks lets the team deliver while it learns the codebase.
- 04
The full backlog
As the team gets to know the product, it takes on larger tasks that depend on other parts of the system.
Someone on your side who owns the backlog, such as a product manager, makes this period much easier.
What we need from you before we start
Access
Permissions for the code repository, task tracker, and test and live environments, as far as the work needs them.
A backlog owner
One person who sets priorities and makes the call when questions come up. This could be your product manager, your CTO or the business owner.
Weekly feedback
Enough time to open each week’s version, try it and write back.
Existing documents
Whatever you have: technical notes, design files, old scope documents. It’s fine if they are incomplete.
Contract paperwork
Your NDA and, if you have one, your own MSA/SOW template. We sign it and work within it.
Choosing the team size, and changing it later
The team has between 2 and 6 people, and we always agree its size together. In the scoping call we look at questions like these:
How much work
How much is on the roadmap for the coming months, and how many pieces of work need to move at the same time?
Which skills
Which areas does the work cover: web, mobile, integration or AI?
Time on your side
How much time does the person feeding the backlog and reviewing releases have?
Deadlines
Is there a release that has to be ready by a particular date?
If the work changes, we can talk about the team size again. You raise it with your contact on the team, and we agree the new size together.
What stays with you when the engagement ends
When the engagement ends, your product carries on with you. This is what you keep:
All the code and IP
Once payment is complete, all source code the team wrote and the full IP belong to you.
Documentation and setup
You also keep the documentation and setup instructions, so another team can take the product over.
Options for afterwards
If you like, we can carry on with a monthly retainer or a new fixed-scope project.
A second team alongside your in-house developers
If you have developers of your own, a dedicated team can work in parallel with them. To keep the two teams out of each other’s way, the work is usually split like this:
Clear boundaries
Which module or workstream sits with which team is written down at the start.
One point of contact
One person on our side talks directly with your tech lead or product manager: the product owner if the team has one, otherwise a named member of the team.
Your ways of working
Our team works to your coding standards, review process and release schedule.