I was actually once involved in working on a web app, which we eventually almost ended up marketing as a standard "desktop application". For some reason, Marketing got it into their heads that one of our major clients wanted the product to "appear to be a GUI application", so we created a little Windows app that just hosts the IE ActiveX control, and points to our web app (hiding the fact that it's actually a browser). So effectively, to an untrained eye it looked like the product was a standard GUI app.
Granted, this isn't exactly what you're asking (we were still pointing at a web app, and not hosting the whole thing locally) - but it's close enough. It would have been trivial - minus some of the remote web services it used - to set this up to just have the whole thing sitting on the local machine.
Here was the biggest problem though: look and feel. Especially feel.
People expect certain behaviours from rich GUI apps (drag and drop, native-feeling windows and dialogs, etc). It is extremely hard to get a genuinely native look and feel from a web frontend. There is simply a different user flow in what is expected when you open up a web app in a browser (eg. Gmail), as opposed to when you use a rich GUI application (eg. Outlook). In my experience, trying to equate the two is asking for trouble. If you put out a "GUI app" which acts like a web app, you're likely to be flooded with usability and LAF complaints.
TL;DR - Web apps and GUI apps have different looks and feels, and a different user culture to some extent. While it's technically possible to do something like this, from my experience, I wouldn't go there (again). At best you're likely to end up with a horrendous mix of client-side scripting that will be more difficult to learn, use and maintain than doing the whole thing as a normal GUI app in the first place. And people WILL complain about things "not quite feeling right" for a native GUI app. It's tempting to think that they won't - but they will.
This is almost impossible to get an accurate cost on. Outsourcing makes this even more difficult.
Just because it's fairly standard doesn't make the task of quoting any easier. For example: you mentioned there is an Administration Interface. This can be as simple as a login and password for each user or complex with users who have multiple roles and a superuser that can oversee all admin tasks. If this becomes a role based admin then the coding time has just increased exponentially.
If you are outsourcing to a foreign country I'd pad the total time and cost by 20% to account for interpretation of questions and answers between customer and coder.
As a ballpark for database driven admins we would estimate 4 hours for each base table. This allowed for table creation, insert routines, update routines, delete routines and the associated admin web pages. This also included a simple listing display page and a detail display page. If search filter queries were required then we'd add 2 more hours for that table.
We did have a lot of code we could borrow from. We also wrote some utility stored procs that helped us speed up the coding by spitting out source code. It wasn't perfect code but it saved us many hours of raw coding. We also would undercut the price if this was a widget we could turn around and resell to other clients. It doesn't sound like you can resell this to anyone else so the price they pay should be a premium.
Is there a similar Commercial Off The Shelf (COTS) system already built that you can buy?
Have you even entertained the Build or Buy question?
Custom software is expensive. As long as you make the customer aware of this fact up front and they still want a custom solution, they will pay the premium price. Every time you say, "Oh yeah, we can do that" and don't say it will cost more, the customer will expect it for free.
Best Answer
It is extremely difficult to provide any sort of flat "responsive design support" fee, percentage, or even algorithm, because in practice the devil is very much in the details.
The problem is (and what you absolutely must define in writing), what constitutes a "supported device"? By the gods, do not permit "mobile devices" and leave it at that. My first foray into that world was a trip to the school of hard knocks, and I'm endlessly grateful I wasn't on an hourly, contract, or time pressure.
The thing to know is you must treat each device and operating system version very much like you would an additional browser. As you are use to supporting multiple browsers, I'm sure you are familiar how much work can go into something as simple as "also, I want this to support Internet Explorer 7"; this can be easy, or it can be an amazing head ache depending on what technologies you are using.
Be aware that to many clients it's just another buzz word they don't fully understand. Maybe they just want their website/application to work on an iPad and iPhone/Android smart phone (last 2 versions of each with stock browsers), and that's it. Well, now you have at least 8 different new configurations to test, and in my experience even the newest/best tools from the top design softwares are unable to accurately tell you what's going to happen beyond a static HTML/CSS design; add in javascript and advanced features of any kind and all bets are off.
What about Windows RT and Surface? How about older Androids, or the first/2nd generation iPad? iPod touch? What tablet sizes and models must be supported? Will you need to test Firefox and Dolphin and Opera for mobile devices?
In practice, I quickly found (rather to my surprise) that using HTML/CSS/javascript/jQuery/SVG (uh oh) even in very basic ways generated a plethora of problems across devices. An app might look and work perfectly on Windows and Macintosh desktops of a dozen different screen resolutions and windows sizes, on Firefox, Safari, IE 7-9, and Opera, and you know how that can be. Then I found iPad didn't like a certain feature and wouldn't work, Windows RT exhibited bugs only otherwise encountered on IE <= 6 but when 'fixed' would randomly exhibit unreliable behaviors, and managed to completely crash all browsers on Android 2.2 and 2.3 but worked fine on newer devices.
Meanwhile, W3C validators and Adobe Browser Lab tools all reported no expected problems.
Bottom Line Advice
A multiple of 1.5-3X, depending on amount and age of devices supported, is not unreasonable. The only way to get better is to do it and get your hands on as many actual devices as you can manage and test, test, test. Its the new version of 1990s browser wars where the rules are made up and the points don't matter, you'll inevitably have to get dirty and spend whole days trying to fix one stupid thing that should work and works in 20 other platform tests but not on this one particular thing....
So define your terms, limit the officially supported devices (and specify models!), browsers, and configuration, and be prepared to feel like a bug-hunting noob. You an do it, just be prepared to spend significant amounts of extra time, avoid taking more than one job at a time to start with, and give yourself some intelligent leeway to avoid looking bad.
I'm personally a big fan of picking the most important configuration and delivering that, then locking down the other configurations on a staggered timetable. If it's all or nothing without incremental delivery you are asking for an unhappy client.
Most of all: good luck!