Community Building Works with WordPress

Using WordPress as a Community Building ToolWordPress has played a huge role in my personal and business development. More than a website platform, WordPress is about community building. Last Monday I hosted the monthly OC WordPress MeetUp and on Tuesday I spoke at the WordPress MeetUp Chris Lema hosts in San Diego. Having sponsored the monthly meetup (held the 4th Monday of every month) for over 5 years now and spoken at many WordPress related events over the years, you might think the excitement would have worn off.

However, that is just not true.

Every WordPress MeetUp, every WordCamp, every after party event has resulted in an amazing community building experience. Personally and professionally, I consider the WordPress community integral to the success of my business.

Through the WordPress community, I have made friends. I love networking but in WordPress, community goes beyond the basic business card exchange. I’ve made some terrific friends, like-minded individuals who I can work with to extend ideas and collaborate. Troubleshooting, project pitching, business planning have all naturally evolved from our interactions. Sometimes we even work together on projects!

I find that as I share my knowledge, I discover things I didn’t know.

Steve Zehngut on WordPress Community BuildingI learn from teaching and from joining in conversation. When it comes to community, you get out what you put in. I’ve found that connecting over WordPress works for me so I continue to give my time and speak and WordPress networking evolves naturally. My company Zeek has gained name recognition simply because I show up and host events.

We have three Meetups per month hosted at Zeek Interactive. I host the General WordPress MeetUp Group, Jeffrey Zinn and Brandon Dove host the WordPress Developer Group and Sarah Wefald hosts the WordPress Design Group. All of these events attract quality people who share a passion for WordPress. Our community is ever growing.

Whether you are new to WordPress and just starting out or are a WP veteran speaking at WordCamp, you are welcome in WordPress. We are all a part of the WordPress community.

Networking Creates Lucky Paths

My name is Steve and I have always considered myself good at networking.

I was lucky to inherit that skill from my father who has been an entrepreneur since before I was born. My dad owns LA Art Exchange, a custom picture frame store and art gallery in Santa Monica. He is the picture framer to Hollywood and has many celebrity clients. You don’t get to that position without being able to schmooze with the best of them.

In 1996, the LAMG was holding their annual MacFair in Burbank and they had a spare booth. Because I led the Director Special Interest Group (SIG), the booth was offered to me at no charge to market my wares.

It was a lucky jackpot and one that required some planning.

Kevin and I thought about what we hated about going to trade shows. We both disliked the tedious walking around from booth to booth. And we recognized that after a while, all of the booths become noise at a trade show. So, we decided to create the “Shockwave Lounge.”

Lucky to sit in Steve Zehngut boothWe found a couple of grungy old couches and a coffee table and set up a makeshift living room in our booth. We had coffee and pastries. I set up a computer on the coffee table to show off our portfolio. We would tell passers by that they looked tired from the trade show and would then invite them to sit down and take a load off. Once they did, they would immediately ask what we did. Boom! We had a captive audience. Either Kevin or I would take a few minutes to show off the work we were doing, hoping it would result in more work. While everyone loved our work (and us), we had no solid leads. Needless to say we felt like our lucky FREE booth was being wasted… until the very end of the show.

We were about to shut down for the weekend when a woman walked over. Luckily, I stopped closing up shop and gave her our pitch.

At that moment, I met our first-ever paying client, Lynda Keeler. Lynda was working for an ad agency at the time and happened to be looking for developers to do exactly what we did – Shockwave games. Lynda was working on the website for the movie Multiplicity and had an idea for a mini arcade that would go viral. This was 1996 and she was a visionary.

She met with us the following week and hired us on the spot to create five games for the site. The Multiplicity team had ideas for 4 out of the 5 games and left the 5th one up to us. The games were designed as stress tests. At the end of each game, the test would determine that you are stressed and that you are in need of a clone. The movie was about cloning so that was the tie in.

We developed the first 4 games that were requested and at the end of the project, we were in need of a 5th game. We brainstormed for a while and came up with nothing. At the last moment, one of us blurted out “Punch the Clown!” The game displayed one of those large blow-up pear shaped clown dolls. The user controlled a boxing glove and when you click on the clown, it would punch him and he would rock backwards. He would roll back forward and the game would start again. That was all it was. We cranked the game out in just a few hours to meet our deadline. To us, it was a throw away.

Have I mentioned before that we were lucky?

