When is it time to launch your new business?

There are countless articles out there on this topic, none of which will help you actually make a definitive decision for when the right time to launch is. The reason they won’t help you is because launching a new business is intrinsically subjective. There are so many variables that go into launching and running a business that even the best articles can provide only guidelines.

I’ll sum up most of the articles out there on this subject: Launch as soon as you can.

If you look past the simplicity of it, the answer and advice is dead on. It is important get your name out there and start building a relationship with customers. You can’t really do that unless you are live.

So, diving in deeper, what constitutes being ready? That depends on you, your business, your market, and your goals for the company. I can’t provide the answer to you but I can tell you what drove my decisions for my recent launch, Tanglewood Turnings.

Tanglewood Turnings started out entirely different from what it is today. Back in 2005 I had an idea for a website where artists from around the world could come together to sell their products without having to worry about all the technology setup and headaches of running a website – they could simply focus on their art. The site was going to be called TanglewoodArts.com and was going to become the de facto place for artists to sell their wares.

It didn’t work out that way.

I kept tinkering with the code and kept adding “just one more feature” and adding “just one more cool technology” until it was too late and Etsy had burst onto the scene and carved out a place as the leader in this market. I waited too long and lost my opportunity.

I viewed the software I was writing in light of things I’d like to see go into the product and the technologies I’d like to use instead of things that will allow the business to start operating. In hindsight I didn’t need 90% of the crap that I wrote, at least not for launch. While much of it is useful and may eventually get some use, the only thing I needed for day 1 was a way for artists to upload their products, a way for users to look at the art, and a way to process payments and orders. Instead, what I was building was a complex system that gave artists and admins fine grained control over all sorts of different aspects – artist profiles, preferred shipping methods, custom order request capabilities, etc.

I missed the mark and I lost my opportunity to corner the market before Etsy did. I failed because I couldn’t draw a line in the sand and say, “these are the only things we need for day 1 and no more.”

The entire time I was adding feature after feature, Etsy was gaining market share and becoming a household name. What’s worse is that I didn’t realize my mistake until it was too late.

After my realization that I missed my window of opportunity I let the code float for a long time – multiple years. I’d write a little code here and there but it was never with the goal of launching anything. Instead, I wrote code because it kept my skills up to date and gave me a good opportunity to stay abreast of the latest happenings in the constantly evolving world of Ruby.

Last year I decided that I wanted to spin the idea up again. In thinking this through I decided to focus on a niche market that I knew well – wood turning. So I started doing research and found that while there are a bunch of sites out there that sell hand turned pens, pencils, bottle stoppers, etc., there are none that a) allow multiple turners to sell through the same site and b) provide a real time custom product builder. I decided that those were my differentiating features. The multiple artists at one site I had. I had already started on the concept of a much more generic custom product builder. I had a working shopping cart, order, and product system.

So I drew my line in the sand. I would launch as soon as the custom product builder was ready in its most basic form. I did. (Note that I did take a brief hiatus to pursue another project, otherwise this timeline would have been more like 2 months instead of 8.)

Now, I have a name out there and I have actual paying customers. I’ve got an offering that is truly unique, allowing me to build a customer base in areas that other sites and vendors can’t fulfill.

Is the site done? Hell, no. I’ve got a list of an additional 50 features or improvements I’d like to make to the site. Right now I have to manually process payments for artists, when it could be automated. Right now users simply get the lowest shipping rate available when I’d like for them to have an option so they can dictate preferred shipping speed. Today I have to manually update various data points such as prices, availability, etc. change in the market when this really should be automated. The custom product builder currently has the capability to support things like accessories, however I’ve not loaded any into the system. The list of things that would make the site better, but weren’t necessary for go live goes on.

Unfortunately it took me losing a really good business opportunity to realize that I didn’t need all the crap that I was writing in order to start the business. What I needed was quite simple but I made it much more complex because I liked writing the code.

Your case is likely no different. Put all the items you want for your product in a list. Now go through each item and individually decide if that item is an absolute must for go live. These are things that your site simply cannot function without or things that you’ll miss out on differentiation without. Once you finish this process you should have a much shorter list. Now do it again with that shorter list. When you are done with that, do it again. Keep doing it until you are sure that you have carved as much fat as possible. Now, when that list is coded and tested, you are ready to launch.

This is the process I followed for Tanglewood Turnings, which worked well. This is NOT the process I followed for Tanglewood Arts, which resulted in failure.

Announcing Tanglewood Turnings!

I’m proud to announce the launch of a new site, Tanglewood Turnings.

Tanglewood Turnings - www.tanglewoodturnings.com

