The 48 Hour Startup: Time Just Ran Out
It is done. Finished. Time has run out. 48 Hours after I started working on my small start-up idea, I am done. I am not complete, but I have run out of my allotted time
The stash of files in my repository, that have not been commited is large. There are a few issues within GitHub to tackle. The project will continue forward. By the end of today I would like to have a public face deployed to a server, and a link I can send around to show the front part of the system off.
There are log entries of what I was have been working on, a few days where I was writing blog entries (Day One, Day Two), and I kept a few images and thoughts on Tumblr. I feel happy with what I have accomplished, but also disappointed that I didn’t approach the project in a different way.
Different Way, Different Approach
The idea of a start up is to see if there is a market for a business idea. The creator does not approve the market for the product, it is the market that makes a choice, either approving or rejecting an idea. My project, while it may be useful for me, is in no state to show to the market – there is nothing public facing at the end of 48 hours. If I was to launch right now, I would not be in a position to make a sale – there is no elevator pitch, no example of what is working, nothing that shows the worth of the idea.
Approaching it in a different way, would be to build the marketing stories first. Spend time on the design and the web presence at the beginning, and allow the back-end to fill out later. This change in focus would have been more impressive than abject failure in a public space.
Always Be Moving Forward
A forward step is better than nothing at all. I got stuck on a few things that ended up being the death of the project. There was a time when I was chasing my tail, after a single line of code that said
Content instead of
Website. The last part was running into CORS issue with my cross domain calls, and realising that I didn’t want to hack my through it – some things are worth doing properly.
Stick to Known Tools
Stick to what you know and understand – it makes you faster. I thought I could be clever and pick up new things along the way. Nope. I should have stayed with what I know. If you know PHP, build in PHP. If you develop with Microsoft Frontpage, then use that. This is not an exercise in experimenting with new tools, not just yet. Refactor and update other pieces a little later. Shipping is more important.
For a long time I was going to build the database in MongoDB. A flat style data structure is all the rage, and it is a tool I wanted to use more. My experience with MongoDB has been in non-commercial, and being honest, I was a little ashamed of using a traditional LAMP stack in a public experiment.
Despite what the industry is saying, and what direction the industry’s tools are moving, the end user is not going to care about the tools you use to build a brilliant product. Consider Amazon, I don’t know anyone who shops at Amazon because they use Perl. Nor, do I know of a business who has been able to blame any data loss on a language, imagine if Sony could have blamed the 2011 data breech on a language and the public accepted that…
The market cares about your product and how you handle their data. The language is a personal and business decision, rather than an industry decision. All that being said, I am going to go back and restructure some parts of the system, and add some extra bundles for collating information for tracking interactions in MongoDB.
Time Constraints a Good Idea?
Is it a good idea to put a time constraint on a new project? Development projects should not be rushed. Doing a good job is better than rushing through some important decisions, I would have preferred to think and consider database things more, I would have preferred to tackle the cross-domain issues a little longer.
Constraining creative endeavors breaks old habits, and forces innovation – sandbox rather than to be contained. Iterate. Work, and move forward, don’t look back.
This small project was perfect for that, forcing me to keep working and not get stuck on small issues. I was happy leaving some templates with the generated forms and moving onto the next thing. By placing a deadline on what I was working on, I was able to make more progress in 48 hours than I would have at a normal pace. Sure, it is with familiar tools, but I was able to create something new. Something I can build upon, and that was the destination in the first place.
Would You Like to Play Again?
This project has been drifting around for a few years. I have a use for a tool like IchabodCMS. I had been thinking of building this three years ago when I started Antelope Studios, but decided against it – I have my excuses and none of them are good. Recently, some of the projects I have been working on have needed a service like this, but we don’t want to spend money on paying for existing services. That aversion to spending money has been a great motivator.
The irony is that it will cost far more to build this as a service than paying a monthly fee to an existing service.
Being aware of the market the product is entering is important. Spending time researching competition, and building to your companies strengths, improving on what the competition does badly, is great for market separation – especially for a new company. Spending 48 Hours developing a product, with bad market research, can lead to an idea that dies as soon as it enters the marketplace. But that was not a consideration, I skipped this part to build a product – not sure about this just yet.
- I like how constraining time makes me think differently. I don’t like how I am leaving parts incomplete along the way.
- I like how constraining time builds a project quickly, and it comes to light faster. I don’t like how I am choosing familiar tools, rather than tools that are better suited to the job.
At this stage, 1 hour after failing to complete the challenge, I would say I am willing to do it again. If not for learning about failure, then for learning that I am not my ideas. Looking back, I worked fast, and failed to think differently about the product, but I did build a large part of a service I want to be using – and now I have come this far why would I leave it alone?
Image taken by Benjamin Child