weekends are for leisure

Never Again

Some business advice, and why I’ll probably never start another company if I have to do the paperwork and bookkeeping myself. Yet another post where I try to put things behind me and reflect on things I’d prefer to do differently next time.

Be sure you have enough to cover your unavoidable expenses for two years:

• Accountant fees. Plan on $700 a year. Make that $1500 a year. My accountant was a personal friend and gave generous discounts.
• State business operating fees. $50-200 a year.
• City and County license fees. $50-200 a year.
• Bookkeeping software or web service. Quickbooks was roughly $300.

Either find someone to take care of the following, or be a person concerned with being on-time and crossing every T, who enjoys reading PDFs from your state’s Dept of Corporations and the IRS.

• Business registration paperwork
• Renewing your business yearly
• Bookkeeping
• Quarterly payroll and income taxes
• Yearly payroll and income taxes
• Printing and mailing W2s
• City and County registrations, if required

Some things that further complicated my experience owning my own business:

• Moving three times in two years, which required updating addresses on my FL business registration, my FL Unemployment account, with the IRS, with the City and the County. There are probably other agencies I should have updated my address with.
• I had my business partner talk with my accountant when I should have done so since they were a personal friend. Mis-communication led to me having to file late forms and paying penalties.
• Changed my business from a three member LLC to one.
• Had some clients at the start, but totally neglected the continuous need to be drumming up work. If I had prior experience (aka success) with acquiring new clients, Greaterscope would probably still be in business.
• When we ran out of clients I had to invest some of my own money into the business to pay fees.

Luckily we had no expenses other than City, County, State, Federal and Accountant fees. We bought no equipment, spent nothing on advertising, used my personal host for the website, didn’t hire a graphic designer. It’s also unfortunate that we had no money to do the previously mentioned things.

Some other things that added to the bad experience:

• Waiting for my Schedule K1, and business taxes to be completed before I could file my personal taxes.
• Not having sufficient design experience, and not knowing a designer whose sense of style matched mine.
• Choosing to develop a product too large for our resources.
• Having to do by-the-hour web development to pay the bills while said product was developed, when it wasn’t what we wanted to do. Nor did we have the resources to do it well enough.

Whew. I have to keep reminding myself that it’s over. However, I just got a Census survey form for my business in the mail. When will the business-related paperwork end?!

Moving on

The newest news is that I’m no longer working on my storefront software. If I could get back all the time and energy I spent on the project, I’m not sure that I would, because I’d no doubt make the same mistakes elsewhere, on another project.

Of course, some post-mortem advice is product-specific, but here’s what I’ve learned and what I plan to look out for in the future.

1. Never underestimate the breadth and depth required of an ecommerce product.

2. Never go it alone in trying to compete with teams of people. The best abstractions and architecture won’t give you enough of a leg-up. Playing catch-up is still playing catch-up.

3. If your innovation makes up only a small piece of the pie, don’t waste your time making the rest of the pie. Be smart and stand on someone else’s shoulders!

4. Don’t get bogged down by ideologies about tools and architecture if you are not selling tools or architecture. I spent a lot of time creating my own abstractions, refining my tools, tweaking my architecture, because I thought they were better. My tools and abstractions have no user base to speak of so they were useless as an enticement to customers. I was trying to kill two birds with one stone:

   “See, my tools are great .. look at the robust application I built with them! Do you want to buy my product?” It is possible nobody was enticed because I SUCK at taking a product from prototype to “this apps looks great, functions great, I gotta have it!” If you don’t have that quality, find someone that does, or find a product you can make that doesn’t require this quality, or stick to pay-by-the-hour software development.

What were my innovations?

Here’s where I spill the beans. Briefly.

Layers on top of the core

All base functionality resides in core classes. Developers can make their changes in classes that extend the core. If you need to customize the logic that does X, implement your own methods that are involved in doing X. This extensibility was baked in from the start.

Every bit of text can be multi-lingual

The product table, which contained non-text data, was accompanied by a productTranslation table. Fields:

