The Ninth Yard

How to Work With a Contract Web Developer: Picking A Platform

2010-07-09T10:32:00.001-05:00

Ask a software developer why they use the language and framework they do, and more often than not you'll get a passionate, solidly-formed opinion. But it probably won't be helpful to you when trying to decide what platform you want to pick for your new project.

Developers love technical details, and sometimes forget the business context behind those technical choices. This post is my attempt to shed a little light on the subject.

First, the basics. What is a language, and how is it different than a framework or a platform? For the purposes of this article I'll define them:

Language: This is the programming language that the application code is written in. The most popular languages for web development these days are Ruby, C# (c -sharp), Java, PHP, and Python. I would advise sticking to one of those unless you have a really good, concrete reason. ("It's new and cool" is not a really good, concrete reason.)

Framework: Web applications tend to have a lot of infrastructure in common - the very basics of what makes an app work. This is the framework. Frameworks exist to give developers a common place from which to begin their projects. Examples of useful frameworks are Ruby on Rails, Django, Microsoft's .NET MVC, CakePHP, and others. Frameworks, in general, are married to a specific language. Ruby on Rails, for example, requires that Ruby be the programming language.

Platform: This is more my definition than a standard, but what I mean by platform is the combination of technologies and programing libraries that you will use to create your application. Some people might refer to this as a "stack". For example, I tend to gravitate to the following basic technologies for a new web project:

Language: Ruby
Framework: Ruby on Rails
Database: MySQL
Server OS: Ubuntu Linux
Web Server: Nginx with Passenger
Javascript Library: J Query or Prototype

These are some pretty standard options as of this writing for a Ruby on Rails application. Different situations may call for changes, but that's the basics of it.

Now that we have definitions out of the way, lets get to how you choose one. A brand of conventional wisdom existis that says "Let your developer pick." Sometimes that may work, but for the reasons I outlined above, the developer working on the project may be a little biased.

So what are the differences and why do they matter?

I will go out on a limb and say that, technically speaking, there is precious little difference between using the .NET stack and Ruby on Rails. Java, Python - they all get the job done. Technology is not what you need to be worried about.

What you should instead think about are the people behind the technologies. Each platform has a certain culture that tends to attract different sorts of personalities. I'll risk being overly general and categorize platforms as either "startupy" or "enterprisy".

In the startupy category I'd put PHP, Ruby, and Python. These languages tend to be favored by independent developers and startups. They are quick to work with and flexible. These open source languages are supported by volunteers and rely heavily on devoted enthusiasts to maintain and improve them. As a result, some features are more mature than others. Ruby is the newest of these dynamic languages, and anecdotally, I would say it's growing at the fastest rate with the startup crowd. This is almost entirely due to the popularity of Ruby on Rails, a framework that preaches convention over configuration and a practical approach to development.

I'd put Java and the .NET MVC framework in the enterprisy category. These are well supported languages/frameworks that are backed my major corporations for use by other major corporations. As a result, you'll find lots of support through official channels. A significant note: Microsoft's products are not free. Pretty much everything else is.

Often, you'll hear developers who prefer the startupy languages complain about the bloat of the enterprisy ones. The other side of story is that you'll hear proponents of the enterprisy languages complain about the relative lack of discipline and scaling challenges inherent in the dynamic languages. Again, none of this matters.

You will find it much easier in today's market to find a Rails developer willing to work as a freelancer or at a startup. The Java and Microsoft developers tend to gravitate towards large, established companies. Good developers are in demand, so you don't want to make it hard on yourself by selecting a platform that makes it even tougher to hire.

As I said, at Ninth Yard, we use a plain vanilla version of the Rails stack. It may be the best thing for your project, or it may not be. Just remember - pick people, not a platform.

How to Work With a Contract Web Developer: Agile Scoping

2010-05-14T16:22:00.002-05:00

So I've just discussed the importance of engaging a web developer in an Agile process. Everything should be fine now, just iterate quickly and actively and it will all work out. Right?

Well, I left out one important piece of information. Reality has a way of getting stuck in the gears from time to time. It's the thing that Agile proponents don't much like to talk about: billing and contract scope.

As a client, you want a web site. You'll pay a fair price for it, and you want to know what that price will be up front. That, to me, sounds like a very reasonable proposition. The alternative is hourly rates, which have some problems:

Incentives are misaligned. More work equals more pay for the developer, but not necessarily more product for the client. There is more than one way to skin a cat, and some of those ways take more time.
Expectations are not agreed to. How long is this going to take, anyhow? If you don't nail down some specifics, you will have a project that will end when the money's gone, finished or not.

I'm a believer in defining the scope of a project before starting and putting a fixed price tag on it. This keeps the project to manageable, finishable scope and encourages the developers to work smartly.

The astute reader will realize that this advice is in direct conflict with my last post on keeping things Agile. And you're right.

More to the point, this is an area that requires some finesse. In exchange for some tangible benefits (a solid scope and a better alignment of the client and the developer), we generally have to sacrifice some Agility. We can nail down the obvious big issues, but still remain Agile about which of the smaller issues get our attention and when they get it.

