"...we concluded that several small repositories is the cheaper option."
That's great. Divide and conquer. You break the effort into logical pieces, give each piece to a different hard-core team, work like mad for a few months, bring everything together, and...
Well, it'll be a damn nightmare. It definitely won't be cheaper. Why would it be?
The largest "cost" in any software project is communication. You don't save money by writing code faster. That's the secret programmers won't admit. (Psst. Don't tell anyone. It really doesn't matter how fast you write code.) The time spent writing code is absolutely dwarfed by the time spent planning and talking and negotiating and fighting and talking and meeting and talking some more and compromising and realizing you shouldn't have compromised and promising to do better and yelling and wishing and "solutioning" (that's not a word, dammit) and looping back and pinging and talking and not being able to sleep.
So, you break your work into discrete chunks and hand each chunk off to a separate team. What did you just do? You added communication burden. If you're lucky and your teams are perfect, there's absolutely no cost difference between one big repository and a few small repos. If you're not lucky (few are), breaking into separate teams will actually cost more. It's hard enough to stay in synch when you're all in the same code base, stepping on each others' toes. Now imagine how hard it will be when three different teams think the requirements mean something slightly different (with no way to correct quickly because they're not breaking the other teams' stuff), have slightly different cultures, and, in the end, are very motivated to avoid blame when things go wrong so they're more than willing to throw the other teams under the bus.
I know, I know... your teams are better than that. But are they really? Are you confident enough to bet money on it?
Look, in either approach (big repo/many little repos) you're going to have to mock out a bunch of crap in the beginning. You start working blind. As soon as possible, as soon as they're available, you should start using concrete implementations from the other layers. This will identify problems and misunderstandings early. Sure, it will be a little bumpy, but it's a hell of a lot less bumpy than developing independently with a shaky spec and a handshake, and then folding things together late.
My point is, big repo/little repos isn't the issue. What matters is how you structure your teams. Ideally, your teams have small independent identities within a larger cohesive identity. Kinda like organs in an organism or maybe a slime mold. Regardless of how you structure the code, give everyone a chance to bump into each other. Make communication easy. Make mistakes together and fix them early and often.