I recently completed a project where I was the sole IC on the project. The project mainly involved migrating logic from a legacy service but involved integrating with a service managed by another team. I was responsible for the design of solution, estimating a timeline and delivery of the project (writing the code and testing).
Unfortunately, I ran into errors last minute and had to communicate delays a day before the expected completion date. We also ran into a tricky error post launch but I failed to communicate an expected deadline after the cause of the bug was identified. My manager and I have spoken on potential strategies and the need to communicate expected completion time.
My question here: What can I do a better in the future? When driving a project, how are you structuring your work so errors are surfaced as early as possible? How are you communicating risks and concerns that come up during a project?
It's impossible to completely avoid last minutes errors for every project: we often don't see bottlenecks, bugs, and/or errors until we're knees deep into implementation. This is a reality that every lead/owner ends up having to eventually accept, but we should always analyze the nature of how the error came about to avoid similar issues for the next project. For your particular scenario, the breakdown of questions I'd have would be:
Without being directly involved in your project, I can't give as nuanced of a response as I'd like. But I do hope this feedback helps give you a clearer sense of how to proactively and reactively respond to issues when they come up.