Here's the process I use.

Client Homework. You, as a client, need to do your homework before I get involved. You need to have thoroughly thought through the problems you are trying to solve. Put more concretely, you need to have created some wireframes of what you think the site will end up looking like (functionally, not aesthetically). I like to use Balsamiq Mockups, but Powerpoint, Visio, Omnigraffle, or just pen and paper are fine too. These mockups should be complete. All of the important views need to be drawn with all the buttons in the right places. Text and copy can be rough, but there should be something there.

Walk through the wireframes, imagining that you are using the software. Click here. What happens next? Run through all the most common scenarios you can come up with and adjust your wireframe to suit what you've learned from your thought experiment. If you need help, check out Don't Make Me Think: A Common Sense Approach to Web Usability
or the voluminous information at Jakob Nielsen's site. Another good rule of thumb for user interface (UI) design is to look at how Apple or Amazon handle similar issues. There's a good chance they've come up with a very good solution.

And now, the important part - the part that requires a mental shift. Understand that you will not be getting this product. The purpose of this exercise is to understand the problem at a detailed level before you get started, not to spec out a web application. You will find some concepts that are critical to the product, some that might be useful, and some that really don't need to be there at all. But you must understand and embrace this point:

This is not a requirements document. It is your vision, written down.

This education process, which you should share with your contract developer, will allow both of you to gain the insight into what the scope of the project will turn out to be.

Developer Homework. Next, you need to thoroughly communicate your findings to the web developer, and come to an agreement about pricing and timeline. You will have put enough thought into the product so that you will be able to come up with some rough time and price estimates, even though you know the product will evolve in development. At this point you must both commit and name a price, a deadline, and an outline of the critical features. The deadline is especially important and must be a hard date to launch the product.

Get to Work. Now that you have a price and a timeframe, it's time to get to sign a contract and get to work. Expect to meet with your developer at least once a week, sometimes twice. Expect to work almost as much as the developer does. You will need to redraw interfaces that don't work like you thought they would. You'll test and retest the live application (there will be something live to test within a few days, and every few days after that). Your experiences will cause some of your features to shift in priority and in form. That's not only ok, it's expected and good. It's all part of the process.

Over time, the product will mature and the deadline will creep up on you. Pay attention to it. The knowledge that your developer time is running out will be a great motivator to build what is important, use the simplest solutions, and ignore the fluff. This is a critical piece of the Agile puzzle. You cannot be Agile without constraints. Even you're not under any particular time pressure, pick a hard deadline and stick to it. I cannot stress this enough:

DO NOT MISS YOUR DEADLINE

Launch. If all has gone well, you'll have a product that is minimally sufficient come launch day. Launch it. Tell your friends to try it.

Post Launch Work. You will also probably have a few "must have" features that are missing that the developer committed to. That's ok and normal. Just add them after launch. You and your developer should have budgeted some time for post launch activities. This is when you fit in the stuff that took a little longer than you might have thought. It's also when you start listening to your initial users. You will undoubtedly learn something right away that will make you want to change something. Do it now.

Contract End. At this point, you'll have a working, but imperfect application that you can use to start testing your market. If you take a look at your original wireframes, you'll probably find that some parts your new product look just like you drew them, and other parts are a bit different. There will probably be some features that didn't get built, and some that were built that aren't on your wireframe.

In practice this a typical contract might be scheduled for four weeks of pre launch work, followed by one week of post launch work, and consist of a fixed price tag and a high-level, but specific list of "must have" functionality.

There are some risks inherent in this method. It requires a degree of trust. It won't work, for example, if you, the client, are intent on squeezing out as much work as humanly possible from this one contract. It also won't work if the developer is intent on doing as little work as humanly possible on this one contract. It requires a professional partnership-style attitude on both sides of the deal to work. By the end of the contract, you should both want to work with each other again - so keep that in mind during the contract. Choose the people you work with very carefully. If they can't or won't understand a part of this process, don't even get started.

