So the widget was roughly done by the next evening. On Monday night, I emailed lifehacker, not really expecting much. Here are some charts with the usage patterns over the first 30 days since then.

This is a chart of pageviews for the widget. You can see the huge jump on Tuesday May 22nd, when I was luckly enough to have lifehacker post an article about the widget that morning. It basically set the level of use moving forward.

This adds up to a lot of pageviews in a month. If these were hitting one of my servers, it would be enough load that I’d be worrying a bit about spikes of traffic and slowness. Fortunately, one of the design goals these widgets have is to use no server resources of my own: all code runs in the browser, and all data is stored in the settings of the widget itself — Google’s servers. So these could grow to 10 or 100 times the traffic, and I wouldn’t loose sleep at night. You can also see that for these iGoogle widgets, unique views tend to run about half the pageview rate.

This is a good rate of usage, but still not yet quite enough to qualify for Google’s new Gadget Ventures program, which offers seed funding for selected widgets with over 250,000 page views per week. With a little more press or an increase in organic growth, it’s possible it could hit that level.

One of the requests that came in early was “how about the same kind of thing for counting down the days until a future event?”. There were already many countdown timers, but not one that tracked several, with easy UI for add/remove and annual recurrence. Starting from the Days Since code, two weeks later the Days Until widget was written. But what would the conversion rate be, if this widget didn’t get the same level of press on a site like Lifehacker? Here is a 30-day graph over the same timeperiod as the one above.

Around June 10th, I added a mini-message to Days Since, advertising the Days Until widget. I didn’t know what kind of conversion ratio would happen — but these are clearly related and complementary things, so it turned out to be surprisingly high — today, it appears that approx 25% of Days Since users became users of the Days Until widget.

Between Days Since and Days Until, there has been about 13,000 unique users of the two widgets so far in this first month. Some startups would kill for that level of unique users, but it’s just getting interesting here for the widget world.

So where does this go from here? The level of usage so far makes me feel good that the relatively small investment of time is delivering value to the world — a few thousand people are finding it useful, and there’s been some really kind comments on the blog and in email.

From a business model perspective, there isn’t a direct one yet. By showing what’s possible, and what Leancode is capable of, it could generate some leads (particularly from companies which want to create a closer connection with customers by providing widgets that tie into their products or services). And you could imagine creating a portfolio of time management widgets, some of which are higher-value and could have premium versions.

But, for now, this is just a fun and interesting experiment.

I’m a believer in a set of thoughts and techniques that fall under the banner of “lean thinking”: finishing things in small batches, lots of feedback, a continuous improvement approach, and other related techniques.

Much of this comes from my experiences working at large companies, but I’m experimenting with applying it here at Leancode on a very small scale.

If you want to read more of my thoughts on this stuff from a theoretical perspective, check out the Lean Software Engineering blog.

And if you want a wider perspective, a new site and feed called Planet Lean aggregates together this writing with other great writing on Lean in general that I like. If you’re also interested in lean topics, and have any thoughts on making this better, please let me know. And perhaps I’ll see you over at Planet Lean.

So we advertise. Well, actually, I haven’t bought any adwords yet, being the cheapskate that I am, but the smart people advertise. And the smartest people of all are the people running the ad networks. That is, Google. Millions are gambling, but Google is the House. You may win or lose, but the house will always get their share. In this case, with all the ads flying around, the house is now a $150b dollar company.

So what if a bunch of buddies just get together for a friendly game of poker? No house. No cut. In the online ad world, this used to be called ‘banner sharing’, and it mostly went the way of the banner.

What’s old is what’s new again. A new, free service called adGridWork has been getting some attention. You put an ad block on your page, and you get an ad which is displayed on the other member sites.

The more click-throughs you generate, the more impresssions you get. Unlike the old banner sharing systems, adgridwork is trying to learn from what Google got right about ads: unobtrusive, relevant, helpful. They match the ads to pages based on keyword, etc. (although the matches so far are not that great — perhaps as the body of ads increase, they can be targeted better).

They’re a donor-supported-service so far, but I wouldn’t begrudge other forms of revenue. For example, they have a very specific, motivated audience showing up at their site to configure and re-configure their ads — adwords ads here might generate good click-through (with a cut to the house, of course).

