There's something that we've run across in our years in this business and it's something anyone looking to do a website design project should be aware of. If you're not careful to ask your website developer about this issue, you could be in for a real surprise later on. We still see this happening (which is surprising).
In a nutshell, find out how your custom web project will be developed. Make sure that your developer (web designer/programmer) is not using any kind of proprietary system, server or code. If this is the case, then you could essentially be handcuffed to them for life.
With a website project, there is a usual path that is taken. Us (Webstix), or any other website developer, will most likely sit down, have a meeting (in person or over the phone) and find out what the requirements are for the project. We want to find out what you need. You may know a lot about what you need or just have ideas. Very rarely do we get things all sketched out (if you do take the time to do that, you can save quite a bit of money, by the way and easily shop your project around) so if it's not sketched out, we sometimes include time to do that - more about this in a minute. And sometimes, people just want a basic website that is pretty standard... no big surprises. These projects may have custom design but you're not talking about some kind of custom website project (application, etc.).
With the standard projects, we'll go through our design process, then do coding on a staging server, put in content, do testing and then launch. Maybe there's a form or a simple shopping cart. That's fine.
For other projects, we get clients that want their shopping cart to work a certain way or have special forms. Maybe it's because their products are different or they ship in a special way or something like that. This happens. It's not wrong at all and we're happy to work on these projects. The difference here is that there's typically not some pre-made software or plugin that can be taken off the shelf and used to do what they want (sometimes there is but not usually). When that happens, a standard project then turns into something custom - it needs to be created. This is the kind of project we're going to focus on as I write this article.
When there is a custom website project, a number of things needs to happen. First, we'll do storyboards - which are essentially the blueprints. Nothing works yet but we can go from screen to screen showing what will happen. In this phase, it's easy to move things around, add more things and so on. We now have all the requirements and we know what we have to build.
Next, what any website developer has to do is figure out how to get the work done. How are they going to do it? Sometimes you pick a programming language and sometimes you pick a platform like Drupal, Joomla, WordPress, Magento, Dot Net Nuke and so on (those are the platforms we typically use). This way, you're using code that has been tested and is being updated and supported. Why re-invent the wheel?
Here's the important part - you want to make sure that whichever way your developer chooses, that they are not using anything proprietary. No propriety server, codebase, plugin or whatever. If they are, then you are tied to them... forever, essentially. On go the handcuffs!
We just saw this happen again. Someone hired our competition to do some work, which was in Drupal. After a while, this local developer was unresponsive. The project dragged on. It was not getting done. This client wanted us to take it over and finish it. We met with them and it was clear what needed to be done. The problem, we found out, was that this developer had a custom module that they developed. They were not willing to release it.
Because of that, this client is stuck. The current developer won't or can't finish the project. The client sunk money into developing it but the developer won't release the work. For us to do it, we'd have to try to figure out the part that the current developer is holding back and try to recreate it. Also, if the project had been completed, the client would not have been able to ever move their website to another server because the developer would then have to release their proprietary code.
This isn't the first time we've seen this, either. There was another company in Madison making shopping carts and they were all on one server, using the same software. We heard that people's invoice numbers would not be sequential because there was maybe an order at one store and then one at another store (on another website) so that other order would get the next invoice number. Stuff like that.
When that happens, you are not able to leave your website developer or even leave their website hosting (servers). You're completely stuck and tied to them. Most clients we talk to do not want to be in this situation... in fact, we haven't met one yet that does.
This is just like going to a company and asking them to make you a car. They find out what you want and make it. Now, when you need to get it fixed, can you only go to them or could someone else work on it?
We do not use proprietary code. Ever.
You're hiring us to develop a project for you, so as far as we're concerned, you should get that code. We'll never handcuff you to our servers or services. If you want, you can leave us (assuming billing is taken care of, of course) and go to another developer and they will be able to work on the project. You are not stuck when you work with Webstix.
Here's what you should ask them:
Website development can seem pretty complicated if you're not familiar with it or know much about it. We get that. We try to make it as simple to understand as possible. As you get into getting a project done, ask a lot of questions. Make sure you're comfortable with them and how you're being treated. If they act like they're hiding something, maybe they are. If red flags go off in your mind, maybe you should stop and ask more questions.
The worst thing is to get into a project that the developer has no motivation to finish (they ignore your calls and emails) and then find out that you're stuck with them.
Custom web projects are risky. With custom code, you introduce a lot of potential problems. The code might not be tested as well. Support is limited. You might be stuck with a certain server or developer. If upgrades are done, things could break.
Honestly, the projects with less risk are the ones that fall under the "standard project" category. The good thing is that there is more and more tested code out there every day. More and more features that were once considered very custom are now standard and are supported. Don't let this stop your imagination of what your website could be or could do. Dream big and then find out the details of what risks there are by adding on certain features. Get things storyboarded out and make sure they're clear to you. That's what we, as website developers, have to do in order to get work.