Is this Agile Utpoia, where products freely evolve until they achieve greatness? No. But it's about as close to it as you'll get without an open-ended, hourly contract. (Which, by the way, can work. It's just that it requires even more professionalism, interpersonal understanding, communication, and trust than the process I've laid out. It's more suitable for a second contract with a proven partner.)

Up Next: Picking A Platform

How to Work With a Contract Web Developer: Agile is the New Average

2010-04-23T12:25:00.002-05:00

You may have heard the phase "Agile Development" and wondered what it means. You need to know before you hire a contract web developer.

Once again, I'll go back to my days as an aerospace engineer working on space shuttle launches for some background. Planning and engineering a space shuttle launch is a long, tedious endeavor that takes lots of people time, and money. Everything is mapped out in as much detail as possible at the earliest time possible. The reason for this is obvious - you can't afford to wing it when something as simple as machining an aluminum mounting plate takes 10's of thousands of dollars and several weeks. How long to you think it takes to build a camera that can look back 10 billion years?

And the requirements... so many, many requirements. There is a spec for everything because everything matters. Is the honeycomb panel strong enough to withstand a wayward kick from an astronaut? Will the handrail be too hot for him to touch? Where is the sun anyhow? What about those bolts? What happens if the astronaut can't loosen them? What happens if he can loosen one, but not another, and the first one floats away into space?

Lots and lots of requirements. Lots of planing, and then the work begins. It is a slog. It's slow, expensive, and still doesn't prevent the unexpected. But given the constraints, it's not a bad way to launch a space shuttle.

Back in the "old" days, they made software this way too. Everything was spec'd out in advance. User interface, data structures, performance - everything. Once a project is all planned out, it gets broken up into well defined pieces for developers to work on. Sounds great, right?

In practice, it's not so great. Software is so flexible and so conducive to innovation that you almost never know exactly what you want to build before you get started. You'll have a vision - a vague idea of what the software should do, not a well defined set of specifications. I'll even go as far as to say that if you think you know exactly what you want to build, you are wrong. There is something you think you want that you don't or something you forgot that you really do need. It's just the way it tends to happen.

Aggressive and thorough pre-planning for software development is exactly equivalent to waste.

So what do you do? You use Agile methodologies. What it means in a nutshell:

Plan and build the smallest chunck of software that actually works, even if it falls way short of what is eventually needed. This entire iteration can be as short as a day or two. The iterations tend to get longer as more developers are added and the software gets more complex, but if they're more than 3-4 weeks, something is wrong.
Try it out. You, the client (acting on behalf of your customers), need to try the newly functioning software, minimal as it may be. The process of actually clicking and typing in your application will clarify your thinking and help prioritize what needs to be built next. You cannot skip this step - be prepared for a lot of work.
Repeat until your app solves the problem you set out to solve.

This process eliminates waste because very little effort is spent working on bad ideas before they are exposed and discarded.

As soon as the application is good enough to put in front of customers (more on what this means in a future post), launch it. Even if it's not perfect. If it's perfect, you waited way too long. Perfect is the enemy of progress.

The truth of the matter is that the application you launch won't be quite right. Your insights, no matter how much domain experience you have or how much thought you put into the product, will not be enough to create a great product right out of the chute. Even a paying customer won't help much - customers are terrible at providing specific guidance.

But how can you launch something that's wrong? Isn't that business suicide? No. Not when you're iterating quickly. Your beta application won't be totally wrong - just kind of wrong. As soon as it launches, your users will become your allies in the "Try it out" phase of the cycle. Listen to them, interpret their specific needs, and make a decision on how to improve things. Nothing is that big of a deal because the next release is just a few days away. If your product gains traction, this pattern will never stop - you keep improving and testing and listening. Over and over and over again. Software development is a journey, not a destination.

This is the face of modern software development. Embrace it. It works.

Coming next: Agile Scoping

How to Work With a Contract Web Developer: The Better-Cheaper-Faster Myth

2010-04-07T13:55:00.001-05:00

Once upon a time I was a young aerospace engineer working on NASA's Hubble Space Telescope project. A typical shuttle mission, if there is such a thing, took about three years to plan. Hundreds of companies, thousands of people, and billions of dollars were stirred up with a healthy dose of governmental help. All for a total of five or six work days during which over-qualified astronauts fixed the aging telescope.

A common truism repeated by engineers was "Good, Fast, Cheap - Pick Two." Of course, that common refrain was at odds with the official NASA slogan of "Better, Faster, Cheaper". As is often (but not always!) the case, the engineers were right. Attempts to reign in costs always failed as the consequences of cutbacks began to show themselves. Demands for quality were continuous and proper - we're talking about huge amounts of money, not to mention human life and national pride. Giving up "Good" was not an option. That left Fast or Cheap on the chopping block. What usually happened was some things got done fast and other tasks were done cheaply (by government standards, at least).

They were right about human space flight, not web applications. The NASA engineers neglected a fourth variable - scope. A space shuttle mission's scope is rigid. You must launch the payload and the astronauts must be able to fix the telescope. End of story.

That is not true for a web application. If a project costs too much, you can almost always drop a feature. If that makes the feature set insufficient, you can reduce the quality. If the quality is too low, increase the time. If it takes to long, you can pay for more developers. So what should give? How do you address this balancing act?

In practice, some of these variables are easier to change than others. It is difficult to speed up development by adding money, for example. Software development just doesn't work that way. Real life budgets are usually constrained, as well.

Similarly, there is a minimum acceptable scope. It's been popular recently to call this the Minimum Viable Product, but that's pretty much buzz-word-speak for "the simplest product that will solve the problem it's aiming to solve."

Building a minimal product is not the same as building a low-quality product. If quality dips too low, maintenance costs more, future coding is slower and more expensive, and the overall user experience suffers from outages and other weirdness.

So we typically have a minimum scope, minimum time, maximum budget, and minimum quality level.

No project should ever be started unless all of those constraints are acceptable to both the principal and the contractor. If there isn't a viable sweet spot where everything works, someone is going to be disappointed. This requires discipline, careful thought, and an honest look at reality. Nothing is going to be ideal, so get that out of your head right now. Building software is about balance and tradeoffs. Not even truckloads of money can change that.

Coming Next: Agile is the New Average

How to Work With a Contract Web Developer

2010-04-07T13:13:00.001-05:00

I often hear business owners or entrepreneurs lamenting the difficulty of hiring and working with contract web developers. Common complaints are "not enough contact", "they're hiding the coders from me", "too slow", "too expensive", and "nobody comes to this website I paid a fortune for".

As a whole, we contractors can be doing a lot of things better. But clients have a role in this too. I would argue that the trend towards agile software development has increased the role of the principal. No longer can you just throw a spec sheet into a darkened cubicle, kick back, and wait for your software. Not if you want good software, at least.

There is a lot to the principal-client relationship. It's critically important that both parties hold up their end of the bargain. If either fails, the result is a lousy product that winds up over-budget and late.

I'll be writing a series of blog posts on this topic in the coming weeks. It's a lot of material to cover, but I hope that anyone who wants to hire a web developer will gain some knowledge that just might save some time and headache.

Enough of the intro. On to the goods...

Next Up: The Better-Cheaper-Faster Myth

Stupid Google Tricks

2010-01-07T17:12:00.003-06:00

Getting into the Online Ad Business

2009-09-14T10:36:00.002-05:00

Now that the dust has settled a but, I'd like to update you on what I've been up to for the last few weeks. I've joined the team at Notice Technologies. Notice has been working on an inventive online advertising platform aimed at small business users.

I'm excited about this opportunity because I see lots of potential. Online advertising is rapidly evolving. As the online side of hte ad business hits the mainstream, it's becoming more and more of a big company game. Recently, I was told by a Google AdWords account manager that Google wont even assign a manager to an account unless they're spending $10,000 per month on AdWords. I don't think many local businesses have $120,000 online ad budgets, and I don't think AdWords is simple enough for most business people to tackle by themselves. The small business market has once again become under-served.

We're not competing with AdWords, however. I merely use them as an example of how high the bar is before small businesses get taken seriously. There is an opportunity here, and its'a big one.

At Notice Technologies, we're building the Minutes Notice platform. In short, it allows advertisers to think like business people, not online advertising geeks. They can broadcast their offers across the internet - email, Twitter, Facebook, SMS and more. All they do is type the text offer into the app and the system intelligently routes the offer to targeted consumers - all in real time. The entire process takes about than 30 seconds. Better still is that we've simplified pricing. We've gone to a flat rate system. No more CPC, no more CPM - just the ability to communicate with your customers when you want to in the ways they want.

For publishers, we offer the ability to create additional ad revenue from their existing locally-themed web sites.

If you're a local business or a publisher of locally themed websites, please let me know - we've got something we'd like to show you.

DemoCamp IV

2009-04-23T10:17:00.003-05:00

On Tuesday I demo'ed BackupMyMail at Bootstrap Austin's DemoCamp IV, and had a great time doing it.

DemoCamp is a quarterly(ish) event held by Bootstrap Austin that provides a forum for web developers and entrepreneurs to show off their new web applications. The rules are very simple: no powerpoint. This is for working (or sort of working) apps only. Sales and funding pitches are best left to other venues.

It's a great way to get feedback for that app you're developing. It's also a great way to see some of the really cool, under the radar stuff going on in Austin before it's ready for prime time.

For the 4th DemoCamp, five new or developing apps were demo'ed:

Prefinery: Prefinery takes the pain out of collecting emails on splash pages prior to a product launch. Sounds simple, but think about it a while and a world of opportunities open up. I have a feeling this product will not be about splash page management when all is said and done, but rather something much bigger.

CloudFire: CloudFire is a welcome twist on photo and video sharing. In a nutshell, CloudFire searched for photos on your computer, serves them up to share with your friends over the net, thus eliminating the hassle of uploading to middleman websites like Flickr. The state of the art of photo sharing still sucks, so I'm glad to see this kind of innovation going on.

BackupMyMail: My own product, BackupMyMail, does just that: it backs up your web based email into the cloud. We currently support Gmail and Hotmail, but more providers are coming soon. We will also be backing up Tweets and Blogs in the near future. Today is the last day you can sign up for a free 30 day trial, so get to it.

Gelato: Gelato is a dating site mixed with a social media aggregator. The premise is that your personality is reflected in your online behavior. Your profile consists of your Twitter account, Facebook status, Netflicks selections, and lots of other stuff available on the web. When combined, you get a picture of what sort of person you're looking at. I'm not doing the service justice in my description - check it out when it gets out of private beta. This is a real breakthrough in dating sites, not a me-too. There will be challenges, no doubt, but for the right kind of person (very active on the web and looking for a date), Gelato looks to be just the ticket.

Minutes Notice: Minutes Notice is a system that allows local businesses (coffee shops, bars, restaurants, anything really) to advertise across multiple outlets (Twitter, email, web widgets, RSS, etc) from one simple interface in real time. That last part is the most important. If a restaurant is having a slow period, they can blast out offers to customers in an effort to entice them to come in right now. Creating an offer is not much more complex than tweeting, and consumers can opt to receive these offers in a variety of ways through Youpons.net. You can choose to subscribe to a SMS feed of restaunart deals in the 78701 zip code, for example. It's a simple, flexible, permission-based system that has a lot of potential.

All in all, it was a good time, and I think we all got a lot of good feedback on our products. Check it out next time at DemoCamp V.

Fun With Government, Part 2

2009-04-17T09:33:00.000-05:00

Yesterday, I took a look behind the curtain of government backed commercial real estate loans. Today, I have a story that comes from the "you can't make this up" category. It involves everyone's favorite branch of the federal government, the always watchful TSA.

Back in 2006, I took an plane trip to San Jose. I've always been suspicious of airport security, at least since they stole my cell phone and a handful of birthday gifts years ago. But this time TSA was on the job protecting me, my stuff, and the American Way. On the way back from San Jose, they even left me a gift!

And here it is, the Official TSA box cutter that a TSA agent left in my suitcase.

In case you don't believe, here's a close up of the sticker.

For those of you who may have forgotten or are too young to remember, box cutters were precisely the implements used to hijack the airlines on 9/11/2001. TSA was formed in response to those attacks.

Today's threat level is orange.

Fun With Government, Part 1

2009-04-16T09:55:00.003-05:00

In honor of the horrifyingly complex documents otherwise known as my tax return, I bring to you this week some examples of some of the more interesting facets of our beloved US Government.

The background for today's story: Our real estate company recently purchased an assisted living property in Virginia. Since the debt markets have pretty well collapsed, we were thankful that our property qualified for a HUD-guaranteed loan (the HUD-backed loan market is alive and well). Sure, we thought, there will be a little more paperwork, but the terms are attractive (especially in this market).

I just got a package in the mail from our attorneys. Attached to a large stack of documents was a note containing the words, "unfortunately", "voluminous", "arcane", and "a few more documents". Apparently I had to sign a few more pages. In blue ink. (Don't you dare use black ink!) Not in duplicate or triplicate, but decicate, if that's a word. Scans and faxes aren't allowed. Only originals signed in blue ink, delivered the old fashioned way.

A picture is worth a thousand words (the tabs are required signatures):

And that is just the paperwork confirming that our company exists. We haven't even gotten to the loan documents.

Come back tomorrow for more Fun With Government.

Exploding Term Sheets and Entrepreneurship

2009-03-27T09:56:00.001-05:00

A pair of posts on TechCrunch got me to thinking about the concept of an exploding term sheet. Or more broadly, an exploding offer of any kind.

With the recent launch of Capital Factory, TechCrunch notes that the number of Y Combinator style incubators is increasing, and the niche is getting more competitive. So competitive, TechCrunch states, that some of the incubators are resorting to exploding term sheets to lock up good companies. Arrington thinks these term sheets are nasty beasts. I disagree - they're totally irrelevant.

The idea is that the incubator makes an offer with terms that are set to expire, sometimes very quickly. This puts a good deal of pressure on the entrepreneur to take the deal while they have the chance.

But here's the thing about exploding terms: they do absolutely nothing to change the dynamics of the marketplace - they are purely psychological tools and can be safely ignored.

I've seen them in real estate, for example. Such and such company will make an offer to buy a property, but the offer is only good for a week. Lets consider two cases to illustrate my point:

Case 1: It's 2007, and the real estate market is cranking at full throttle. The exploding term sheet is pure bullshit. The property owner has all the cards, and can react to an array of buyers in the time frame of his choosing. The exploding offer does nothing but make the purchaser seem flakey, because when push comes to shove, he'll wait.

Case 2: It's 2009, and nobody wants real estate. The buyer has all the power, because the seller wants out and there are no other buyers. If the seller delays too long, the buyer may find something else to buy. It's in the seller's interest to act as quickly as possible before the deal falls apart. The exploding offer again does nothing, since the market has already provided sufficient motivation to get things done quickly.

So when you get a term sheet with an expiration, ignore it. Act as quickly or as slowly as the realities of the market will allow.

And if you're on the other side of the table, don't make an exploding offer. At best you come off as pushy, and at worst, you'll be embarrassed when you don't follow through with a hollow threat. A better tactic is to simply state that the offer is good until it's not - which is really the truth of the matter.

FiveRuns Dash: Really Flexible Analytics

2009-03-20T10:26:00.001-05:00

We just installed Dash on BackupMyMail. Dash is a new product from FiveRuns that collects data from your Rails app and presents it in a form that Google Analytics users should be familiar with - charts, mainly.

Dash is great. The way it works is that you create simple "recipes" which monitor your rails app in real time. Setup is really easy, and the output is understandable by non-coders. You can track any sort of data that is important. It could be technical data (such as memory usage and performace information), or business data (such as signups or payments).

As an example of what you can do with Dash, I'll show a simple, but very helpful piece of data that we collected from BackupMyMail. We wanted to be able to tell when someone signed up, or when they tried to sign up, but failed. Within minutes, we cranked out the following chart, which is visible from our Dash dashboard (the data in this chart is not real - it's just for testing):

The yellow line is signups. The red line is failed signups. As you can see, when we tested our signup page with bad info, we got a red spike. I can just sit back and watch this chart and it will tell me when someone fails at the signup process. If I see a problem, I can go check the logs to get more info. When they implement auto-refresh, a series of these charts will go up on a monitor all day long.

Granted, this is something that could be accomplished with a custom admin section. The value that Dash provides is the painless implementation, which saves your developers a lot of time and headaches. Dash also presents the data so well that it's much easier to track lots of these types of issues at the same time, which saves the business guys a lot of time and headaches. Everyone wins - visibility into your app increases without having to pay a high cost in development time.

I've only scratched the surface of what Dash can do. I highly recommend checking it out.

BackupMyMail is Here!

2009-03-16T14:33:00.003-05:00

For the last six weeks or so I've been working on a new startup. The company does exactly what it's name suggests: BackupMyMail backs up your email.

What we do a little differently than others is that we backup your online email account (Gmail or Hotmail, for example) and store it in the cloud, where we keep it available for you to download if you ever need it.

The reason we started the company is simple. More and more of our important data is being used by applications that are hosted on line. We've become used to the idea that we should backup our personal computers, but are just now becoming aware that our online data is also at risk.

We would hope that major email providers would have a good backup scheme. To be sure, Gmail, Yahoo, Hotmail, and the rest all do have reasonably good backup measures. But that doesn't necessarily keep your email safe. Gmail has lost entire accounts. Not many, but it does happen. All of the majors reserve the right to delete your account. (This happened to me with my old Hotmail account. I didn't log in for 30 days, and when I finally did, everything was gone.) But the most compelling reason to manage your own backups is that you control the data. With BackupMyMail, you can go back in time and extract your account as it was then - before you deleted that customer's email.

