Why integrations go first in a custom software schedule

On projects with third party integrations we build them first, before any other feature. The reason sits outside our team: verification on Google's side took 2 to 4 times longer in our projects than on Meta's, where it usually fit inside 2 weeks. Neither budget nor a bigger team shortens that.

If you are asking where an implementation should start, this is a specific answer. Not with the feature that demos well, but with the part that has a queue attached to it on someone else's desk.

A schedule that ignores this looks correct on paper and breaks in the final week. Not because anyone was late with the code. Because the code is waiting on a decision nobody applied for in time.

Sequence decides the deadline more than speed of work does

On one project the client arrived with a scope where third party integrations were spread evenly across the timeline, like any other feature. That is a reasonable instinct: similar amount of work, so put it where it fits.

We advised moving the Google integration to the very start, ahead of everything else. The client dropped no integrations. Only the order changed.

The effect was that verification ran in parallel with building the system instead of after it. The deadline held. Had the integrations stayed where the original scope put them, the project would have been waiting on someone else's decision during the week it was supposed to go live.

Verification on Google's side took 2 to 4 times longer than on Meta's

This is an observation from our projects, not an official timeline from either company. On Meta, verification usually fit inside two weeks. On Google it ran several times longer and was harder to predict.

That difference has one property which makes it more dangerous than most other risks: it does not compress. You can add developers, pay more, work weekends. The queue on the other side will not move faster, because it is not yours.

So we treat it as foundation rather than as a task. Foundations go first, if only because everything else sits on them. A task can be rescheduled.

What happens when you skip this

The project looks healthy for most of its life. Features ship, the demo works, status reports are green. The problem is invisible because it does not present as a delay. It presents as a missing action nobody scheduled.

It surfaces at the end, in the week set aside for launch. That is when you learn the system is finished and one integration is waiting on a review that will take several more weeks. There is nothing to fix, because nothing is broken.

Anyone who has lived through an ERP rollout recognises the shape. Not "we did not finish building it", but "we built it and cannot switch it on". The second one hurts more, because the money is already spent.

What else is usually missing from the scope we receive

When you plan a first version you think about features. About what the user will see and click. Rarely about what is required to release those features lawfully.

On that same project the scope had no mechanism for managing consent under data protection rules. We added one from our own resources: versioning and confirmation of consents. It was not in the quote and the client did not pay for it. It cost us a few days of work, reduced by reusable code from earlier projects of this type.

Without that module the problem would not have surfaced immediately. It would have surfaced after validation in a closed beta, when moving to a wider group of users. Instead of scaling a product with confirmed value, the client would have stopped to build a layer nobody planned for. Same shape again: not missing work, but missing permission.

What we do not promise here

We do not quote a verification time for a third party, because we do not control it. We can tell you how long it took us and how many times, and set the sequence on that basis. We cannot tell you how long it will take for you.

We also do not claim that 2 to 4 times is a market figure. It is what we saw on our own projects, and that is how you should treat it. A firm that gives you an exact percentage here either measured it across a large sample, and will tell you how large, or is guessing.

Our 63 working days run from scope sign off and we hold that date. It contains the verification window precisely because integrations go first. If they went last, the same date would be a promise about something outside our control.

What this means for your schedule

Ask your vendor one question: which parts of this project depend on a decision made by someone outside the team. An answer of "none" means nobody checked, because integrations, payments, app stores and data access usually do.

Then ask where those parts sit in the schedule. If they sit at the end, ask for them to be moved to the front and for an explanation of what that changes in cost. Usually nothing, because it is the same work in a different order.

Before you write to us

We do not promise deadlines we do not control, and we do not take projects where a third party review has to fit inside two weeks because that is how it looked in a board deck. If the date is fixed for business reasons, we say so before signing rather than in the final week.

If you are planning custom software and want to see how we lay out a schedule: see what custom AI software covers. The price and the timeline are stated there.