Tom Markiewicz

The lessons learned from the failure of my company are going to be in no particular order, so I decided to start with one that I’m already applying to my next project - creating admin tools as early as possible.

With FeedCraft, we took the approach of getting the application launched as quickly as possible with the main features we needed (which I think was wise, but I’ll have some thoughts on this in later posts). In the rush to launch, we put off developing admin tools such as user management, basic content management, and some support related items.

Simple database scripts written in SQL (that steadily ballooned) managed many of these tasks with the initial thought that 1) we didn’t have many users yet and 2) we would add in a robust admin system after launch when we had the time.

I think you can see the obvious problem here. You never have that time after launch to create these tools. The same logic that stopped us from developing them before launch (lower priority) kept them from being developed after launch. There was always something that appeared to be more important in the grander scheme of acquiring revenue.

Unfortunately, the ability to better manage your business, while not always directly correlated to immediately generating income, is often overlooked in the beginning. It’s quite easy to forget about the cost of our time, especially as founders, but it quickly adds up with each task that could have been automated or made more efficient by building admin tools.

Over time there were too many tasks that were not in one central location, enabling others a simple way to manage them.

Here are a few examples of some of the parts of an admin interface that could be added for maximum impact at the beginning of an application’s development as opposed to the middle or end:

• user management (add, edit, delete, activate, deactivate)
• role management
• content management - basic addition, updating, and deletion of content on the site
• CRUD functionality for relevant models - updating content that will be displayed throughout the site; ex. categories, account types, etc.
• support - ex. manage contact forms, feedback, support requests
• e-commerce support - within your own app and not directly on the gateway’s site

Adding admin tools does not need to be a major, separate project. The approach I’m now taking is to add admin functionality as needed along with the rest of the project.

I learned the hard way about putting administration off, so now they’re added directly on the product roadmap so we don’t overlook them.

Popularity: 37% [?]

Many say you learn more from your failures than your successes. I believe this to be absolutely true in business as well as most other aspects of life. And you can also learn quite a bit from the stories of failures from others.

So, as promised when I announced that my company was shutting down, I’ll be posting a collection of thoughts on what I feel are some of the big learning lessons in this experience of running an Internet startup and its subsequent failure.

When I talk to non-entrepreneurs about what occurred, I often get a sad “I’m so sorry that happened” kind of reaction on the startup’s failure. For an entrepreneur though, it’s honestly the opposite sentiment (or at least it should be in order to be successful).

Failure for an entrepreneur is like a badge of honor. You will start another company and now you have the benefit of a whole host of prior mistakes than can hopefully be avoided. Very few successful entrepreneurs have had success without failures (usually large ones) along the way.

This may sound like a rationalization of business failure, but there are numerous examples.

Many of my lessons learned will be in relation to a web-based startup, but even these still tend to be applicable to any business.

Either way, I hope the examination of my specific mistakes help other entrepreneurs (and those looking to become one) and spark further discussion so we can all learn.

Popularity: 46% [?]