BackupMyMail is in beta, and will be giving away free 30 day trials for the next few weeks or so. Sign up for one now and let me know what you think!

Note: the beta version of BackupMyMail only works with Gmail (and Google Apps mail), and is limited to 1GB of mail. Both restrictions will eventually be lifted (sooner rather than later, we hope).

You can also follow us on Twitter at @backupmymail.

SXSW is Coming!

2009-03-11T16:12:00.000-05:00

Welcome to Austin!

It's that time of year again - SWSX Interactive is nearly upon us. For you out-of-towners in for the week, check out the guide to Austin written by my friend and fellow entrepreneur, Chris Treadaway (aka @ctreada). And be sure to check out his new site Youpons.net for discounts from local merchants during your stay.

Lessons from Y Combinator's AngelConf

2009-03-06T14:34:00.005-06:00

Yesterday I had the pleasure of attending AngelConf at Y Combinator. It was a great event - if you couldn't attend, I highly recommend taking the time to watch (or at least listen to) the Justin.TV video. My comments on what I found to be the key points and issues raised at the conference (and how they relate to the startup world in Austin):

Angel investing is a full time job if done in a financially rational manner.
Some angels are perfectly content to knowingly act irrationally. Hey, it's their money.
Since angel investing is a hits-based business, deal volume matters. A portfolio approach is a requirement - the more deals the better. Getting great terms is less important than getting into great deals.
Getting into good angel deals is competitive. Only Angels who provide value - expertise or contacts - get to invest in the hot prospects. Naturally, this takes a lot of work.
Interestingly, since the most successful and prolific angels approach investing as a numbers game, negotiating terms is not very important. The process boils down to this: Find smart people that you like and trust working on big problems and give them money at fair terms quickly. Help them. Repeat. Repeat. Repeat. Nobody wants to do bad deals, but arguing over details is counterproductive. Again, the idea is not to make every deal a winner, but to make sure that some of your deals make it really big.
Good deals are very hard to recognize - that's why you need to do a lot of them. As soon as they are recognizable, VC's get into the game. You have to place your bets before that happens.
I don't think this works outside of Silicon Valley. There just aren't enough companies to develop a meaningful portfolio unless you're at ground zero. That doesn't mean angels outside of the Valley are wasting their time, but they are not likely acting in a financially rational way - they could make more money with less risk elsewhere.
If we want to see the same sort of explosive growth out of Austin companies that we do from Silicon Valley startups, we need more active, risk-tolerant angels looking at the region. That means we need more hyper-growth potential startups. Startups need investors who need startups who... It's a tough feedback cycle to start, which is why I'm keeping my fingers crossed for Capital Factory. Austin will never be Silicon Valley, but I'd sure like to see it get a good shove in that direction.