That game became a huge viral hit!

Punch the Clown with Steve ZehngutPunch the Clown became bigger than the Multiplicity site. It got featured on Macromedia’s site and on several other “site of the day” type websites. We would go into meetings and show that we did the games for the Multiplicity site. Usually, someone would say, “You developed Punch the Clown?” Who knew that a game developed in just a couple hours time would become our identity. Zeek became known as the “Punch the Clown” guys. Go figure.

Succeeding in business takes some hard work and a little luck. But, you can create your own luck. In my case, luck came in the form of being in the right place at the right time on numerous occasions and from trusting my ability to network. If you’ve been down on your luck, know that it is possible to be lucky in business, and keep trying. Who knows, you may have a “Punch the Clown” moment just around the corner.

Lucky in Life, Lucky in Business

Lucky in business with Steve Zehngut and ZeekLuck means different things to different people.

Some are lucky in business.

Others are lucky in love.

And others, like long-distance swimmer Steven Robles are lucky to be alive.

Robles was an hour into his regular Manhattan Beach swim when he was attacked by a shark last week. Robles was pulled to shore, further extending his luck and saving his life. In his own words, Steven said, “I was really lucky. I’ve been given a second chance.”

Being lucky in business can be a similar story. Entrepreneurs have multiple opportunities and second chances. We also have many situations where we may feel attacked by sharks. I know I’ve experienced both feelings.

The moments that stick best though are when I’ve been lucky in business.

Five years ago, Jeff Turner and I founded the OC WordPress Meetup. It was Jeff’s idea to form a referral network of other WordPress developers in the area. We had a good problem – there was more work than we could handle and we didn’t want to leave our clients in the lurch. Starting the Meetup on a solid backbone of giving and sharing created an unbelievably generous WordPress community in Orange County. That’s very lucky in itself, but I had another lucky break early in my career that led to me being here.

The OC WordPress Meetup wasn’t my first rodeo, cowboys.

When we first started Zeek, we were going to be the next great CD-ROM developer. We specialized in Macromedia Director development. To learn how to develop, I began networking with other developers. I attended a SIG (Special Interest Group), held at the Los Angeles Macintosh Group in Santa Monica that was led by Richard John Jenkins, a Director enthusiast. I met Richard and began participating and presenting regularly. Soon, Richard recognized me as a “go to” resource when he had developer questions. Lucky for me, Richard was eventually hired by Macromedia and asked me to lead the group. I happily accepted.

The people at Macromedia recognized the power of user groups early on and put a person in charge of user group support – Suzanne Porta. Suzanne would send us t-shirts, stickers, mugs, and software licenses to give away. Suzanne and I became friends. And it was lucky that we did.

Around 1998, Macromedia was in the process of creating their own original content site, called Shockwave.com (originally Shockrave.com). Suzanne knew Zeek’s reputation for creating games and got us an invite to be one of the first participants. We created a game called Taco Joe and it launched with the site. It was an instant success. We made some money from it and we got many leads from people wanting similar games. We learned what it meant to be lucky in business!

Luck changed our mindset at Zeek and taught us to look for opportunities. We learned, as Steven Robles has, to embrace the lucky breaks and utilize second chances whenever they come our way. That, and, to steer clear of sharks.

Lucky Breaks Impact Business and Life

Lucky Breaks in Life and in BusinessBasketball wonder Josh McRoberts committed to the Miami Heat yesterday. His actual contract resulted in a four-year, $23 million deal. Talk about lucky breaks! McRoberts has talent, boundless energy, an intense ability to train and withstand the stress of the game, and height. The guy stands 6 foot 10 inches. Yet, no matter how good a player he may be, luck still plays a role in the course of his life.

The Miami Heat fell apart this season after a missed three-peat. Lucky for McRoberts, the San Antonio Spurs were hungry for a ring in June. Had that not happened, Lebron, Wade and Bosch may have resigned and McRoberts would still be wearing a Bobcats jersey. Now, however, McRoberts is in the limelight, as the Heat secured his contract hoping the move will keep LeBron James in Miami.

The lucky break still goes back to the Spurs win. Had the Heat won a 3rd ring, this would not even be happening.

Lucky breaks can come to all of us. They may come in the form of a chance meeting or from following a friend’s advice. A lucky break could be a won contract (like McRoberts) or from a coincidence that places you in the right place at the right time.

