A couple of questions around how you run your business model:
Do you supply only runtime? Or full system only lacking admin rights?
Do you have any concern regarding "unlicensed copying or distribution"? Or is it so unique that it is not a concern?
Do you sell the solution or upgrade, or do you charge by the hour?
Items like these may change the approach you take with the customer.
Once you give an admin account, you may lose the client. There are some safeguards you can use for this, depending on what you feel comfortable doing.
1. Charge a fee for the admin right
2. Give them the account in a sealed envelope...and if the seal is broken, any ongoing liability to you is also broken.
3. Keep a copy of the original deployment and run a comparison DDR if there is a problem in the future (did they log in a break something?).
4. many many other ways...primarily based on the style of your relationship to the customer, and the style you want your business to project. You can be a hard line, to the letter provider...or an easy guy to work with and accept the risks that go with it. Most I've worked with/for are pretty easy...but not all.
Eric has given you some good advice. No, it's not common to give up admin access, for two primary reasons:
- Solution source control / quality / liability
- Intellectual property
The first is probably more important. If you surrender full access, you can no longer guarantee that the solution will perform as you built it. The customer can make what seems to be a minor change and totally blow some key functionality. And it can be really hard to recover from, depending on what they do. (Like, say ... delete a field?)
The second matters if you plan to resell the solution, or you have proprietary programming methods you don't want copied. Less of a concern, usually, especially if you're being paid hourly.
Now, that said, the customer has a legitimate concern, and it's a big one: What happens if you get hit by a bus? They're completely frozen, unless you have a backup plan. Eric's listed some excellent compensatory measures. I would suggest you develop a relationship with a local developer who can back you up if something happens. They keystore method also works well (the physical or electronic repository for the system credentials that the customer can get at if something happens to you).
Food for thought.
I could give an admin password to another FileMaker developer, but when a client asks for the admin password it has usually been because they don't like having any passwords or any operations not under their control. Clients in this situation can muck up a perfectly good FM application without any understanding that they have deleted a table or done similar damage. On my hourly rate it is very expensive to fix the application even if I have a backup copy available in my saved files. I do "work for hire" and the database is the clients, BUT
After warning the "owner" that they should not have the admin password, even warning them that they do not know enough about FileMaker to do anything they cannot already do without harming the application, save a copy of the FileMaker application in its current form for me on my media, I will give the admin password, and get ready to head out the door. Clients who cannot be convinced that they need user passwords with various sets of access, and don't know enough to use the admin password without supervision are not worth keeping. I try to get their balances due to me paid, but I have abandoned some balances due me just to get out of the way of an owner. Once I learned that another employee, mostly used to MS Word and Excel, was going to "learn FileMaker and take care of the application." Another time the owner had just done real damage with the limited rights they did have. If they don't want to take my advice, I am not the developer for them.
So sorry for not responding to your replies - life took me away from here for a few weeks...
Thanks to you all for your valuable input. I know a few local developers so I'm going to see if we can come up with an arrangement whereby they provide backup support should the circumstance arise that I'm no longer able to develop the system.
This is my first step into commercial development and it turns out there's a heck of a lot to learn aside from the development!!!
Thanks again for your support.
Good luck with your first foray!
If it holds true for this step as it does with so many others...the first time is the hardest.
Building a dbase is one thing. Running a business is something entirely different. You are trying to do both...don't be afraid to keep asking what others who already do it as a (successful) business think.
It's certainly a steep learning curve and there are many things that I know I need to get much better at (planning, mainly!) but it's an exciting time.
And, yes, I'll be sure to ask plenty of questions!