I've purposely not commented on the non-financial motivations for angel investing. That's a personal matter that will be different for every investor. There is a definite pay-it-forward element in the Silicon Valley angel community that was well communicated, even celebrated, at AngelConf. I don't want to discount that, as it's tremendously valuable.

It was a great event. I hope to attend next year as well.

UPDATE: Paul Graham has posted a great article on angel investing.

So Long, and Thanks for All the Capistrano!

2009-02-26T09:30:00.000-06:00

Jamis Buck has stopped development of Capistrano. I wish I could say I'm saddened by this, but I'm not. Let me explain.

Capistrano works. For me, it works perfectly. Perhaps I have simple deployment needs, but I can do damn near anything I want by typing the words "cap deploy". Deploying all kinds of web projects cannot get any easier. That is pretty damn cool.

So frankly, I'm glad Jamis gave it up. It's done, and I'm sure that he'll be on to more cool stuff in the future. Meanwhile, Capistrano is as useful as it ever was. So thanks, Jamis. And keep the good stuff coming.

Monitoring Your Brand on the Internet

2009-02-24T11:31:00.000-06:00

Jeremy Bencken has done it again - he's come up with another innovative use of common tools. If you're looking for a cheap (free) way to monitor what people are saying about your business (or anything else for that matter), this is exactly what you're looking for. It covers all the major "Social Media" outlets and is infinitely customizable.

