You may be asked to develop a proof of concept or a demo site for a customer on platforms ranging from WordPress to Magento. Building the site locally makes sense for instances where:
- Existing hosting inhibits you from developing a demo site
- Hosting has not been agreed upon and the client wants to see a bare-bones site before committing to a full-scale hosting agreement
- The existing host does not have the correct code stack for development
- For example if you are moving from a .NET platform to a PHP platform
- Let’s be honest, you are not sure the client will move past the proof of concept phase and you do not want to go through the steps to setup new hosting nor do you want to put your code out there only to have it “appropriated” by the client for their own use
- The technical equivalent of the client taking your ball and going home
However you arrive at the decision to develop locally, you will need a method to demo the site to your customer. A screen share is always an option, but that does not allow the customer to freely click-through the site or get a true sense of site speed.
Share your local environment
Let’s use a simple example of a client with a static website which hasn’t been updated since the Cubs were last in the playoffs. The client wants a new site they can easily update and one that will scale based on their needs. Seems like a logical case for a CMS such as Drupal or, my favorite, WordPress.
Now we’ll say that you have convinced the client to go with WordPress and all it has to offer. One of the features the client is interested in is the theme capabilities inherent in WordPress and, just like any curious client, she has gone out and found a series of themes that tickle her fancy.
Once you filter through themes that will not fit the project needs, you end up with a few themes of which the customer would like to “kick the tires”. The customer need to see the theme, click the links and view the differences between a page and a post to understand the dynamics of the site and platform. You agree to set up an environment for the client because, as we all know, the customer is always right.
I’m LAMPin’, I’m LAMPin’, I’m Cold, Cold LAMPin’ (Can you name the song?)
You’ve installed LAMP locally in your Inetpub directory (now do you get the headline tie in?) and have the customer’s preferred themes ready to demo. Don’t pat yourself on the back just yet, how in the world will the customer get to the site locally? Dang it…you forgot that little detail.
You need to provide a way for them to get to the local setup on your machine to use the site. You need a tunnel. A tunnel simply means that you are providing the customer a public URL (a tunnel) that accesses a specific port on your local machine to view the site you built.
I create a “tunnel” to my local machine using ngrok. Ngrok is fully secure and let’s you define who can access the tunnel so that not every bored knucklehead can access your machine and find your questionable file of selfies.
Installing ngrok is straightforward.
- Choose your ngrok download type – I used Windows
- Extract the files from the downloaded zip file
- Go to the Windows start menu, type in cmd to open the cmd prompt
- Once in the cmd prompt, change directory to the location to whicchngrok was downloaded
- For example, if you downloaded ngrok to C:/ngrok your cmd would be:
- Once in the ngrok folder, type command ngrok 80
- This tells ngrok to start and open port 80
- Port 80 will be the tunnel through which your customer accesses the site
- Ngrok will return two URLs an http and anhttps. For example, my ngrok URLs are
- These are the public-facing URLs that you will send to your customer. They allow them to use the local site you have set up
- Ngrok will also provide a URL you use on your machine such as localhost:4040
- This is the local web interface to ngrok and will show you inbound traffic through the tunnel so you can monitor the client and any other activity
That’s it. The customer is now free to click through and evaluate your WordPress local site without you doing a screenshare or resorting to some other inefficient sharing method. Once the client has seen what she needs, you can shut down ngrok and make any updates needed. This is a simple way to develop locally and kick the tires before launching on your host of choice?
Do you have other methods to sharing our local environment? There is always more than one way to skin a cat. Post your tools and methods here and I will share the best ones.