Web development - issues to consider

When choosing a web designer, here are some brief tips on ensuring the relevant parts of the site remain your property.

Domain ownership

When entering into any web development agreement, you must make sure (in writing) that the domain name you have chosen remains, at all times, your property. This means your name must be on the domain name entry records, and that you have the relevant passwords to control this domain. There are still developers out there who purchase the name on your behalf, and won't put your name on the domain name entry. This can create big problems down the track and is done by developers to 'lock you in' to them, or even to capture part of the value of your business in the case where a domain name itself becomes valuable.

If your web developer won't confirm that your name will go on the domain name entry, or if they suggest they are unwilling to give you the site passwords....choose another developer. It's incredible this unfortunate practice still happens, but it's less rare than you think.

Site ownership

The question of site ownership is slightly difficult to explain, because there are numerous components to a website and your control over them varies. To summarise a very detailed topic, here's a brief list of website components, who should own them, and what they can do with them:

Domain name Customer

See first point on this page. It is critical you maintain 100% ownership of your domain name, have your own name on the domain entry records, and have the domain passwords at all times. Your web developer will need these passwords when developing the site.


Hosting account Customer (preferable)

Some web developers insist on controlling the hosting account. This is reasonable, as long as the charges are not excessive ie. close to what you could buy yourself. In any agreement, ensure that you are will ultimately be free (down the track) to move hosting accounts if your current one no longer meets your needs. Avoid web developers that insist on locking you permanently into their hosting providers, particularly if the charges seem very high. Note carefully if your developer's hosting package charges you for both storage and downloads (page access). Page access fees are incurred when people visit your site, and although it's normal for a hosting provider to limit unreasonable page access/downloads, most sites should never hit this limit. It's preferable to steer clear of any hosting agreement that includes a page access fee as the charges become outside your control: for a busy site, these can rack up fast!

The acid test questions are "will I be able to move my hosting account elsewhere later on if I decide to?" and "what is the total charge for site hosting". If you can't get a 'yes' answer to the first question, and a clear commitment to the second, you'd be advised to choose another web developer. Note that if you do decide to move your site to another hosting provider, it's reasonable for the developer to charge you a modest fee to package up your site contents, and, if you wish, to move it to another hosting account.

Obviously while the site is being developed the developer will manage the hosting component of your site, but after this, you should be able to exert some level of control over the hosting account. Most developers will work with just a few hosting providers, and will recommend one to you. This is reasonable, as is charging for the time involved in setting up and managing the hosting account during the development process. Many web developers receive a 'kickback' from the hosting provider: again this is reasonable as long as the overall cost to you is not excessive. When your site is complete, ensure you have access (ie. the relevant user names and passwords) to your hosting account.

The three main user names and passwords you should have at all times are:

  1. Domain name ie. your xxx.com.au user name and password. This lets you control the actual domain name itself, and is used most often to 'point' your domain to the nameservers of the hosting provider you choose.
  2. Site administrator. This user name and password lets you modify the actual site itself, if you're using content management system or online shopping carts. You use this name and password to modify the content of your site.
  3. Control panel. Hosting providers allow access to your site to control it, check error logs and set up and utilise mail accounts. Good web developers allow you to access these things, although bear in mind, you can destroy your site by making inappropriate changes here! If this is the case, you can expect to be charged to get it fixed.

You should be very cautious of web developers who don't want to provide you with these passwords - to the point of avoidance. In the case of the first one (domain name), it's unacceptable for you to not have access to these. Choose another web developer if they won't agree to provide you with these. If your web developer is cagey about giving you the user names and passwords to the other two, use caution - you're likely to be 'locked in' to this developer, ensuring you are stuck paying them for any changes you want to make, no matter how small. If you move to a different web developer, it's strongly advisable to change all three passwords as soon as possible. Keep them in a safe, accessible place - getting them back once they're lost is do-able, but can be very difficult, and often expensive too.


Site content Customer

Ownership of the site contents ie. the pages, the words and the imagery should remain yours as the customer. In effect, this means that the web developer is not entitled to re-use content developed for you that relates to your business and products in other sites unless you agree. Generic sections on payment terms and privacy are often re-used across sites, so these aspects of content may be reasonably re-used by your developer. Ownership of site contents should be covered in the written agreement with your web developer - but see the next section on what's reasonable for the developer to keep and re-use.


'Look and feel' Customer and developer

