Normally the important part is things work on their target environment. So whatever approach you take does not matter as long as things will work.
If I am thrown into a new project, I start to do a few things if they are not available.
a) set up git and port the source code to my local git repository. This allows me to work in a version controlled environment that does not require me to show my intermediate work and experiments.
b) build it and make sure things do work.
c) create a test harness even if it is just to prove the welcome page works, I can add onto it as time goes by.
d) set up a coverage report to visually how the test cases flow through the app without stepping through a debugger (if you're lucky your language supports this, most of my projects are Java based so I have these tooling available)
Provide estimates. Don't say ASAP, always give a proper time, but not optimistic estimate. I tend to pad my estimates otherwise if something goes awry I would be accountable for them. I try to estimate based on a Jr. developer who is thrown into a project multiplied by two. However, if I do finish things sooner I let them know so the plans can change accordingly. If they want things sooner, still be firm and tell them that those are reasonable estimates given your analysis. They can choose to either accept them, try to allocate more resources (ideally) or kick you out (which is better than being burnt out)
Should your team grow, let other people know how you're doing things, there's no need to document every little thing, but be there to offer. Documenting everything you know will burn you out. As far as documenting things in detail go, I do make detailed install guides to get new developers up and running. However, that document ownership gets passed to the new developer for updates and refinements as things go.