Jeremy has pieced together several free web services into what amounts to a pretty slick system. It requires a little work to set up, but you can't beat the price. This is bootstrapping at it's finest.

He's even included a screen cast. Check it out.

Why $20,000 from Capital Factory is a Good Deal

2009-02-01T14:18:00.099-06:00

Last week, a group of successful entrepreneurs launched Capital Factory here in Austin. It's a program that is similar to Y Combinator (out of Silicon Valley) and TechStars (in Boulder - where I went to college).

Programs like these are great deals for young web entrepreneurs. Oddly, I hear the following complaint most often from these same young entrepreneurs:

"They want 5% of my company for $20,000. That's a valuation of $400,000 and I think that's a lousy deal. Angels are giving money out at $2-3 million pre-money."

The thinking behind this objection is all wrong. Yes, that 5% does imply a value of $400,000. But lets look at what makes up that value: an idea and the willingness of a few smart people to follow up on it. No traction required. No customers, no revenue, no actual proof of anything. Those $3M angel deals are very different animals - they have money, products, and often customers.

As one of my colleagues put it, it's $400,000 more than you had yesterday.

Second - the money that Capital Factory invests is not really an investment. At least, that's not how you should think about it. It's a vote of confidence. It's a signal to other investors that you and Capital Factory are serious. It's a test. What can you do with $20,000 of someone else's money? Can you create tangible value when given the chance? It's a way to convince your family that you're not off on some wild goose chase.

