As the more junior dev on this team, you have very little you can say that will have any real effect, especially since your boss seems to be ready to tackle this project.
If you were still talking to the upper managers that deal with the costs during the planning stage, I might suggest asking them financial questions, instead of technical questions. Upper management typically responds better to that than technical questions/situations they may not understand.
- If we fail to meet the deadline, how much is this going to cost the company?
- Is the cost of the license worth +4 months of our development time, including the time we could be working on something else? And including the time of all the planning meetings?
- Is it worth the cost of having to keep maintaining this project until it's no longer needed and the other team sunsets the project that requires it?
I'm sure you can think of similar questions to ask, but as a junior dev (at least on this team), you may not have the authority to ask these questions in the first place. And it may already be too late to ask them now. However, it might be a decent gut check for them, still, prefacing the question with "With all the time and effort we've already spent on this and all the time we know it's going to take to accomplish this project..."
But if it's too late to do that, then @Hilmar's answer is really good. Because what that does is it gets rid of the "feeling" something is not going to make deadline and instead states the schedule as a certainty, and then you can say "for sure" whether this is going to meet the deadline, or not. Don't guess at large projects, break it down to pieces, and depending on if the pieces fit or not, you have your answer. Maybe the other dev is a better project manager and can estimate better than you can. It sounds like you don't know. I sure don't. So, work with them to actually set a schedule and plan this out.
I know I like to think that I'm good at estimating projects, with my 16+ years experience as a software engineer, but I have to admit that I'm wrong more times than I'm right, at least with the larger projects. Sometimes I estimate too much time and sometimes I estimate too little. And sometimes unexpected things come along that no one could have expected to put you behind schedule. And, just to be complete, maybe there's something that ends up being easier and speeds you up (maybe 1% of the time IME).
I try to under-promise and over-deliver. So if I think a project will take 2.5 months, I say it'll take 3 months. It's sort of like the so-called "Scotty Principle", but not as extreme. So, you plan it out and then give them an expected date that's 10-20% longer than you expect. Or, since the due date is set, tell them you can do 10-20% less than is expected to be done by then. Remember, your expectations of how long a task will take is a guess, not a hard number written in stone where at the end of that timeframe it'll definitely be done. An hourglass might have an exact amount of time for it to finish, but software development sure doesn't.
About the only thing I'm sure about with your situation is that you are likely too far into it to be able to easily convince anyone of backing out now. The whole "sunk cost" fallacy, and all that.
I see 3 major options here:
- Do the work and see where things fall, and hope you can get the work done so you can keep your job.
- Overwork yourself to make sure you hit the deadline, and then deal with burnout and future unrealistic deadlines, while hoping they fire you.
- Start looking for a new job now and see where things end up.