This site will allow artists to sell their products through the site as well as give people the ability to create their own custom build products with our one of a kind custom product builder. The custom product builder allows you to select a series of components that will make up your product and builds out a rough representation of your product right on the screen.

I’ve been playing with this concept for almost 5 years now (that’s a topic for a different post that I’m working on still – “When is it time to launch?”) and have finally decided that it is time to stop writing code for the sake of writing code and launch the site.

Please take a minute to check out my new site. Drop me an email if you find any issues or have any questions or feedback.

Application Design for Mobile Devices

As I watch the mobile software market explode I can’t help but notice a pattern that keeps repeating itself. Like software architecture design patterns, software packages follow distinct patterns that have been repeating over the past 20-30 years.

While there is a lot of history before this point, let’s start at mainframes and terminals. See a pattern here?

  • Remote – Terminal / Mainframe
    During this phase of our history one could sit down at a dumb terminal that had a direct connection to the mainframe. This would provide remote access to the functionality on the server but wouldn’t provide much other functionality.
  • Local – Thick client apps
    Next came thick client apps. That is, applications that are physically installed on a computer. This typically moved a lot of the processing off the central system and onto a stand alone computer. A good example of this is word processing.
  • Remote/Local – Distributed thick client apps
    Once thick clients were widespread the software industry quickly realized they had a problem. They needed easy ways to update their thick client applications but also needed to be able to gather and aggregate data across all of the installations. The resulting evolution was a set of applications that could communicate with a central server as well as install updates as necessary, all without needing a technician physically present.
  • Remote – Web based apps
    The software industry quickly realized that the bulk of the functionality that they were installing on people’s computers could easily be handled via the internet, given the advance of software and networking technologies. Thus, the web based app was born. These apps provide 90% of what most users need without the overhead of distributing, installing, and supporting thick client software. Note, however that specific app needs still have to be addressed with this clients, even in this evolution, 3D rendering being a good example.
  • Local – Thick client mobile apps
    As the mobile world started to mature we found that the hardware in our mobile devices was becoming much more powerful and capable of handling apps. At this time the browser capabilities of these devices as well as the ability to have fast mobile networking was sufficiently infantile that once again we found ourselves utilizing thick client apps as the best way to deliver functionality.
  • Remote/Local – Distributed thick client mobile apps
    Once again, technology advances delivered us better mobile browsers and a newfound ability to handle much faster networking on mobile devices, giving birth to the distributed thick client apps for mobile devices. These apps, in many regards, follow the same basic principles as the distributed thick clients of the PC era. They are installed but can update themselves and communicate with a remote server or servers.
  • Remote – Mobile responsive apps
    This phase of our evolution is unfolding now and is really just starting to gain traction. Over the next year this will become the de facto way that the majority of companies get their data into a mobile device. The responsive layouts concept is a way of designing a web site/application in a such a way that it understands what kind of device (PC, phone, tablet, etc.) it is being displayed on and applies the correct styling for that type device. Bank of America has a pretty good example of this. If you visit their mobile site you are seeing the same basic content you would on their primary site, however it has been styled so that it works well and is easy to use on your mobile device.

Predicting what comes next in this evolution isn’t exact but also isn’t particularly difficult. We’ll likely see bridges to cross some of the major gaps that currently tie us to mobile devices, such as:

  • Browser support for mobile features
    Mobile browsers will likely continue to begin supporting, or at least provide an API for supporting, multiple features that are device specific, such as GPS or the accelerometer. Likewise, mobile operating systems will continue to evolve in such a way that allows the browser to more easily interact with the mobile system.
  • Generic push notification capabilities
    One of the major limitations today that cause companies to gravitate towards thick client mobile apps are push notifications. If I want to be able to notify a user of a particular event the only way to do so today is to utilize the push API for a particular device. My hope is that this functionality will become standardized in such a way that notifications can be sent to a central location (albeit, possibly different device dependent locations) that knows how to notify the device in a manner suitable to that device.For example, my web application may trigger an event that then notifies the Apple servers of the event and provides a unique key that was authorized by and identifies the device. The Apple servers would then know how to send the notification to that device based on the unique id. Users would be able to easily control who does and doesn’t have access to push to them in the same manner they do today, only the system would be distributed.

Until these changes take place there will always be a need for a thick client mobile app in certain situations. Just don’t write a custom thick client app for a mobile device unless you actually need the features that are offered by the mobile device you are writing for. If you just want an app for the sake of having an app, spend your money having a good designer build a mobile responsive layout for your site. However, if you actually need things like GPS, accelerometer, notifications, or other device specific features, you really don’t have much choice, in present day, but to write a thick client mobile app. In this situation you should still follow the web based paradigm as much as possible and keep as much content web based as you can.