Non-theme based Drupal development?

I run a design firm and have frequent need for Drupal development. I'm looking for a bit of guidance on a Drupal workflow that will work best for my company.

My experience working with Drupal developers in the past has been great for back-end development, and chaotic for front-end development. Projects end up with multiple and inconsistent CSS styles, and doing quality control on the visual aspect is very time-consuming.

Moreover, I'm a front-end coder, and use HMTL/CSS/JS prototypes for all phases of projects. I would prefer if the front-end coding I do to was used by the developer instead of going to waste.

However, this workflow hasn't been compatible with Drupal dev partners so far. Because they use themes, and retro-fit them to the design I give them, they aren't able to use the HTML/CSS/JS work I do. Moreover, I have a responsive framework that I like (Foundation), and my developers want to work with the standard responsive Drupal theme (Omega). I don't like Omega because it isn't fluid.

Then there's things like my developer telling me they can't do a carrousel that uses CSS (background-image), because the available Drupal carrousel modules are all based on using the HTML img tag. Does everything have to be based on modules?

Going back to the HTML/CSS inconsistencies and the time-consuming design QA, I think this comes from trying to retrofit a theme. The code is very messy and it makes it hard to target elements for styling. It also makes it impossible for me to do my own CSS changes if I want.

So, in short, I'm looking for a completely different design workflow, and I'm looking for feedback on whether it's workable in Drupal without inflating costs.

Is it possible in Drupal to use front-end code (provided by me), throw in some PHP tags, and end up with cleanly-coded pages, instead of relying on themes? Would this reduce costs (because the HTML/CSS/JS is provided), or would it inflate costs (because it's easier to use a theme)? Are there any security issues involved? Are there update issues involved? In short, what's the big advantage with working with pre-fab themes?

I really, truly appreciate your comments.

We usually develop from the backend to the front end. Modules like Views add many div tags, classes and tags so the theme developer can make better use of them and fine tune the design.

I do not think that is a "messy" code unless you are doing all of the work in tpl.php files.

Modules simply processed the data. It should not heavily theme the output. For a better understanding, see the image below (from drupal.org):

If you want to do any database intensive work in the template level, you will have to load many stuff again that you could simply do in a module.

In my opinion, if your developer is not hardcoding the HTML stuff, he is doing it right. Keep in mind that you can override most of the theme functions so you already have the flexibility if you want.

Is it possible in Drupal to use front-end code (provided by me), throw in some PHP tags, and end up with cleanly-coded pages, instead of relying on themes?

Yes. But you can't simply use slider-image.php like files for that. You will have to add necessary theme functions to and pass the variables to it. IMO, it's relatively more work if you need to completely rewrite the theming functions.

Would this reduce costs (because the HTML/CSS/JS is provided), or would it inflate costs (because it's easier to use a theme)? I do not think so. If you have multiple backend developers working on code, ask the theming team to make changes to HTML/CSS. CSS can make your site look worse, and a security bug can ruin your business, expose all your user information or even worse.

Are there any security issues involved? Most likely. Default theme functions tend to come with much better security. Even though few bugs come out, they will get fixed soon by the community.

Are there update issues involved? In short, what's the big advantage with working with pre-fab themes?

Because there is a whole lot of work that you can simply adopt. That will also block you from adopting others' CSS work though.