So you’ll notice the “free ad co-op” block on my right sidebar. It’s other people like me trying to make people aware of what we’re doing. Feel free to click — nobody will get paid, but you’ll see a related site, and I’ll get the ad for this page displayed in a few more places. This blog doesn’t get a huge amount of traffic, but I’m happy with what this network has steered my way .. traffic is up 29% in the days since joining the network.

And the house won’t get quite as much of a cut. A little competition and a few more options that way can only be a good thing… right?

One of those things is what legal entity to choose for your business. The IRS needs to know who is earning all that money you’re making off adwords (snark), and everyone else needs to know what rules this business will be operating under.

It’s fine to do this kind of small web business as a sole proprietorship where you may have no special paperwork to do until tax time in the US, and just use your own SSN to identify the business. But then there is no separate corporate entity. Everything, including liabilities, pass through directly to you.

So, for the third time now, I faced the choice of which legal structure to choose for my business. It’s one of those drop-dead boring, but still important decisions you have to make. Here in the US, the basic forms are Sole Proprietorship, General/Limited Partnership, Single-owner LLC, LLC, S Corp, and C Corp. Each form involves different rules (especially for taxes), and different levels of complexity and cost at first, and on an ongoing basis.

What form was chosen each time and why?

Enteraction

In 1996, two high-school buddies and I created a PC-based multiplayer gaming arcade called Enteraction, with the storefront in our hometown of Hollidaysburg, PA. We choose to create a partnership because there were 3 of us, and since we were all fresh out of college, liability wasn’t a major concern. Two of us would be “passive” partners, one “active”.

Some people are fine with verbal agreements, but it’s smarter to be very clear and up front about everything, especially when friendships are at stake. So we went through the trouble to write up and sign a formal partnership agreement (based on a standard template).

The partnership form worked for us through more than a year of operation, and ultimately dissolution of the business. We realized we could pay the bills, but not a reasonable wage for our active partner. The breakup was amicable. An LLC would have also worked well, providing more protection with a little more up-front cost, but as it turns out that investment would have been wasted.

Cosource.com

In 1998, Veriteam, Inc. was formed with the goal of creating a full-fledged, go-big-or-go-home startup. I had been working an employee at a another successful startup (S3, Inc.), and wanted to follow that model. Investors would eventually be involved. So the company was formed as an “S” Corp, which allowed us to have a few sophisticated investors, but also simplified taxation to pass profit and loss through to the owners like an LLC or partnership.

As many startups do, the business totally changed direction at one point and became Cosource.com.

Through those changes, recruiting employees, private investment, and selling the business to a public company, the S corporation structure worked well, and I’d choose it again in the same circumstances.

Leancode

This time around, I’m trying to create something that will start small, get successful, yet stay sane by not having to take on investors or go public. It’s a different kind of business, and the S corporation would introduce cost and complexity that isn’t justified. So Leancode has been incorporated as a single-owner LLC. This form creates a full corporate entity with it’s own EIN (instead of a personal SSN) and some liability protection, while being treated much like a sole proprietorship for tax and other purposes.

Will it ultimely be the right form for what Leancode becomes? We can’t know yet, and the world isn’t going to fall apart if it isn’t — with a little paperwork and some tax filing headaches, a switch of legal entity could be pulled off. But a little footwork up front can avoid troubles later — perhaps at a time when you’re busy doing cool stuff, and can least afford to take your eye off the ball.

I’ll post next on how a lawyer can fit into all this, but if you’re the self-study type, the book I’ve used in the past and would recommend is The Entrepreneur’s Guide to Business Law (the 2nd edition is from 2002, I’d recommend pre-ordering the coming 3rd edition).

“And of course they had a christening party. And of course they invited the fairies…”

They say software is never done (and everything will take 4x as long as you’d think). They’re right. So you have to call out milestones and give names to things to get your bearings. And so I hereby knight this small service called chartpart. We’ll call you “beta” and send you off.

Feedback is critical in software development, but it’s not always easy to figure out what the customer is telling you. In the case of chartpart, I got lots of good explicit feedback (thank you). I also got implicit feedback in the form of hits and general interest level.

This feedback led me to realize I was trying to do too much with chartpart. Dealing with the complexities and commitments of hosting images. Serving up flash, and sparklines, and tracking trends (all things for which there is nearly complete code in source control).