id, productId, languageId, title, description, ETC Repeat this structure for product options, categories, stores, and so on.

Product option combinations

A product can have any number of options (small, red, medium), which are grouped (color, size). Every combination of these can have its own price:

Small, red shirt: $15 Small, blue shirt: $14 Medium, red shirt: $14 Medium, blue shirt: not available

Tables: option (“Small”, in the “Color” group), option_combination (joins option to combination), combination (holds the price)

The logic required to make this all work was very tricky, but now it’s stable and robust. Alas …

…….

That’s all folks. Thanks for reading. And as always, feel free to contact me with questions, or if you want to give me money.

Another Exposé

Self-doubt has struck again. I’ve spent more than two years building this “thing”. But please don’t tell anybody because it’s a little embarrassing. Why?

• Because you often hear 6 months as the longest amount of time a startup should spend on a project for it to be considered “worthwhile”. I’ve spent more than 2 years. 37signals suggests an even shorter turnaround time of 1-3 months.
• Because I don’t have a network of people lined up to buy.
• Because I haven’t worked out exactly how to find the people that need what I’ve built.
• Because sometimes I wish I’d spent my time working on something more original.

At first I didn’t know what I wanted this product to be. Initially I thought about making a “set of reusable ecommerce components”, but what the hell does that mean? And how would that work, exactly? I don’t know. Eventually I decided I wanted to tackle multi-lingual functionality, and allow products to have an unlimited number of options that affect the product’s price.

Once I came up with a way to enable 100% multi-lingual coverage on the storefront as well as in the administrative area, and a way to support flexible pricing rules, I figured I might as well roll my ideas into a full-fledged shopping cart product. It seemed like a natural thing to do since it was inspired by frustrations with existing shopping carts. But what I probably should have done was find a simpler way to make money from my solutions. Something that didn’t require re-inventing a huge piece of software would have been ideal.

It might be possible to offer standalone components that can be plugged together to build a more feature-complete shopping cart product, but that’s tough work. Or maybe I could somehow package my multi-lingual functionality into something others could use for their websites and web apps. Either one would certainly be more niche, but probably not any more marketable than what I’ve got right now. Some combination of both is what I’m still searching for.

Here You Go

Caterina Fake included a quote from a friend on her post about Hunch. It goes like this. “If you launch something you’re not at all embarrassed by, then you’ve waited too long.” Hunch is a free web app, not a commercial product, so that advice probably doesn’t apply to what I’m doing. And no doubt, the Business of Software forum advice-givers would advise against what I’m about to do, but I’m going to do it anyway. What am I about to do? I’m going to post a public demo of my shopping cart software…

The product doesn’t feel ready (I’m a constant tinkerer) and it doesn’t look the greatest. You probably won’t mistake it for shit based on the design alone (layout, colors), but it still has a slight odor.

I’ve written a few blog posts saying “I’m still making progress” and “something visible is coming, hang tight”, but I don’t want to do that anymore. I want feedback. I want to give people the ability to decide whether they’re interested by giving them something to look at. Text flying solo will always fail to persuade and entice.

So check it. I set up an admin area and 1 styled store. The password to each is “yessir”.

Be constructive with your feedback. - Rhymenocerous

Licensing is Hard

I’m stumped. Here’s what I want:

• I want people to be able to customize my product
• I want people to be able to make money selling their customizations
• I want people to make money off their customization services
• I want people that have purchased a license to be able to use the product as long as they want

Here’s what I don’t want:

• I don’t want to create competitors by allowing them to take my product and sell it for a lower price
• This may or may not mean I don’t want people redistributing my product
• I want my product to live on. It shouldn’t be tied too strongly to me or my company.

To create more value than I capture I want others to get involved in, invest in, and benefit (profit) from my product.

What I’m particularly worried about are shops with more marketing-savvy and/or more customer reach; I don’t want to help them put me out of business. There is so much competition in this space, I can see it happening if I’m stupid.