I’ve had my share of lucky breaks.

In fact, this June marked Zeek’s 19th year in business. It’s been quite a ride and ultimately a success. Thomas Edison is quoted as saying “Success is 10% inspiration and 90% perspiration.” I absolutely believe this though I like to throw a small percentage of luck into that equation.

Steve Zehngut - Zengy - and Lucky BreaksLuck is an interesting concept. I don’t view luck as some magic power or superstition that happens on its own. Zeek doesn’t have a rabbit’s foot that we rub each time we send off a proposal. I do have a horseshoe sitting on my bookshelf, but that is just a part of my collection of poker paraphernalia.

Luck is something that you create. In my opinion, luck is the unexpected alignment of the stars resulting from knocking on doors, asking questions, introducing people, sharing knowledge, attending industry events, and a host of other actions. When you put yourself out there, opportunities present themselves. Stars align and luck follows.

Lucky Breaks Are Noted in the Details

A lucky break can show up as a name. At least it did for me.

19 years ago Kevin, my original business partner, and I decided to start a business. The first task at Zeek was to name the company. Many names were debated and I can’t remember a single one. We knew we wanted something short and catchy, but nothing was sticking. After days of brainstorming, we were exhausted. We ended up just taking the initials of our last names and stuck them together: Z&K. We threw 2 E’s in the middle and “ZeeK” was born. (We used to capitalize the K wherever we wrote it.)

In 1995, almost any domain name was available. For only $35/year at Network Solutions, the name was yours. We bought zeek.com and put the company naming task behind us. Checked it off the list.

Even though “zeek” emerged from exhaustion, it stuck.

Zeek is short and it’s catchy.

It contains a K, also known as a plosive. Any good stand-up comedian will tell you that they select certain words because they contain plosives. Words that contain hard sounds are inherently funny on their own with or without context. This was unintentional, but it works.

Zeek as a lucky breakZeek also rhymes with “geek.” Again, unintentional. I have heard all of the alliterative insults you have in your head right now. Glad you came up with something catchy. Because the truth is that if you remember the name “Zeek” and ultimately hire us, you can call me whatever you want.

Would Zeek have received the same traction if we’d called it Synergy Solutions? Would McRoberts be trending today had the Spurs lost that night? We’ll never know. Luckily we don’t have to find out. Like McRoberts, our name performs well, looks great and we’re committed to it, lucky break or not.

add_feed();

I discussed this function during the lightning round at WordCamp San Diego 2013.

add_feed() adds a custom feed to your WordPress site. I discovered this function recently when I needed to create a feed that uses a custom query. Specifically, a client needed a feed that pulled together content in a single category from multiple custom post types. The default WordPress category feeds will not pull content from multiple custom post types.

The code below can be dropped into functions.php in your theme folder or it could be rolled into a plugin.

add_feed( 'games' , 'make_games_feed' );

function make_games_feed(){
 $args = array(
 'post_type' => array('post','project'),
 'cat' => get_cat_id('games')
 );

query_posts($args);
 include_once(ABSPATH . 'wp-includes/feed-rss2.php');
 wp_reset_query();
}

After this code is added to your site, you must flush the rewrite rules to get it to take effect. A quick way to do this is to go to SETTINGS -> PERMALINKS and click SAVE CHANGES. You don’t have to actually make a change.

Yesterday, Suzette Franck posted the following to the OC WordPress Facebook group: A German developer named Frank Jonen had a dispute with his client, Fitness SF. He claims that the client did not pay their bill. Frank took his dispute to the web by hijacking Fitnes SF’s website and posted a note complaining (frankly, whining) to the world about his client. What Frank Jonen has done is completely unprofessional.

A screenshot of the hijacked page is at the bottom of this post. Leading up to the hijack, Frank tweeted about what he was doing.

http://twitter.com/frankjonen/status/301894155204964354

Bad form, dude.

Frank, I get it. You’re pissed. You feel wronged. You want revenge. This is not the way to go about it. Here’s why:

  • If you had any chance of reconciling a business relationship with this client, you can kiss it goodbye. You put a nail in the coffin. You will never have a relationship with this client and you will never get paid. Instead, you may be facing a possible lawsuit.
  • The page you posted is getting traffic on Twitter and you are getting noticed. But this is not the kind of press you want. Any potential clients that see this page will never hire you. You will forever be labeled as unstable.
  • It looks like you were attempting to make Fitness SF look bad and that you want their clients to take action. Make no mistake, you are the only one who looks bad here. And you look really, really bad.