The site and the business model behind it need to be far simpler, at least to start. And so you’ll notice some significant changes to chartpart, done in the last week for beta. The site now generates images, but does not provide hosting. And the site aspires only to be a small, useful ad-supported tool. If there will be more, it’ll come later in a separate form.

Complexity builds on itself. Fortuately, simplicity is also reinforcing. For example, more than one request came in to simply allow the pasting of spreadsheet data. And it could have been done. But with a focus on being a free chart generator, not a chart hosting, we’re clearly not trying to compete with spreadsheet charting engines. The guidance would be: “use your spreadsheet if you have one at hand, chartpart if not.” So the feature is less essential with our simplified use cases.

Please use chartpart, if you find it useful. And please mention it if you find it interesting.

For me, chartpart has been a great first project to learn (and re-learn) a ton about web development, and especially Ruby and its libraries. It now needs time to bake and find its niche (or not) — collecting use and feedback over a longer period. And I need to start thinking about a second project.

Enjoy!

For chartpart, the high-level design should be simple — making use of existing components as much as possible. The actual application is a stable, well-thought out API for requesting a chart (A URL which fully describes it), the code to transform a GET request into a chart image, plus a nice helper form to create those URLS, and other information.

The Gruff library is where the heavy lifting of charting happens, and a few small changes were done there already and passed back to Geoff Grosenbach, Gruff’s author. The chartpart app (as thin as it is), is not open source. But enhancements to all the libraries under it will be (and must be, in the case of GPL or other licenses) passed back.
Partially because of Ruby’s dynamic nature and good cross-platform tool and library support, there’s another interesting thing to note about this diagram — there are a lot of fundamental components at the bottom of the stack (e.g. what OS it runs on), that can be entirely substituted. In fact, chartpart has been developed on a mix of Windows, Linux, and Mac platforms as I’ve played around at finding an environment that I like best (I’ve settled on a MacBook). And the actual hosted environment of chartpart.com is Linux today, but might be Solaris tomorrow.

Anything wrong with the approach or diagram? Any thoughts or concerns about mixed license models?

Some I’ve selected over the years include veriteam.com and cosource.com (both now defunct), Vistasource (funny enough, several years before Windows Longhorn was renamed Windows Vista). Now leancode and its stable of small web projects, including this first project, a web charting service.

What we’re shooting for is a name which is short, memorable, a reminder of what the company or tool does, BUT one that’s not so specific that we can’t make small or large changes in direction without changing names. Combined with the inherent uniqueness requirement of domain names and the gold rush for them, this is difficult to triangulate.

The best tool I’ve found for helping this process is Instant Domain Search by Beau Hartshorne. His tool keeps a cache of the current WHOIS records and provides a wonderfully quick AJAX-style interface to try out lots of domain names, getting instant feedback about what’s taken. I’ve used it lots over the last year — I hope the adwords on the site have made Beau some bucks.

So what’s a good, available name for a charting service? How about chartpart.com? A little rhyming never hurt. And these web services are not destinations unto themselves — rather they are some part of a larger whole. Seems appropriate. What do you think? And check out the site for a taste — mind the remaining beams and scaffolding.

1. Free, ad-supported version
   This is what 99% of your users will choose, and where maybe 5% of your revenue will come from.  Sounds like a bum deal! But we know the threshold where a customer will part with their money for software is high (just look in the mirror). You need to have them use your stuff, understand you, believe in your value, trust you, and rely on you before it’s worth their while to pay you.  On the bright side, the cost of providing this free service largely serves as your marketing budget.  This is your cold-call salesforce.  These are your demo/sample units. And nothing grows mindshare as quickly as the right service, offered at an irresistible price.
2. Premium ad-free subscription
   Maybe one in every few hundred users will find your service useful enough, important enough, that they want to get serious and lay down their dollars to get more.  Get rid of the nonsense (advertising).  Know that you have their back today, and tomorrow (service level agreements).  And provide some extra features to give them their money’s worth. This might be where 25% of your revenue comes from.
