In the previous post in this series, we talked about defining requirements (or a statement of work) and why it matters to have this.

Before we get into actually understanding – and writing – object-oriented code, there’s one more “business-related” topic to discuss: Terms and Conditions.

For many, it’s a bit of a dry topic, but if you’re looking to build solutions for someone else, do so from the ground-up, and do so properly, then it’s important to make sure you have all of the necessary pieces in place before doing so.

And once you’ve:

It’s time to make sure you have the terms under which you’re working.

[restrict paid=”true”]

Defining Terms and Conditions

First, I think it’s important to understand the purpose of terms and conditions (or, more simply, a “terms”) document.

According to Wikipedia, terms are defined as:

A contractual term is “Any provision forming part of a contract”. Each term gives rise to a contractual obligation, breach of which can give rise to litigation. Not all terms are stated expressly and some terms carry less legal gravity as they are peripheral to the objectives of the contract.

Is that too formal? Maybe. I think it does a good job of explaining it, at least in a general sense, but if I were to define it on my own, I would go about it a little differently.

In short, I’d try to keep it as simple as possible. Perhaps something like this:

Terms and Conditions defined the rules and the guidelines of agreement between at least two parties in a business relationship.

But what should they contain?

What’s in a Terms and Conditions Document?

This question is a bit subjective because it’s largely dependent on the size of the solution, the size of the businesses involved, and the nature of what’s being built.

Generally speaking, though, I normally make sure the following topics are covered:

  1. Pricing and Payments define how the pricing and payment structure is going to work.
  2. Estimates refer to how the service provider, namely you or you and your team, provide estimates, what’s required for them, and how they differ from actual payments.
  3. Approvals are for the benefit of both the provider and the client, so they know when a given feature (or the entire project) has been completed.
  4. Authorization simply defines the agreement between the two parties for invoicing and the remainder of the content of the document.
  5. Projection Completion and Delivery Dates set the expectations for the timeline of the project. I include that it does not include holidays, “external forces beyond our control” or negligence on the client’s behalf to return communications.
  6. Cancellation explains how the resources created, used, generated, and shared among parties are to be maintained or owned if the project is canceled.
  7. Copyright Responsibility is meant to ensure that any intellectual property provided by the client has obtained the proper copyright and that you or your team can’t be held responsible otherwise.
  8. Intellectual Property can be used to explain how the ownership of artwork and other assets created during the project is maintained once the project is completed. Sometimes, a given firm will be responsible for maintaining ownership of the assets; other times, the client can maintain ownership of the entire project.
  9. Modifications explain how change requests will work and be charged.
  10. Limitation of Liability simply explains the level of responsibility you or your team maintain for damages or profit losses once the project is released.
  11. Promotional Use defines whether or not you or your team can use the work in the promotional material when talking with other clients.
  12. Client Responsibilities outlines what the client is responsible for providing for the project. This may be all up front, per milestone, or on whatever schedule you may agree.
  13. Legal Fees defines who will be responsible for what when it comes to attorney fees should they need to be presented.

I’ve tried to give a short synopsis of what’s above. It’s easy to search the web for templates off of which to work, but I highly recommend having a lawyer look over your document before using it in any legal situation.

Tools for Terms and Conditions

When it comes to learning about running a business and getting into object-oriented programming, this can be some of the driest material possible.

But it’s necessary if you’re looking to run a successful business because work is more than just writing code for someone else.

Although I can’t provide terms and conditions for each freelancer or agency, I can still provide a couple of places to read more about them and to setup e-signatures to make it as easy as possible to get started.

Object-Oriented Programming in WordPress: Terms and Conditions

Case in point, I use the following:

  • Google Docs for drafting the Terms and Conditions and updating them on a per-project basis.
  • Eversign for setting up electronic signatures.

And that’s it! Perhaps the most complicated part is getting started with drafting the terms and conditions.

From this point forward, we’re going to begin diving into code and talking about the various aspects of object-oriented programming then how to apply them in the context of WordPress.

[/restrict]