Custómica was an an online t-shirt store for the Argentinian market where all the designs were user-contributed and anyone could design their own t-shirt.

You can get the source on GitHub here.

I started working on Custómica in January 2010 and launched in June 2011.

I’ve learned a lot about tech startups and entrepreneurship since I started working on Custómica, particularly about lean startups and reducing waste. I realized about fundamental flaws in my core idea only after investing a huge ammount of time building the product, and eventually it was clear to me that this project had little chance of succeeding.

Still, I decided to carry on and launch the application. Even if the business failed, I figured it would be a great learning experience. Plus, I could get a return on the time I’d invested so far in the form of a nice addition to my GitHub profile if I finished the thing and put the code online instead of letting it rot on my hard drive.

I launched Custómica in June 2011 at a meetup of the Lean Startups Buenos Aires group and got a bunch of helpful feedback and constructive criticism.

Six months later, Custómica still hadn’t gained any significant traction and had produced zero sales. Time to call it a day.

The application is still running in read-only mode, and will continue to do so indefinitely.

The idea

Custómica as an idea was nothing new; there are lots of custom-designed t-shirt stores out there (most notably Zazzle, CafePress and Spreadshirt.) The big difference from its American and European counterparts was its social integration.

Users would sign in using their Facebook accounts, and the application would post to their Facebook walls any new t-shirts they designed. This would hopefully attract some of their Facebook friends to the site, generating sales and/or new t-shirt designs.

What went wrong

I never validated my hypothesis. I should’ve built an MVP and tested the idea before investing so much time building the product. Turns out, only a very small fraction of my users (less than 1%) actually designed new t-shirts. I relied solely on Facebook wall posts as my customer acquisition channel, so traffic growth was severely limited by the content-producer-to-consumer ratio.

I attacked the riskiest parts of the project last. For instance, I assumed I could print designs on t-shrits of any color, only to later find out that the only technically and economically feasible printing process in my reach was limited to plain white t-shirts.

Crowded niche. A lot of new players have emerged in the alternative/custom-designed t-shirt scene in Argentina since I’ve started working on Custómica. Most of them use Facebook Pages as their primary means of promotion and offer a big selection of professionally designed t-shirts.

Couldn’t compete on neither price nor quality. Professionally designed, batch produced t-shirts are usually printed using higher quality techniques that are only economically viable in large quantities, such as screen printing. Custómica was limited to inkjet transfer printing, which not only results in a poorer quality product, but is also limited to white t-shirts. In addition to that, production was outsourced, which translated into little margin for profit.

Wrapping it up

Seen through the lens of the lean startup method, Custómica was the perfect example of what not to do. My biggest mistakes were not testing my market assumptions and tackling the trickiest parts of my plan last.

My advice to my future self (and anyone reading this) is stick to the books and talk to people. There are many places where you can ask for advice and bounce ideas off people who’ve been there and done it, my favorite ones being Hacker News and the Lean Startup Circle. I should do that more often.

About the code

Custómica is a Play application written in Java, running on Heroku. The t-shirt designer component is built with Adobe Flex. I’m releasing the code under the MIT license. Feel free to get a copy and do whatever you want with it.

Thanks

I’d like to thank all my friends who’ve encouraged me to pursue this project. It was a terrific learning experience and I have improved immensely both as a developer and as an aspiring entrepreneur because if it.

Are you developing Facebook apps? Does this picture look familiar to you?

This happens when you’re developing a Facebook application locally using the http://localhost:8080 URL to test your app (or whatever port it’s listening to) and you try to log in using your Facebook account.

The reason for this is that the JavaScript SDK expects your app to be running from the domain you’ve entered in your app’s settings page.

I’ll transcribe the error here so this article can be found from search engines more easily:

API Error Code: 191
API Error Description: The specified URL is not owned by the application.
Error Message: redirect_uri is not owned by the application.

The usual workaround

Assuming that your application’s domain is mywebapp.com, your first attempt at circumventing this problem would probably be to add the following line to your /etc/hosts file and comment it out when you’re done testing your app locally:

127.0.0.1	mywebapp.com

The main problem with this is that you end up editing the hosts file all the time, which can be pretty inconvenient.

A better approach

A less painful way to fix this is to define an alias just for a subdomain, e.g. local.mywebapp.com, and use that alias instead of localhost when you’re developing locally:

127.0.0.1	local.mywebapp.com

This way, you can test your app locally using http://local.mywebapp.com:8080 and forget about editing the hosts file ever again.

This works because the JavaScript SDK sees that all your URLs belong to the application domain.

Check out my newest app: Calendator.

Calendator lets you quickly generate printable calendars right from your browser. Great for sketching your schedule, drafting estimates during a meeting and as a regular calendar that you can stick on your wall.

The app is inspired in David Seah’s Compact Calendar. I’ve been using the Compact Calendar for some time now and I’ve found it to be a very practical and fun tool. However, David’s calendar is year-long, and I usually only need to mark dates that are three or maybe four months into the future at most. Also, sometimes I need to mark dates in the next year. So, out of necessity, I decided to put together this little tool. Try it out.

Stack

Calendator is a pure client side application. The interface is built using Twitter’s Bootstrap toolkit, the CSS is preprocessed using Less, handling of dates is done with Date.js and everything is tied together with jQuery. Source code available on GitHub.