Some of the normal arguments against restricting redistribution and derivative works are:

• Would-be competitors won’t take the time, nor will they have the agility, to take my product and make it their own before I can succeed
• The peer-review benefit gained from open sourcing and encouraging distribution will pay off

I’m not convinced (yet).

The Past Few Weeks

It’s almost the middle of March, thus only two more weeks until I’ve missed my “first quarter 2009” target. Don’t worry, I’ve not been idle…

The main areas of focus have been documentation, screenshots (not yet available), the privacy policy, and more content for my website. Turning bland features into attention-grabbing benefits has been ongoing for almost a month at this point, and I’m increasingly pleased with the results.

On the design front, I’ve enlisted the help of an artist to add more flare to my site. The hand-drawn icons she has created portray my sense of humor, and add something special to my otherwise lonely sea of text. You can also see more of her work at daubery.com.

For about an hour or so I toyed around with freeprivacypolicy.com and a few others that come up in Google search results for “privacy policy generator” and “privacy policy template”, but they didn’t work out so well. Then I found mention of Automattic’s Privacy Policy on the Business of Software forums. Their policy is Creative Commons licensed, and they encourage you to tweak it to your needs, which didn’t take me too long. After some find-and-replace work and a once-over to remove all the verbiage pertaining to wordpress, round 1 of Privacy Policy creation was done. Round 2 will involve making sure what I’ve tweaked is compatible with California law, but that’s for another day.

Round 1 of PHPDocumentor docs is also complete, but the docs aren’t quite publishable yet. It was a big task, and involved writing scripts to automatically inject PHPDocumentor style comments at the top of class definitions, which helped jump-start the task in a big way. Additionally I began documentation focused on installation and customization, even though it is pretty fledgling at the moment. Either way, it gives a feel for how we compare to other commercial shopping carts.

On the menial task side, I imported United States postal code to city/state mappings, and Canadian provinces. Now I can display both countries in the country dropdowns. Selecting Canada brings up it’s own set of address fields (Province versus State) to show we’re not locked to the United States addressing system. To facilitate this, address field generation and validation is delegated to “country helpers”. These helpers know exactly which fields are required for postal addresses (and phone numbers) in their specific country, how to validate those fields, and how to present them. So if a storefront needs to work in a new country, the programmer should only have to create a new country helper.

Last week I make good progress on Paypal PayFlowPro, ViaKlix and Authorize.NET payment processor integration. But this week I decided to focus solely on Authorize.NET for the first release, since it was easy as pie to obtain a developer testing account from them. It’s time, once again, to start cutting features that aren’t essential for the first release.

Oh, I almost forgot. I spent about two hours skinning a demo store, but it’s not quite finished yet. Soon we’ll have a demo that actually looks like a real storefront.

That’s it for now. Licensing will be the next pile of legal shit I attempt to launch over, in additional to final preparations for release. But that’s misleading, there are many things left to do before release: publish rewrite rules, create a MySQL schema, fix some data on the order details page, prepare demo for storefront and admin. See, that’s not too much, right? I’m leaving off about 20 items that can wait until release 2.

Benefits not Features

Seth Godin says marketing should start before a product. This sounds strange when you take it literally. The Business of Software forum participants say you should focus on benefits, not features. These pieces of advice go together. When developing a product you must have the big picture in mind, which means an answer to the question “why are you making what you’re making?” The answer to that should, at the very least, center around meeting a customer’s needs. Ideally, your product should also make life better for your customers, and provide value and benefits not found elsewhere…

At this time, my product doesn’t really have a list of benefits. The difference between benefits and features is subtle, but at the end of this post hopefully it’ll be more apparent. Maybe the difference between “what it does” and “what it does for your customers” is an accurate analogy.

Here are my product’s current features, which are more about what the product can do.

• Proper solution to the “complex product attribute/pricing” problem
• Freedom to customize AND get updates
• Every bit of text can be displayed in multiple languages
• A full year of free updates