You are not trading 5% of your company for $20,000. Any motivated group of young entrepreneurs can come up with $20,000 very easily without giving up any equity.

No, you are giving up 5% of your company to engage a group of people who have an interest in your success and who have the ability to impact your chances for success. That's worth a lot more than $20,000. Not only to your current venture, but to your future endeavors. This is the stuff that makes ventures work. It's not about the money - it's about the people.

So why offer the money at all? When it comes down to it, the money is just a tangible symbol of seriousness - a way to communicate a sense of urgency and a glue to keep all the parties interested and involved.

So if you think you have what it takes to make a company from nothing, come to Austin - and let Capital Factory help.

Balsamiq Mockups is very good.

2009-01-29T09:47:00.025-06:00

At my new gig, I spend a good bit of time mocking up wireframes for a new web app. I tried Omnigraffle, Powerpoint, Keynote, and finally settled on Balsamiq Mockups. It really is a great program. It's simple and hyper-focused on one task - software mockups.

The user interface is trivial (you drag and drop screen elements onto the page and move them around). The learning curve is zero. But the best part is that the mockups are styled to look like hand drawings. At first I thought it was an unnecessary gimmick, but as I began to use it, I really appreciate the feature.

Seeing the mockups with their rough, hand-drawn look reinforces that they are mockups, not cast-in-stone specs. That is a very powerful communication tool when dealing with clients or bosses who want progress updates. You don't have to preface everything with "this is a mockup, not real software", or "this is a crude alpha" (how crude?). It's really great - people instinctively understand the stage of development just by looking at the mockups.

Balsamiq is a little buggy, but not in a way that stops you from working. And I wonder if that has more to do with Adobe Air than Balsamiq. In any case, I highly recommend it.

Note: The makers of Balsamiq give a way free copies to bloggers who write honest reviews of the product. I did not take advantage of that program - I paid for my copy and liked it enough to tell the world about it. I also have a selfish interest in that I want to be able to share Balsamiq files with others, which won't be possible until everyone has Balsamiq...

Changes

2009-01-16T21:22:00.002-06:00

My free time just took a nose dive. I've just started working on a new web business - a properly funded one with other people involved. So between that and my current gig in the real estate investment business I won't have much time to muck about with the ins and outs of my beloved web experiments.

