This could be difficult.
I think planning is your key. Do you have a project plan that the three of you are working to?
If not, I would suggest you come up with one before your colleagues jump ship. At the very least this will be a list of all the tasks you need to do on the project. The more detail the better (up to a point - but just saying "develop such-and-such a screen" is probably not detailed enough). Also include things like documentation and plans.
This is the top priority.
You should go through every task on the list and satisfy yourself that the time allowed for the task suits you. Its no good one of your colleagues estimating a day for a particular task, if its something you know nothing about and would likely take you a week. Also be aware that developers tend to be optimistic about timescales - since you say you have little experience in this area you will likely fall into this trap. Unfortunately the main thing that will help you there is experience, but some "rules" that spring to mind could be:
- nothing takes less than a half-day. Even if its a one-line code change. Because you'll lost the time elsewhere
- however long you think it'll take, double it (this isn't one that I use because it cannot stand up to close scrutiny, but it may help you starting out)
- if a single task takes longer than a week, you haven't defined it well enough. The reason for this is simply that if you have a 20-day task its near impossible to say with any certainty that you're 75% complete.
Depending on how important it is that you fit in with existing standards, you should add tasks (for other people) to review things like documentation, test plans and of course code. And you should add tasks (for yourself) to refactor your documentation/plans/code following these reviews.
If there are certain aspects of the project that you simply cannot do, or cannot do within a reasonable timeframe, or need training to do, say so.
Do not budget to work evenings or weekends. If you do this, and you slip, then you have no hope of making up the lost time. It may be that you feel the need to put in these extra hours, but you should use them to play catchup. Keep them up your sleeve, as it were.
Make sure your boss knows about this new plan, and is aware that delivery will take x weeks/months longer. If they want it more quickly, its up to them to either sort more resource or to descope parts of the project. This is important because if you don't communicate these things to your boss, they will be expecting you to deliver things when you're nowhere near ready.
Lastly, keep on top of your plan. If you are starting to slip, make sure you are the first to know. Now, whether you say anything to anyone or keep it to yourself will have to be a judgement call. If you're confident you can get the time back, then there's probably no point saying anything.
Bottom line is this: don't let yourself be stitched up. If you find yourself missing deadlines, your only defence will be if you can say, "Look, I highlighted this as a risk x months ago."