Number one is horrible because nobody knows what the hell it means. Number two sounds ok, but the benefit isn’t explicit enough. Number three’s wording isn’t as clear or direct as it could be. Something like “translate your storefront with ease” would be better.

To help me out I had to look at the verbiage for some other successful software products. Here are the benefits for the Bingo Card Creator software.

• Take the busywork out of bingo
• Tailor your activities
• Keep students interested in learning
• Teach almost any subject
• Never buy another bingo product

And here are the benefits for Balsamiq Mockups.

• Improve your Usability. Explore Different Designs in Minutes
• Get to Agreement Early with a tool everyone can use
• Cut down spec-writing time. Spend your time coding, not churning
• Use it with your clients. Let them help you bring their vision to life
• Integrated in the way you work

The benefits for Bingo Card Creator and Balamiq Mockups are non-technical. They outline what the user of the software gets by using the product.

While focusing about this, I’ve realized my benefits are beneficial to differing audiences. My product doesn’t have just 1 user. This makes things a bit more difficult for me, but I think it can be dealt with through good website organization.

Being a programmer, I want my product to make other programmers happy. But programmers often work hand-in-hand with a graphic designer when setting up a storefront; designers are directly affected by my decisions as well. And of course, the third party affected is the retailer. All three are “users” of my product, so I might as well outline the benefits for all three. Makes sense, right? Maybe I’m making it too complicated. Time will tell.

For Programmers

• Customize with less pain.
• Software updates won’t squash your customizations.
• Never again retrofit multi-lingual functionality.

For Designers

• Skin faster. Easy to navigate templates, simple syntax, no abbreviations, easily discernable template logic.
• Translate storefronts with ease.

For Vendors

• Customizations and branding are less painful for your development team.
• Grow your customer base by selling in other languages.
• Sell any type of product.

Now it’s time to work those into the website. Any thoughts?

Last Week

Last week I made some changes that may seem small, but should go a long way in making it easier to understand the code and customize the product…

• Finalize the use of ISO codes as primary keys for country and language tables. This removes the need to follow integer foreign-keys back to these tables; the ISO code should make it easy to tell which language or country you’re dealing with.
• Create the concept of a country helper — a class that knows which address fields are necessary for specific country, and how to validate and format them.
• Make state model work with country helper.
• Work country helper into single page checkout. Add Canada as a proof of concept.
• Make databased sessions more robust by registering a shutdown function (register_shutdown_function()) and closing the session in there, rather than in the destructor of our controller class.
• Rename address fields to work better with international addressing.
• Simplify and comment flow of logic in single-page checkout code

Last Week

Holidays are a great time to make progress.

• Add Registration and Sign-In functionality to single page checkout
• Use ISO codes for language and country primary/foreign keys. Makes it much easier to get around when you’re mucking in the database.
• Make dashboard statistics work
• Use width in resized image filenames. Allows images for all stores to be pulled from the same location if needed (http://images.storedomain.com/images/), while allowing each store to have its own size for thumbnails/medium/large/etc images.
• Populate the database with states, languages and a few countries
• Make core controller more aware of databased sessions (must write and close the session before HTTP redirects)
• Ability to throttle the number of active sessions in the database, for when I put up an official demo.

I’m happy with the progress, because it means both the storefront and admin areas are getting closer to full usability.

Delete functionality was big on my list, but I’ve not reached a solution I’m comfortable with yet. But that’s for another blog post where I’d love to hear your thoughts on the subject.

Site Fork

The last two weeks have been a holiday blur, so no weekly updates. However …

Lately I’ve thought about creating a separate website for my product. I do think it’s a good idea, as it will be a pure place for stuff that’s only related to the product, but I don’t see the need just yet. That sort of thing will come when I’m feeling more momentum, which will come when the following are accomplished in roughly this order:

• Choosing a name for the product
• The code reaches a more usable state
• I get the word out and have more genuine interest
• Documentation is written and is ready to be put on the site
• I decide how I’m going to cultivate a community for the product