The new business is a web company based here in Austin, and hopefully we'll have something to show for it in the coming months.

Onward!

Protect your Online Data

2009-01-06T09:33:00.002-06:00

Not a week goes by after my rant about online app security and Twitter gets hacked. Just days after Twitter users were tricked into divulging their passwords to a fake Twitter site, the company's developer tools were breached. Take a second to think about how bad this could have been. Or how bad it could still get.

Another case this week: Journalspace no longer exists. The company is gone forever, along with thousands of blogs. The company hinted that it might have been due to sabotage by a former employee. Obviously, it also took a healthy dose of complacency on the part of the company, but it happened.

Now, nobody is going to lose a whole lot of sleep if Twitter evaporates in a puff of smoke. (Well, most people won't). But losing a 6 year old blog can be pretty painful, especially if the author was using its SEO mojo to drive a consulting business.

What has me really freaked out is what would happen if it wasn't Twitter that got hacked, but Mint or Wesabe.

The interconnection of web apps is a great, but frightening trend. Make sure you protect yourself - and your data. This is an area of tech that is racing ahead, perhaps a little too quickly.

Web Security

2008-12-30T10:46:00.003-06:00

I've been noticing a trend among web apps for the past couple years. They want you to be very trusting.

As the new year rolls in, I thought I would take a look at some personal finance apps. Specifically, Mint and Wesabe. I saw a panel discussion at South By Southwest a couple years ago that included one of the founders of Wesabe. I was interested in the concept at the time, but thought I'd give them a little time to get their house in order. Finances are frustrating enough without dealing with "beta" software.

About the same time I heard about Wesabe's competitor, Mint. And Twitter was just beginning to explode.

In any case, I didn't make it past the second screen of the Mint or Wesabe signup process.

I love that there are new great things to be done on the web, but what I don't like is that all three of these apps ask me to trust them with an awful lot. Twitter asks me for my email password. You know, the same one that allows me to reset my password on just about every account I have. Wesabe and Mint take it a step further. They want my bank account password. I was blown away. They want access to the password that would allow people to withdraw cash or close my accounts.

If I walked up to you and asked you for your bank credentials and told you I just wanted to show you something cool, you'd probably want to punch me in the throat. But that is exactly what all of these sites are doing. They're saying "trust us - we know what we're doing."

And I want to trust. Heck, the guy from Wesabe seemed like a nice man. I practically met him at SXSW! But what about the guy he hires? What about the hundreds of hackers throughout the world who see a startup collecting bank info. I bet it's a lot easier to hack a startup than an actual bank... So why, again, should I trust?

I've been called paranoid for not allowing 3rd parties to have my email password. I suppose I am a little. After all, Google has it. I've even written a test app that asks for an email password myself (I never released it, however). But my bank account? The only ones who have that are the banks. And they're on the hook for my money.

So sorry, Mint & Wesabe. I want to use your products, but I just can't do it if you're going to ask me for the keys to my life savings.

How do we fix this? It kills me that I'd probably be just fine using all this stuff but I still can't bring myself to pull the trigger. The consequences of a breach, no matter how remote, are truly dire.

This strikes me as a huge business opportunity, but I haven't the foggiest idea how to solve the problem.

Starting with Nothing

2008-11-12T15:22:00.003-06:00

The internet is a small place. Out of the blue from across the Atlantic, I received an email from a gentleman named Peter Harris who makes films on the cheap. Turns out he used to own the domain 9thyard.com and was looking around for it. When he saw that the subject matter of my blog is starting a company on a shoestring budget, he chimed in with a show of support.

He also provided me with a teaser film he made for a total of £25. Check it out:

Equinox

No, it's not going to give Peter Jackson a run for his money. And some will say that such an effort requires a lot of "charity" from all of folks involved. True on both accounts. But to quibble with the true cost of such an effort is to miss the point.

Nobody smart will till you that you can sustain a business on pennies and dreams. I've said before that all great businesses will at some point take advantage of external financing. I still believe that. The message here is that you can produce something "good enough" one time for practically nothing. In fact, in order to get started, you will probably have to.

That "good enough" start just may turn out to be what it takes to begin a much bigger project that transforms into greatness over time.

If you have an example of a project that began from nothing and can show me how it all began, please let me know and I'll write it up.

Happy Birthday, USMC!

2008-11-10T10:10:00.000-06:00

And thanks for all you do for us.

Introduce Yourself

2008-10-09T09:17:00.000-05:00

It's been about two months since I've started this blog, and lo and behold, I have subscribers. Who knew?

I've also been contacted by three entrepreneurs who found me though this blog. All three have been great contacts that may be helpful to all of us some day. Which makes me wonder - what about the rest of you? There are quite a bit more that three people subscribed to this blog, and I'd like to get to know each of you. No matter how slight the contact, I have learned over the years that it's always a good thing to reach out.

So if you've subscribed to this blog, let me know. Tell me what you're up to and what you think of my project. There just might be some overlap where we can help each other.