The second team that builds your next product

The problem is not money, and it is not the spec

It is that there is no month in the calendar where the people who could build it are free. Maintenance is not a failure of your team, it is what a working system costs. But it means the roadmap never starts, and every quarter the new product moves one quarter to the right.

Who this is for

• The new product has been on the roadmap for three quarters and has not started.
• Every sprint, the new work gets pushed because something in production needed attention.
• You have the budget and you have the spec. What you do not have is a team with a free month.
• Hiring would take six months, and at the end of it you would still have to manage them.
• Your engineers are protective of the codebase, and they are right to be.
• The last time you tried an outside team, your own engineers ended up reviewing their work, which cost more time than it saved.

How it works

The whole arrangement is designed around one constraint: your engineers stay on their own work.

1. Scope

   We scope it without your team

   We read the system, the schema and the existing integrations ourselves. Your engineers give us one day of questions, not a standing weekly meeting. If we need something explained twice, that is our cost to carry, not theirs.

2. Separate

   The new product gets its own surface

   Its own repository, its own deployments, its own on-call. It reaches your existing system through an interface we agree in writing at the start. Nothing we build can wake your team at three in the morning, because nothing we build runs inside their perimeter.

3. Ship

   You see working software every two weeks

   Not a percentage, not a status colour. Something you can open and use. If a slice is late we say so in the same fortnight, while there is still room to change what comes next.

4. Handover

   Then you keep it, or we keep running it

   Handover is a planned piece of work with a date on it, not a hope. Your team gets the codebase, the runbook and two weeks of us sitting with them. If you would rather we carried it, that is a separate and much smaller arrangement.

What you get

All of it is yours from the first commit, not at the end on good behaviour.

• The product, running

  In your cloud account or ours, your choice, made at the start rather than discovered at the end.

• The interface contract

  Written down before any code: what the new product may read from your system, what it may write, and what happens when either side changes.

• A handover your team can accept

  Architecture notes, the runbook, the decisions we made and why. Written for the engineer who inherits it, not for the person who signs the invoice.

Who owns what

Written here because this is the part that goes wrong quietly.

We have done this

EasyCEP came to us twice, for two different products, while their own team stayed on the platform they already ran. We are doing the same thing now with Sipay.

• 

  EasyCep Garaj

  A full-stack commerce build, storefront through to operations.

• 

  EasyHesap

  Pre-accounting and stock control built for the mobile phone retail market.

The questions we get asked

• Our engineering team has no capacity for a new product. What are the actual options?

  There are four, and only two of them work. You can hire, which takes six months and leaves you managing more people. You can pause maintenance, which nobody survives. You can rent individual developers and have your own engineers supervise them, which consumes the capacity you were trying to create. Or you can hand a whole product to a team that scopes it, builds it and runs it on a separate surface, and keep your engineers where they are. The last one is the only option that does not spend your team's time to save your team's time.

• How do you build a new product without pulling our engineers off the existing one?

  By never needing them on the critical path. We read your system ourselves instead of being walked through it. The new product lives in its own repository with its own deployments and its own on-call, and it talks to your system through one interface agreed in writing at the start. Your engineers spend about a day at the beginning and a couple of hours a month after that. If we need more than that, we have scoped it wrong and that is our problem to fix.

• Is this staff augmentation?

  No, and the difference is the whole point. Staff augmentation gives you developers who need direction, review and a place in your sprint, which means your senior people spend their time on them. We take a product, not a seat. You set the direction and the priorities; we handle scoping, staffing, delivery and running it. You review the working software every two weeks, not the pull requests every day.

• Who owns the code when it ships?

  You do, from the first commit. The repository can sit in your organisation from day one if you prefer. There is no licence, no escrow arrangement and no period where the work is held against payment.

• What happens if our internal team wants to take it over later?

  That is the expected ending, not an exception. Handover is planned work with a date: your engineers get the codebase, the architecture notes, the runbook and two weeks of us sitting alongside them. We build assuming this will happen, which is why the code is documented for the engineer who inherits it rather than for the person who signs the invoice.

• What do you need from our team, and how much of their time?

  Read access to the relevant parts of the system, one day of questions at the start, and a named person we can reach when the interface contract needs a decision. After the first week, expect a couple of hours a month. We deliberately do not ask for a seat in your standups.

Tell us what has been stuck on the roadmap

Send the one-paragraph version. We will come back with what we think it takes and which parts we would not touch.

Start a project

Building the Product for What's Next