So you have dreams of starting your own Pet Site, but have no experience with programming whatsoever, this thread is going to walk through a lot of things that you need to know, and what you need to look for from your developer (and in your code base), to ensure that you are paying for things that really matter.
Please Note: This is not an exhaustive list, this is meant to be a jumping off point to help improve your overall familiarity with the process of developing code.
As a site owner, it is your responsibility to know at least at a cursory glance how it works. Code is complicated but so is owning a site. There are a lot of resources out there which can help you, don't treat coding like a black box because at the end of the day you will be the one out money should the developer decide to cut corners.
Please Note: As an owner, nothing is "above your pay grade", you are defining the pay grade, so you need to be aware of the inner workings!
No live code updates - Yes, cPanel has a code editor built in, or your developer may have an FTP client installed on their computer that they can use to connect to your site, but you should not let them develop through these tools. They are meant for small changes, not developing whole features.
Why is this bad? Your users can see things that they shouldn't have visibility to, and it may make the site seem less stable because they are on one page and they see an error message, or worse, raw code emitted (i.e. SQL statement), now you are giving them too much information!
Nightly Offsite Backups (or more frequently) - servers die, databases get hacked, accidents happen! Having backups of all of your assets are paramount to recovery. If you happen to keep the backup in the same data centre, or even worse, the same server, you could be asking for trouble. If your server dies (it happens from time to time), the backups that you have stored on the same server will have died with the rest of the code. So this is kind of useless. It's great if there is a quick rollback that is necessary unfortunately in situations like that this is typically not the case.
Source Control Everything - So first of all, you are probably wondering what Source Control is, it's a tool that developers are able to use in order to keep track of changes that they do to the codebase, in order to make it easier to work with other developers, as well as be able to revert the code to a point in time when it was actually working (or at least look at it at that point in time). Think of it as "CTRL-Z" on steroids. This one here somewhat goes hand-in-hand with point 1, about no live editing of files because your production environment should be made from either a "release" branch/tag, or your "master" branch in your repository.
Test all code in a Development Sandbox - New code poses the possibility of new bugs (or old bugs rearing their ugly heads again). Because of this, there should be another environment that can be pushed to first prior to production in an attempt to find any bugs early, especially if they are game breaking ones.
All changes to the database should be done via code (SQL scripts or migration scripts) - Now that you are following some of the other best practices, we need a way to ensure that the structure in the development environment matches the production database environment. By scripting it (and running the script when deploy time comes), you are able to fairly confidently say "yes, this will work in production". Yes, you have phpMyAdmin, it's a great tool, just like the other things built into cPanel, but if someone makes a schema change in production that isn't reflected in development, then anything you build from that point on (if they rely on it) could potentially be broken because you manually changed something in production.
So you have a developer that wants to use a framework, should you let them? Probably! First thing's first, what actually is a framework? The regular definition is:
A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed.
Which fits in really well with what application frameworks do. They scaffold out a lot of the best practices and abstract away lots of the things that you really don't need to have a developer make for you. This in turn leaves you with less code they need to write which should mean more money to spend on the things that matter, and better yet, less security flaws! More frameworks handle things (as best they can) such as Cross-Site Scripting/Cross Site Request Forgery (CSRF) and SQL Injection. These are just two of the big security things that you need to be concerned about.
Most frameworks have tutorials out there which range in quality. As a site owner, it is your responsibility to at least know what you are buying a little bit. So I would encourage you to take a bit of time and watch some YouTube videos about it so you can at least familiarize yourself with the nomenclature.
Please Note: Just because your developer said that they wanted to use a framework, this does not mean that you do not have to worry about security. Take the following example, you display a "bank" page which to the human eye all you can see is a "withdraw" and a "deposit" text box with a button. But behind the scenes, hidden in the HTML (hidden input field), the programmer decided to also include the user's bank account ID, and use that for any of the actions. Well, in cases like this, your site has a security hole, and the framework has no way of knowing that isn't actually what you want to happen.
Lots of the frameworks out there are open source. This means that people around the world can look and work on improving the framework! This means that the framework will have new features added, and security releases made. Because of this, it is super important to keep your version of the libraries as up-to-date as possible.
Depending on the language you are using there are a bunch of different frameworks that can be chosen from. We will maintain this list as best as we can, but we will also show you how you can find out the version that you are on, as well as what version the framework is currently on.
Latest Version: 6.x - https://github.com/laravel/framework/releases
Determining your Version: Within the codebase, there should be a file called "composer.json", in there under "require", there should be a line that says, "laravel/framework". On the right of that, you will see the version you are currently on.
Latest Version: 3 (4 - a massive rewrite is in the works, so maybe hold off until this is done?)
Version 3: https://github.com/bcit-ci/CodeIgniter/releases
Version 4: https://github.com/codeigniter4/CodeIgniter4/releases
Determining your Version: https://www.kodingmadesimple.com/2016/08/find-codeigniter-version.html
Latest Version: 4.0 - https://github.com/cakephp/cakephp/releases
Determining your Version: Within the codebase, there should be a file called "composer.json", in there under "require", there should be a line that says, "cakephp/cakephp". On the right of that, you will see the version you are currently on.
Latest Version: 2.0 - https://github.com/yiisoft/yii2/releases
Determining your Version: Within the codebase, there should be a file called "composer.json", in there under "require", there should be a line that says, "yiisoft/yii2". On the right of that, you will see the version you are currently on.
Latest Version: 5.0 - https://github.com/symfony/symfony/releases
Determining your Version: Within the codebase, there should be a file called "composer.json", in there under "require", there should be multiple lines that which start with, "symfony/". On the right of that, you will see the version they are currently on. Because of the nature of this project, they may be on different versions which is fine, however the "major" release should be the same across the board.
Latest Version: 3.0 - https://github.com/django/django/releases
Determining your Version: Within the codebase, there should be a file called "requirements.txt", in there, should be a line that says, "Django". On the right of that, you will see the version you are currently on.
Latest Version: 6.0 - https://github.com/rails/rails/releases
Determining your Version: Within the codebase, there should be a file called "Gemfile", in there, there should be a line that says, "gem 'rails'". On the right of that, you will see the version you are currently on.
If the framework that your developer wants to use isn't listed here, that isn't necessarily a problem, try to get the details about the framework that they are wanting to use, and go from there! It's a great place to start a conversation to make sure you truly are getting what you paid for. The things listed above (especially the latest version) also helps to show how active the project is. If the developer wants to use a framework that hasn't been updated in 3 years, chances are the maintainers of the project have abandoned it, so you probably should too!
I used a framework but I still got SQL Injected!
Similar to my other example above with the bank, just because you are using a framework does not mean you will not be hit by SQL injection! My gut instinct when I hear this is "the programmer is using it wrong". Most frameworks provide wrappers around the database objects, and then behind the scenes use database parameters to actually query the data. What are database parameters? They are a way of passing the data you want to query (normally user's input) in alongside the actual query, preventing evil-doers from doing things that were not intended (i.e. dropping tables). In the past, developers would just build a string and do something like "mysql_real_escape_string" on the data to ensure the safety, it is still possible in modern frameworks to have access to the raw database object and run queries you write yourself. It's these circumstances that tell me the developer is using it wrong, hence my original statement, the developer is using it wrong, and should be stopped.
Please Note: Frameworks are just code, so they do have the potential for bugs which can introduce security issues as well. Take Laravel for example this past summer they found that one small piece of the code was vulnerable to SQL Injection!
My Programmer doesn't want to use _____
A framework - Ask why not, prompt them to give answers and don't just settle for "I'm more comfortable in my own code", or "It'll be faster if I code it from scratch" - frameworks this day in age are pretty darn fast, unless you are using it wrong, http://www.phpbenchmarks.com/en/comparator/framework, they likely won't be your bottleneck in the application, it's the rest of the stuff that goes on. Don't throw away the security of your application just because it's easier for a random developer to do their own thing (that no one else will be able to figure out easily).
Source Control - Ask why not, there are so many tutorials out there nowadays it's pretty easy to learn. If you are ok with not using it, make sure you discuss your safety net, i.e. when you will pay for things (paid on delivery with code clearly available). Source control is only as useful as the developers using it. They should be committing to it regularly, not just when the code is complete. This will help to give you a good sense of the work that went into the project as well!
My personal mantra is, never pay for something that only resides on a development machine. Just like art that is being created, you wouldn't be happy with receiving and paying for a watermarked image. Why are you doing that for code? In your agreement with your programmer, at the bare minimum, state "the code must be stored in this repository".
Please Note: You should be the owner of the repository, not the developer. I have seen so many projects go haywire and owners get screwed out of their money because the code hasn't been delivered. It resides on a developer's machine or their personal servers.
The repository is just like getting access to the raw PSDs for art (which you should be getting as well when you commission art in case you need to edit things later on).