A second team for your next product
Your engineers maintain the system the business depends on. That is the correct use of their time. We build the new product alongside them, without reassigning anyone.
The constraint is capacity, not budget or scope
There is no month in the calendar in which the people who could build it are available. Maintenance is not a shortcoming of your team; it is the running cost of a system that works. The consequence is that the roadmap never begins, and the new product moves one quarter further out every quarter.
Who this is for
- The new product has been on the roadmap for three quarters and has not started.
- New work is deferred each sprint because something in production requires attention.
- The budget is approved and the scope is defined. What is missing is a team with available capacity.
- Recruitment would take six months, and you would then have additional people to manage.
- Your engineers are protective of the codebase, with good reason.
- The last external team you engaged had to be reviewed by your own engineers, which cost more time than it saved.
How the engagement works
The entire arrangement is designed around a single constraint: your engineers remain on their own work.
Scope
We define the scope without occupying your team
We review the system, the schema and the existing integrations ourselves. Your engineers provide one day of questions, not a standing weekly meeting. If something has to be explained twice, that cost is ours to absorb.
Separate
The new product runs on its own surface
Its own repository, its own deployments, its own on-call rotation. It connects to your existing system through an interface agreed in writing before development begins. Nothing we build runs inside your team's perimeter, so nothing we build can escalate to them outside working hours.
Deliver
You review working software every two weeks
Not a completion percentage and not a status indicator. Software you can open and use. If a slice is going to be late, you are told within the same fortnight, while there is still room to reorder what follows.
Handover
You take it over, or we continue to operate it
Handover is planned work with a date attached, not an assumption. Your team receives the codebase, the runbook and two weeks of our engineers working alongside them. If you would prefer that we continued to operate it, that is a separate and considerably smaller arrangement.
What you receive
All of it is yours from the first commit, not released at the end of the engagement.
The product, in production
In your cloud account or ours. The decision is made at the start rather than discovered at the end.
The interface contract
Documented before any code is written: what the new product may read from your system, what it may write, and the process that applies when either side changes.
A handover your team can accept
Architecture notes, the runbook, and the decisions we made with the reasoning behind them. Written for the engineer who inherits the system rather than for the person who approves the invoice.
Who is responsible for what
Documented here because this is the part that most often fails without anyone noticing.
| Product direction and priorities | You |
|---|---|
| Release order | You, on our advice |
| Delivery, staffing and timeline | Us |
| On-call for the new product | Us |
| Your existing codebase | Untouched unless you request otherwise |
| The code we write | Yours, from the first commit |
Comparable work
EasyCEP engaged us twice, for two separate products: we built the EasyHesap side and the Garaj mobile application while their own team remained on the platform they already operated. We are currently working with Sipay on the same basis.
EasyCep Garaj
A full-stack commerce build, storefront through to operations.
EasyHesap
Pre-accounting and stock control built for the mobile phone retail market.
Frequently asked questions
Our engineering team has no capacity for a new product. What are the realistic options?
There are four, and two of them are viable. Recruitment takes six months and leaves you with more people to manage. Suspending maintenance is not sustainable. Contracting individual developers requires your own engineers to direct and review them, which consumes the capacity you were attempting to create. The remaining option is to hand a complete product to a team that scopes it, builds it and operates it on a separate surface, leaving your engineers where they are. It is the only one that does not spend your team's time in order to save it.
How do you build a new product without reassigning our engineers from the existing one?
By keeping them off the critical path. We review your system ourselves rather than being walked through it. The new product runs in its own repository with its own deployments and its own on-call rotation, and it connects to your system through a single interface agreed in writing at the outset. Your engineers spend approximately one day at the start and a few hours per month thereafter. If more is required, the scope was defined incorrectly and correcting that is our responsibility.
Is this staff augmentation?
No, and the distinction matters. Staff augmentation provides developers who require direction, review and a place in your sprint, which means your senior engineers spend their time managing them. We take responsibility for a product rather than filling a seat. You set the direction and the priorities; we handle scoping, staffing, delivery and operation. You review working software every two weeks rather than pull requests every day.
Who owns the code on delivery?
You do, from the first commit. The repository can sit within your organisation from day one. There is no licence, no escrow arrangement and no period during which the work is withheld against payment.
What happens if our internal team wants to take it over later?
That is the expected conclusion rather than an exception. Handover is planned work with a date: your engineers receive the codebase, the architecture notes, the runbook and two weeks of our engineers working alongside them. We build on the assumption that this will happen, which is why the code is documented for the engineer who inherits it rather than for the person who approves 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 contact we can reach when the interface contract requires a decision. After the first week, expect a few hours per month. We deliberately do not ask for a place in your standups.
Related reading
How EasyCep Added Two Products Without Pausing the Core
EasyHesap and then Garaj, built for the same client without their business pausing. How the boundary was drawn, and what the second engagement changed.
What the Year-End Slowdown Is Actually Good For
Three weeks of low capacity is either lost or it is the only window all year for discovery, audit and the decisions nobody has time for.
Why the Year-End Stock Count Takes a Week
The annual count is a measurement of how accurate your stock data was all year. Here is how to read the result.
Running Internal and External Teams on the Same System
Collisions are not a people problem, they are a boundary problem. Where to draw the line between two teams so neither can break the other's release.
Tell us what has been waiting on the roadmap
Send the one-paragraph version. We will respond with our view of what it requires and which parts we would leave alone.
Building the product for what comes next
We would rather deliver one product that holds up than three that have to be rebuilt. That standard is the same on every project, whatever its size.
Ali Boran GazelCEO