Managing Expectations

I do not know the details of the relationship between Frank and his client and I have no idea what led up to the relationship going sour. Frank may have delivered late. He may have delivered work that was not what Fitness SF was expecting. Fitness SF may not have paid their bill for a number of reasons, many of which are not malicious. Who knows…

Regardless, Frank’s expectations about how he was to get paid were not met. And it was Frank’s responsibility to communicate those expectations before things got out of hand. I wonder if the milestones were set up in a way where the majority of payment was paid after the project was delivered. If they were, Fitness SF would have been motivated to make sure their entire project was absolutely final before paying for their project.

We prefer to establish milestones for our projects that include interval payments. This ensures that we ask for approvals throughout the project. Aside from payments, we make every effort to stay in constant communication with our clients. We request client feedback throughout our production process, at some points on a daily basis. If there is something wrong, we know very quickly and we can address it right away. Small problems should never have a chance to escalate to the level of complete dissatisfaction. But even with the best of intentions, it can happen.

Lots of things can change while working on a web project. I have never been on a project where the scope hasn’t changed over the course of the project. How you deal with scope change is what separates a good developer from a great developer.

This is a sad day for web developers everywhere.

The reason I’m disappointed is because Frank’s actions make all developers look bad. It tarnishes our industry and creates a trust barrier between clients and developers. I have spoken to many potential clients in my career who have a horror story about a former developer. I’m sure Fitness SF has their own story to tell.

Not getting paid is usually a matter of expectations being out of whack. We’ve had clients that weren’t able to pay their bills. It happens. And while I don’t like it, we have always found a way to deal with it peacefully.

Don’t be like Frank.

For more, see this AdWeek post.

fitnesssf

aliso

Joanna Clay recently interviewed me for an article she wrote in the OC Register: Aliso Viejo website arouses security, cost questions. She asked my opinions on alisoviejoexchange.com, a site built by a local developer. They were paid $37,500 to build the site and that it took 5 months to develop.

D’oh!

It’s not really my desire to judge other developers, but my initial reaction was that this does not feel like a site that would cost $38k to develop. This is a very simple directory site that looks like it was built with an existing template. Even if it was built from scratch, the whole site is comprised of three page templates: The home page, the detail page and the static content page. Oh and let’s not forget the sweet YouTube video splash screen!

Judging turnaround time is complex, however. It’s impossible to look at a site and understand what may have happened behind the scenes to cause delays. As any developer knows, a simple project can go sideways quick when communication breaks down with a client or when scope shifts. In a perfect world, sure, 5 months is way too long. But the development world is never perfect.

As I told Joanna during the interview, it is difficult to say exactly what went wrong with this project as I was not privy to the internal development process. My comments were based on my own experience and I made several assumptions.

So I asked the people…The people of WordPress

I run a private Facebook group for the OC WordPress Meetup and I posted a link to the article for discussion. My friend Jeff Hester asked “Based on the article, what do you think the lesson is for developers?” Great question. Here are a few of my thoughts…

1. Be transparent

My assumption is that there wasn’t a lot of transparency on this project. Projects can get bloated when the developer is “hiding” something from the client. It appears to me that We The Creative does not have a lot of web development experience in their portfolio and they may not have been forthcoming with this.

I am a firm believer in full transparency with my clients. I let them know very clearly what we can and cannot do. We are transparent with our core strengths and we let them know if a task is not in our wheelhouse. We let our clients know what technologies we are utilizing and why. We build on WordPress and we use existing plugins and themes. Leveraging existing technology provides a quicker time to market and that is a value to our clients.

2. Use common tools

A search on builtwith.com will expose that the developer used Ruby on Rails to build this site. An earlier search showed that they used a CMS called SDL Tridion, although that isn’t showing up any longer (I’m not sure why). When a developer builds with not-so common technologies, it locks the client in with that developer. There aren’t as many developers experienced with these platforms. If things go south with that developer, the next one will will most likely recommend a compete rebuild.

We only build sites using common tools. And our clients own the code. If something were to go wrong, our clients all have the peace of mind of knowing that their development can be taken over by another resource. And most importantly, other resources are available.

3. Be responsible