In general terms, the 'look and feel' of your site should ultimately be your property (this is what you're paying for!), however it is reasonable for a web developer to re-use stylistic or technical components of your website elswhere, as long as your branding is not misused. Note that where generic, or freely-provided templates have been used, your web developer does not own them to begin with, and neither do you. Consequently, neither party can exert any control on where these templates (including the 'look and feel') are used elsewhere on the web. If you are adamant about having a very specific, customised look and feel for your site and you want to ensure the look is not replicated elswhere, you should invest in a custom template. This is likely to be very expensive - and its cost to develop may easily outstrip the cost of the site when freely available templates are used.


Software Developer/original owner Unless you are having a site custom-coded from scratch (very unusual), the code behind your site does not become yours just because you use it. If your site is built using open-sourced software, the ownership of this software is unchanged by your agreement with your developer as it is not theirs or yours to transfer. The same situation applies when commercial, licensed software is used.
Any customised coding done for your site usually remains the property of the developer, unless you strike a specific agreement to take ownership of this as well. This means the developer can re-use code developed for your site elsewhere. While in the overwhelming majority of cases this is acceptable, if you have had some very specific functionality designed for you, you may wish to prevent its use in any other site. In this case you should customise your agreement with your web developer to reflect this fact. Custom functionality is likely to add (often significantly) to the cost of a site. For this work, you should insist on a time-based quotation, and ensure it's easily separated from other charges so you can make a decision on how much you really need the customisation.

Taking payments on your website

If you're website sells products and makes payment facilities available on the site, you have to choose a payment system. Credit cards are the preferable way to take payment, and you should avoid cheques altogether unless you can ensure clearance before dispatch of your product. Another option is to provide for direct funds transfer into your banking account, though this is not recommended as your site is likely to become a target for identity fraud. Paypal and e-way are third party payment providers that charge a percentage fee to process credit card payments. In return, you get a fairly hassle-free, easy to set up payment system. The alternative to these third party payment systems is for you to use your own banking facilities via a merchant account. For low-volume sales, the costs are roughly equal (although setting up your own merchant account is a cost you need to factor in). For high-volume sales, a merchant account is definitely cheaper, and allows you negotiate a charge with your bank. Paypal scams are rife and you are advised to do your research before committing to this payment system - their usual position is to take the customer's side in any dispute, and disputes can, in certain circumstances, lock your account leaving you unable to access your money! For high-value items, we strongly advise against using Paypal - your funds (and products) are at significant risk of fraud and exchange rates are usually very poor. When fraud occurs (and it will at some point) you are likely to wear the cost. In summary, it is our strong opinion that a merchant account through your bank is the preferred way to implement payments on your site.

Taking payments on your website necessarily involves the purchase and full use of an 'SSL certificate'. These certificates encrypt transactions (so no-one can snoop on credit card details while payments are made), and provide modest certification that the site is who it says it is. Banking rules now insist that no credit card information is ever stored on your site's databases - you should make yourself aware of the various security requirements banks now require for sites that take payments. In general, you are not authorised to make payments or adjustments independently of the customer, and must contact them directly before making any adjustment to their accounts. You should not record any of their credit card details - these must come directly from the customer, at the time the transaction is made. SSL certificates come in a few types: while the functionality is exactly the same, some provide 'enhanced' identification of your site. In general, the more expensive certificates do not represent better value for money, and as long as your certificate is provided by an established provider, the 'basic' ones should do fine. Note that installation of your certificate will be done by your web developer in conjunction with the hosting company and requires great care - simple mistakes can mean wasted certificates, and at over $100 each (approximately), they're expensive!


For Australian sites, Australia Post is the most-used provider of shipping services, and most site software packages can easily include postage calculation for this medium. You are very strongly advised to use only fully-registered post. Despite the additional expense, it affords you numerous protections from fraud (though no system is fail-safe). Using unregistered mail is an invitation to be scammed and you are effectively left without any protection if a dispute arises as you have no proof goods were ever sent! The best solution is to use registered mail that requires a consignment number and signature on receipt. You should only allow purchases from people in countries you 'trust', and should specifically exclude most third-world countries and places like Russia from buying direct from your site due to the high rates of scams emanating from these places. If you don't expect many customers from the US, it's probably better exclude this country as well as the number of scams emanating from the US is high. A simple solution to accept sales from the US (and other countries you have excluded from direct purchase) is to advise these shoppers to contact you directly to arrange purchase.