3. Licensing
   As a customer, it’s wonderful to have someone else hosting your software — not having to worry about installing, maintaining, etc.  And you don’t have those big, up front licensing fees. But it’s like giving your car keys to a stranger.  It’s a no-no having corporate data floating around on someone else’s servers, on the Internet, and out of your control.  You have a firewall, and you want your corporate data to stay within it.  So the hosted web service is a great way to play with the software and see what it can do for you.  But at that point, you want to be able to say “sell me your backend software, so I can deploy it on my corporate network”.  Or, perhaps better, make it an appliance or a VM.  And this is where 70% of your revenue as a “hosted services software company” will come from.  Back to the future.

Companies that use this 3-tier approach are everywhere.  How does VA Linux (LNUX) make money on sourceforge?  Why does Google sell an appliance search box?  But there are still plenty of companies that stop at tier 1 or 2, and they may be leaving most of their opportunity on the table.

There’s no magic analysis. From a lean perspective, it’s a matter of triangulating at least 3 things:

1. What are the market opportunities/needs
2. How close is the available technology to filling them
3. When can our group fill the gap vs. our competition

For a lean-style micro-isv, we would hope for projects that can launch in weeks, not years. In my case, it’s been 7 years since I’ve done this kind of development. I’m starting from zero on nearly all the technologies I’ll be using to create these web sites and web services: ruby, rails, lots of gems, css, subversion, new editor, etc. I know It’ll be slow going on the first projects. And as I experiment with openly blogging about this project as I work on it, the time window of my head start will be short.

For these reasons — and all the other reasons why short iterations, feedback, and adjustment are important — I have to be especially cautious about scale to keep the project managably short.

Personal interest in the space is also an important factor — even with trying to keep each project as small as possible, it’ll still be a large chunk of life working on it.

Data visualization has gotten my attention in recent years. I’ve spent a bunch of time on large software projects. Large-scale software development is an amazing challenge. Microsoft, which does a lot of it, has been pursuing a strategy of collecting and analyzing a ton of data for the purposes of managing their projects. So much data that it’s simply overwhelming. If you can’t summarize it with charts, teams can’t really digest it. Both inside Microsoft (where they can throw people at the problem), and on the wider Internet — we don’t have tools yet to make this visualization easy enough.

There is competition in this space — one can search for companies offering charting, graphing, visualization web services. This is a good thing, as long as there is breathing room for technical or business model innovation. http://www.graphmagic.com/ is one example, that offers 1000 graphs for $12.95 a month (with lots of other pricing options) with a free trial that requires registration.

There are interesting new ideas around for doing things better, like Joe Gregoria’s sparklines service . This is a wonderful example of taking a underused form of visualization, and making it more approachable with a very well designed, simple site for creating the images, and hosting so the images can be easily included on other pages. I’d like to see something similar which makes it as easy to create larger visualizations.

And there are some exciting technologies to build on. Geoffrey Grosenbach’s awesome Gruff library, manni.us’s beautiful SWF/XML charts, and web frameworks like Ruby on Rails to speed development.

So, out of a long list of potential ideas, this one seemed to stand out as one where the need, and the technology gap to fill it, seemed to be a match. Instinct backed up by a bit of analysis.

And, in typical lean fashion, I shouldn’t be betting the farm on this one project. I should complete several projects in a year — and expect that I’ll have several failures and a few successes. It is through that feedback loop with the market that leancode as a business can succeed.

For those pictures, we already have many vertical market sites which provide great charts (http://finance.yahoo.com/ being one common example for stocks, etc.). What we don’t have is a service — and a business model to support it — to bring this kind of data visualization to the “long tail” of other data on the internet. Charting for things like: bugs or checkins to open source projects, historical government spending, census data, or the # of daily classified job postings in your field etc, etc.

In order for that to happen, you’d need a freely available service which lets you point it at data, generate nice charts and visualizations, and have them be hosted so you can link to them from web pages, blogs, wikis, discussion boards, etc.

This is not a big business — there are limits to how much this visualization is worth to people. And for one-off stuff, you can always hand data to your buddy who is handy with Excel. But it’s a nice niche, and it’s part of a much larger category of knowledge mangement and data mining tools, which is an area of work which I love for some reason, and keep getting drawn back to.

What do you think — is this something you could ever imagine using (or seeing someone else use)?

But ideas are cheap — it’s really all about execution. For that, see coming posts.