Probably the thing to do is to start thinking like an IT department. Yes, really. The idea is to avoid the risk of breaking something in production and not knowing why. Suppose for instance that you started hacking a new feature into the live, production application and something broke. Now the application is down and the customer is breathing down your neck to get it fixed. That would be a stupid way to proceed, right? So don't do that.
It's hard to imagine exactly what the environment is like, but you say "no technical support or management." So there's a web application running on a server, and that's it? Is there a test system, deployment procedures, source control, etc.? I'll assume not.
Given that, here are some ideas for how to proceed.
Get Read-Only Access, or Snapshot the Production System
Get access to the production system so that you can poke around to see how things work. Be very careful not to modify anything. If necessary, see if you can get a snapshot of the system (say, a filesystem backup), and restore it elsewhere. That way you can poke around without fear of accidentally fat-fingering a command and breaking something.
If the source code and configuration files for the system aren't in some kind of source control system, create one and start using it. Even if you're the only one working on the system, this will help you track your changes, and if something breaks, you can roll back to the previous version.
Backups and Restores
Is the production system backed up? If it isn't start doing it. Obviously, don't try a restore to the production system. But do try a full restore to an empty system to see if you can recreate a replica of the production system.
Now you should have a system that's effectively a mirror of the production system. (Notice that I've started to use terminology like "production system" and "test system".) You can now tinker with the test system without fear of breaking the actual running application. Depending on how big a project this is, you could do development and testing on the same system. Or you might want to separate them. You might even consider a separate staging system between test and production.
(Search for "developmestuction" on thedailywtf.com if you want to read horror stories about mismanaged production environments.)
Analysis, Documentation, Development
Now that you have a test system, you can study it and write up some documentation for how it works. The goal isn't necessarily to document the whole system, but to generate enough information for yourself so that you can implement the new feature. You can also tinker with things to see how they work (or not) which will assist with the analysis and development of the new feature.
Now that you have a test system, perhaps with some new features added, how are you going to test the system? You need to make sure all the existing stuff works as well as the new features. Generate test data and automated tests if possible. If tests are manual, make sure you have a full set of actions scripted to test all the functions, e.g. create record, modify it, print a report, delete, etc.
Now that you have all your code under source control, how do you put it into production? This also could be fully automated or a scripted set of manual actions, such as:
- shut down application server
- rsync files from staging to production
- restart application server
- smoke test (connect to web page to see if it works!)
Make sure you write down the rsync command or put it in a script or something. Getting it wrong could cause a catastrophe!
This might seem like overkill. Maybe it is. It depends on how big and how critical this system is. It can certainly be scaled down to be simpler if the risks aren't that big. But I can't overemphasize the need to think about testing and development separately from production. I've heard some amazing war stories about how somebody was tinkering with the production system and caused days of outages costing millions of dollars. I also can't overemphasize the importance of source control and deployment rigor. There are many other war stories of how somebody got something "working" on the production system, and the change never made it back into the source control system. The next time they deployed, the change was undone, things broke, and nobody could figure out why.
Anyway, good luck with this!
EDIT: clarified the first paragraph so that it's clear that it's talking about making changes directly to the production system.