> I accepted this contract because I like the country, the CEO and want to push myself to a first experience software lead. I suspect that you are young. Only

> I accepted this contract because I like the country, the CEO and want to push myself to a first experience software lead. I suspect that you are young. Only a young/naive person would take a job on these points. From my perspective from a 40+yo (with 20+ years exp), this is very foolish. > They are struggling with a project and the deadline is close. You should really tell us the backstory. Unwittingly, you have made yourself the fall-guy. Now your "boss" can surely put the blame on YOU when this goes south. > They are seriously lacking on this aspect: no test, a single staging dev server (no local dev env), no doc, inconsistent function and variable naming, the list goes on. I hate to use the word incompetent. But lets call a spade a spade shall we? In the little to no time you have, you cannot expect to work miracles overnight. Especially when you are so new to being a software lead. Talk to the wrong person, in the wrong way and it's all over. Depending on where you are going. Losing face is quite serious in some places of the world. What happens if you get into a situation where they cannot say no. So instead they say, not now or maybe it isn't the right time to implement X. Now you've stalled and the project fails. Honestly, my advice would be to walk back this situation as best as you can. You want your first project lead to be a simple project that can be controlled and taken from conception to shipping with the least amount of issues. Not this baptism of fire, which you WILL get burned. There are so many variables in play that you won't be able to control ANY of them! > How would you handle this situation ? Very simple. Talk to whomever gave you this assignment and tell them you have thought about it/taken outside council and it was foolish of you to accept. Let the project fail. Let it fail very hard. Let the project owner bask in it's failure. Only when you are asked to rescue the project, then you can submit a document detailing how it could be rescued. How long it may take to do so, the budget, the team members you need, etc, etc. You make it clear that it's only an estimate since you have not seen the codebase. Then and only when you get the codebase and do a thorough examination of it, then you submit a revised proposal. If you are successful in a bid to rescue it. Once you have control of the project you can implement your dream wish list, etc. If you are unsuccessful in getting the project. Well, let it burn. It's not your head on the chopping block. Move on, that project lead will come some day.