48 Hour Start Up: What I Learned
My previous post I talked about the 48 Hour Startup. A small project that I set myself, with a small goal for building a MVP in 48 Hours. I failed, but in constraining time for the project I was able to learn a few valuable lessons.
Time Constraints Focus Development
“Should I spent hours tweaking the design, or making the layout perfect, or is it better to move on?” The answer when I have 48 Hours is “move on”. There is a time and place for perfection, and that is when the product is being paid for. Until you have a sale, you are building it for yourself.
Haphazard development is not something I advocate. Care and attention are important to the process, and should not be pushed aside. The time constraints made me rely more on the auto generation of controllers and views, and to not worry about tweaking every layout to exist in Bootstrap. Or, to worry about the way certain links display. If it does take steps forward, disregard it.
The project was never meant to sell, at the moment. I was more concerned with making the system available to meet a goal I set before starting — post a blog post to my Antelope Studios website. This meant that if changes were not in the service of meeting the goal, then I would not do them. But that didn’t always work. I spent too long making the Application page display just right, and too long making sure the database design was correct.
Time Constraint Limits Knowledge
Learning a new tool takes time. The theory of development is taught through low-level languages, that knowledge bubbles up and is applied to other languages. If the theory is taught, it can be explained in the real world, then learning new tools becomes easier. Learning new tools, with a time constraint, is a reasonable exercise. Learning new tools, while trying to rapidly develop an application is one level too many of speed learning — at least for me.
Sticking with my current tool set, and building an application while writing about it, made me feel inadequate. I have been using PHP as my main development language for the past 10 years, I enjoy using it. While I think the language has improved since it made a splash in the early days of WordPress, it has lost respect in the broader development community. I thought I could add in a new cog, and use MongoDB as the main database — maybe by changing that one cog I would feel a little-less obsolete.
Adding a tool to my skill set, while trying to get a product to life in 48 Hours is not the best time to learn something new. As much as it pains to say, I should have stuck with MySQL from the start.
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 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 the development language selected, imagine if Sony could have blamed the 2011 data breech on a the old development language an ex-employee selected.
The Minimally Viable Product
A minimally viable product is one that proves a market for a product or service. If the product doesn’t sell, then no market has been found. Thinking I could build a product without market research, or talking to potential clients who are looking for a tool like this, is a silly idea. An important part of creating a product is to seek information about where you should head and then building product for that market demographic. At least at the end of that pathway you know there is at least the idea of money, and potentially people who would exchange money for that particular product.
Right now, I have an idea, and a “Supposed Market”. I am not sure of the distance between my current idea and one that will begin to make money — so I still do not have an MVP. I have an idea in development. I will continue to make changes to it, because I have use for it immediately and can use the rudimentary functionality with it — kind of like living in an unfinished house. But I will need to do something to find a market, it won’t just find me.
Would I Do It Again?
The first website I built for a client, when Antelope Studios was started, I had thought of an idea like IchabodCMS, but I didn’t build it. A few projects I have been tasked with have needed a headless CMS, and it was the perfect time to build it fast. The time constraint helped me move forward on an idea that has been in the back of my mind for years. But, the irony is that it will cost me far more to build this as a service, than paying a monthly fee to an existing service.
I think working on restricted time frame showed me far more things to consider about my process than tools; It is making me reassess if the rapid development through Startup Territory is worth it, or if a scoped project is better before starting work. Just because I can build a website in 48 Hours, does not mean that I should. It certainly doesn’t give me the right to call it a Startup. It is a project.
The motivation was enough to get something “mostly completed”. A rapid prototype is more what I did — choosing speed over process — and for that it has been successful. It was a great way to build a prototype — and I think having a prototype is the first step to creating a Startup. To that end alone, I would do it again.
