Welcome to the world of micro-management.
The place where the boss lose money, and the technicians made coffee for others
Most of the agile development techniques that you have learned up to now, in this moment become non-applicable. The main problem is that in the absence of a development team, what remains is perhaps "extreme programming". My advice is to make it clear to the company (no matter the size of this one), this situation is sustainable only if the software is developed to an amateur level. This has nothing to do with your role, you can continue to develop by applying all the techniques you know, but only at the level of software design and development. Continue, perhaps, to develop using TDD, drawing use cases in UML, etc.. But a product, it needs more members to be developed, debugged, tuned, deployed, advertised...
Do not forget that the development of a product, must pass through a strong criticism, survive this, and then have its path of continuous integration. as programmers, we do not digest well the criticism of others and we often need a brilliant idea from others, BUT when they are not there, we become omnipotent and all the errors becomes ours.
I believe that the boss (as defined), has a rejection to the explanation of a technical, these normally lead to the need to spend money, and in a company where there is not a defined budget for the technical department, this can generate conflicts between administrators and technical.
My advice is to invest in training managers, without giving much explanation and even in small projects, organize your work ready to welcome new members in the development team.
- Always use repositories, maybe a nice project on github, with your code organized as Super Project
- Spend your time in at least define what are the milestones of the requests that are made to you;
- Organize your milestone in simple online spreadsheets, now you do not need great project managers, Gantt diagrams, resource control, money flows, etc.
- Always communicate the progress of your work via e-mail, and attach the status of your milestone in PDF;
I think the method that you choose today, must show what you do, and how much time do you spend on.
if you show to a Boss, 10 milestone, 3 of these were writing code, and the other divided between, debug, design, install, test, at that moment you have a great tool for dialogue with the administration...
at that time, you speak their language.