I am betting that the original timeline on this project was not 5 months. It had to have been far shorter. Who would sign off on 5 months for such a simple website?!? Something caused a delay in the schedule. I assume the deadlines got pushed on either the client side or the developer side or both.

The responsibility of controlling deadlines lies with the developer. It is the job of the developer to set the expectations early in the project, specifically what happens when the schedule slips. When there are no expectations, minor slippage can turn into major slippage quickly.

I would like to hear your thoughts on this.

How To Speak Geek, Part 4 – Bug Reporting

This is the final installment of my four part series on how to communicate with your developer. Part 1 covered Interviewing Your Potential Developer, part 2 covered Planning & Project Management, and part 3 covered Version Control.

Bug Reporting

Problems are going to occur. The way your developer handles problems is what sets good developers apart from bad ones. I have never found a website that was 100% bug free; not even the largest websites. Knowing this ahead of time may help you handle problems more rationally.

Do your best to keep emotion and drama out of the situation. When a problem arises, take a deep breath and count to 10. Most emergencies are usually resolved very quickly. What may seem like a major problem to you might actually be a minor technical problem that your developer can fix in 5 minutes.

Your bug reporting procedure should be established during the planning phase of your project. You and your developer should agree on how emergencies are handled as well as non-emergencies. You need to agree first on what constitutes an emergency. Typically on our projects, an emergency is when any part of the site is not accessible by the public. This happens when either a page fails to load or the server is acting slow for some reason. For all other situations, we have our clients submit a ticket to our project management system.

Developers do not like guesswork. When reporting a bug, don’t send an email to your developer with something like “My site isn’t working.” Lack of detail is very frustrating for you developer and the “hunting” time can cost you extra money.

Good bug reporting is an art form that can take some practice to master. To report a bug, you need to give as much detail as possible in a concise document.  Start by giving a brief description of the issue in plain English. Don’t try to analyze any technical issues.

Then, give the exact steps to reproduce the problem. Tell your developer exactly what you were doing at the time the problem occurred. Also, include your operating system, browser version and any virus or firewall software you might be running.

support-detailsAn easy way to send your system details to your developer is http://supportdetails.com. Our customer service people at Real Estate Shows use this site extensively. When a customer reports a problem, they have the customer send an email from that site.

VERY IMPORTANT! When reporting problems, make sure you specify the priority. Be realistic. Is this a mission critical problem? Can it wait a few days? A week? If you don’t regularly specify a priority, your developer should get into the habit of asking the priority.

If your site is inaccessible, check out http://downforeveryoneorjustme.com before contacting your developer. This site will let you know if the problem is limited to just you or if the public is experiencing it as well.

A Few Additional Tips

Brainstorming is a good thing, but there is a fine line between brainstorming and feature creep. As you see your project being built, your mental wheels will start to spin. You will be thinking of additional enhancements to these features. However, if you want them added in your current working phase, be prepared to revise your statement of work. There will be an impact on the schedule and/or budget.

Many developers speak in languages that sometimes I don’t even understand. You will hear them refer to technology using terms and acronyms that will make your head spin. And they will rattle them off like you are supposed to know exactly what they are referring to. When this happens, make Wikipedia and Google your friend. Jot down the terminology and look it up later.

Conclusion

The bottom line is that many of the horror stories that I hear could have been avoided with clear communication. While there are a few bad seeds, I believe that most developers are not maliciously screwing up projects. Several factors may have contributed to projects that went wrong. If you have a developer horror story, I encourage you to look back at what could have been done differently to avoid the problem(s). Learn from it so that you don’t fall into the same trap next time around.

How To Speak Geek, Part 3 – Version Control

This is the third installment of my four part series on how to communicate with your developer. Part 1 covered Interviewing Your Potential Developer. Part 2 covered Planning & Project Management. Part 4 will cover Bug Reporting.

Version Control Is Critical

Version control is critical! In case you missed it, I will say it again. VERSION CONTROL IS CRITICAL!!!

So what the heck is it? Simply put, version control is a system that saves each iteration of your code. The code is stored in a central repository and all code changes pass through that central repository. Multiple developers are able to simultaneously work on the code and the system aggregates the changes. Version control also gives your developer an easy way to quickly “roll back” code to previous versions if something goes wrong. For a more detailed explanation, go to http://en.wikipedia.org/wiki/Version_control.

