You have a good start toward "specifying" what you want to do (the additional information helps a lot!), and I know you spent some time on that reply, so I will try to see if I can help at least point you in the right direction.
This part is "getting there"... so the first step is to "sell" them an "intangible" - probably "access" to the "wizard" you are going to build (user/password)- or, alternatively, a "template" package (which will have to contain a user/password to get to the "protected" area of the site where your "wizard" lives) To do this you will need:
1) A payment gateway to collect your money - will have to allow the sale of "intangibles" (special considerations there - as not all payment processors will allow that!)
2) A delivery mechanism (email? protected download link - for a template? access to your protected "wizard"?, etc) so you can "deliver" what they bought.
Got it! This becomes a bit redundant if you "sell" the " "access" to the wizard - at it's simplest, you could "deliver" the user/pass combination to an apache authentication (.htaccess) protected area so they can reach your "wizard" - At it's more "complex" level, you may elect to build a full user management system where users could maintain , "accounts" - considerably more complicated, and maybe not necessary for what you are trying to accomplish. The degree of difficulty/cost involved here depends on how "automated" you want this to be. - Your programmer can explain more fully.
Ok. Probably the easiest way to do this is to provide the graphics as files, accompanied by a "readme" or other implementation instructions, that are downloadable from a link, or emailed, to the customer when they have completed the customization wizard (so you know "which" files they need.
Ok. Since you will be learning something new to work on this, you can pick whatever you want. I think the project is well suited for either perl or PHP. Most find that PHP is easier to work with than perl, and it works vey well in conjunction with MySQL databases - so that is my recommendation. Also the site you used as a reference is done in php, and there are lots of php code snippets and classes out there to make your/your programmers' work easier. PHP has good mechanisms for "passing form variables back to itself" (your programmer will understand), making it arguably easier to process your "wizard" inputs. You will have a lot more success finding "affordable" PHP programmers than you will perl programmers - there are several developers on this forum that can surely tackle this.
Building on what we have discussed above, now you have a set of programming parameters to code this functionality into the needed PHP script(s). They will have to :
1) collect the inputs,
2) build and display "preview" pages, (this can include "secondary" templates)
3) repeat as necessary till client is happy with preview,
4) then display (or package for download) the code and/or graphics.
I suspect that the sucess of this project will depend greatly upon how well it is implemented, as well as the quallity of the "template"/ "graphics" as it will have to compete with several "free" offerings that are out there. You might want to consider using a "subscription" model vs a "template purchase" model because of this - but I digress - it's your business model
1) Setup your payment system *
2) Setup your access method - easiest/cheapest is apache authentication via .htaccess - it might be reasonable to investigate existing PHP code for managing this.
3) Gather, prep, and organize your assets - code snippets, graphics, etc. - these will need to be available (at least one full "set" at first) for you/your programmer to use when "assembling" the "pages" from the "wizard" script in the next step.
4) Prepare your "wizard" form(s) for collecting your customers' inputs - work with your programmer on determing what these need to include, as it will becopme important in next step.
5) Code the php script(s) needed to collect the appropriate form data, validate it, gather the assets, generate the code, assemble into a "preview" page for display, branch to editing the input values till statisfied, when satisfied, package the resultant code/graphics/instruction for delivery via screen display (links for graphics), email, or downloadable archive.
6) Put the whole thing "online" and get rich!
- This can be the first or the last step, as long as all the other steps are completed with the target payment gateway in mind!
I hope this discussion has been of some help to you, though I understand it might be discouraging. If you plan thoroughly, working out the processes and methodologies you are going to use before you start "building" it, you can break the project into smaller pieces and work on it a piece at a time - it helps to keep it from becoming so overwhelming. Also understand that another developer might approach this differently; this is just an overview as to how I would approach it (and points out things that will have to be addressed whatever approach is taken). YMMV!