gitYour developer needs to implement a workflow where the code has to pass through version control as a way to push changes live to your server. We typically work on all code locally and then push it through version control to a live server. On larger projects, this workflow may include pushing to a staging server first and then to a live server. Either way, the code always passes through version control.

So why is all of this important to you? I am glad you asked. Your version control system protects you if your developer drops the ball. You will always have access to the latest version of the code. If your developer bails, you don’t have to hunt down your code or worse, start over from scratch. You should be able to simply grant access to a new developer.

Three popular version control systems are svn, git and Mercurial. At Zeek, we use git.

It is important that you have access to the code repository for your project. Your developer needs to grant you access if they are hosting the repository. Better yet, host it yourself so that there is no confusion down the road.

There are services that offer inexpensive version control hosting.

  • Beanstalk (http://beanstalkapp.com) offers hosting for SVN and git.
  • Bit Bucket (http://bitbucket.org) offers hosting for Mercurial hosting.
  • Some sites offer free repositories, but your code will typically be public if you use a free system.

Note. If your developer does not currently use a version control system, insist on it. If they refuse to use a version control system, find a new developer.

Up next: Part 4 – Bug Reporting.

How To Speak Geek, Part 2 – Planning & Project Management

This is the second of my four part series on how to communicate with your developer. Part 1 covered Interviewing Your Potential Developer. Part 3 will cover Version Control and Part 4 will cover Bug Reporting.

Planning

As the old adage goes, “Bad planning on your part doesn’t make it an emergency on mine.” This is exactly what your developer is thinking when you make last minute feature requests that were not in the original work scope.

Planning is about setting expectations. If expectations are spelled out up front, there should be no surprises. This is an ongoing process and expectations will need to be revised as you move forward. Your developer may lack the skills to proactively set expectations, but you can take on this responsibility. The developer will probably thank you for doing so.

The Statement Of Work

The most critical document you need for any size project is a Statement of Work (SOW). The SOW needs to contain a detailed description of the project, the milestones, a timeline and payment terms. Depending on the complexity of the project, your SOW may need to contain specific details about each feature and how that feature is supposed to operate. Include as many specifics as it takes so that little is left to interpretation later.

This is the time to address code ownership. Who owns the code that is generated as a result of the project? Different developers have different points of view on this subject so it is important establish this early. In my work for hire contracts, our clients own the iteration of the code that we develop for their site. This means that we are able to re-use our routines on other projects, but we cannot re-use an entire project elsewhere. If you want to own the code, then you will need to negotiate this in advance and the SOW is a perfect place to do this.

Take your time creating the SOW. Your developer should not write one line of code until this is finalized and agreed upon. When I create an SOW, it typically goes through several drafts. I will submit a draft to my client for their review and then they will make edits and submit it back and so on until we both agree that it is final. You can use Word, Pages or Google Docs for this process. Whatever software you use, make sure you use the “Track Changes” tool so that you can see the progression.

Once the SOW is complete, both parties need to sign a copy of it to signify that they agree. For larger projects, my SOWs get attached as an exhibit to the work for hire contract.

A couple of important notes:

  • You can never over-plan! Good planning and documentation reduces the guesswork as your project gets developed. Anything you can do to cut down the margin for error will save you money in the long run.
  • Always try to avoid doing anything as a rush. You are always asking for mistakes when rushing.

Project Management Site

Your developer should use a project management tool like Basecamp. This will allow you to track your deliverables and project schedule. The site needs to have a good commenting system so that your conversations around a particular task are centralized in one place.

goplan2-logo-bigDO NOT use email or instant messenger to track tasks! These conversations tend to get lost in the shuffle. I have found that important parts of the conversation get lost when someone accidentally forgets to cc the group. 🙂

The SOW should become a road map for your project management site. All of the deliverables from the SOW need to be converted to tasks on the site. This can be done by you or the developer. In addition to task tracking, your project management site should be used as a central place to post feature discussions, technical notes and design comps. Your project schedule and major milestones should also be tracked on the site.

At Zeek, we use a site called GoPlan. GoPlan is similar to BaseCamp, but we switched because it has a good bug tracking ticket system built in.

Take an active part in the project management, but be careful not to micro-manage your developer. And when possible, ask your developer to use a screen sharing site like GoToMeeting.com to explain when you don’t understand something their saying. So many communication issues can be solved if a little extra time is taken at those critical moments in the project.

Up next: Part 3 – Version Control