kitify « Justin Dunham - 's journal about making things

Building Kitify, my first modern web app (in Rails), Part 3

Filed under: Everything Else — Tags: development, javascript, kitify, prototype, rails, ruby on rails — Justin Dunham on September 20, 2012

The first prototype of the Kitify front page. Notice I use the phrase "1999-style page reloads".

v0 of the actual site.

This entry is the third in a series about Kitify, a web app I built that was intended to let DIY project creators easily sell kits for their projects. You can see all the published entries by clicking here.

Once I had the initial research for Kitify done, I moved on to what I think is the most important actual research step, which is building a functional product. The difference in feedback that you get between “here’s an idea, what do you think?” and “here’s a product, will you use it?” – and indeed, seeing whether people do use it once you let them know about it – is huge. I also like building things, so it would have been hard to keep me away from this step regardless!

First, I put together a mockup of what I thought a very early alpha could look like – the core of the product. In retrospect my plans for the core of the product were probably too simple, but I was focused on coming up with a feature set that could be put together relatively quickly and cheaply. I built some mockups in Balsamiq and annotated them heavily in order to fully convey everything that needed to be built, while I looked for a software engineer who’d be willing to do that for me.

Through a friend of a friend, I found an awesome developer who had real interest in the product and was therefore willing to take a bit of time to build the prototype for me. During the initial phases of the project, I learned just how out of touch with modern web development practices I was. I knew how to code in PHP (extremely helpful in being able to talk intelligently about design decisions), but I didn’t realize how (relatively) easy Ruby on Rails and other modern frameworks make it to build a fairly polished user experience, just as a foundation.

You then have lots of flexibility on top of that to build all kinds of technically-complex features that normal users take for granted, such as frequent communication between the server and client without page reloads, animations, and other snazzy UI components. My mockups say that page reloads are OK, but if you are working with a good web developer, you more or less get AJAX communication for free, for example.

The prototype looked really good and allowed me to gather more feedback about the idea and be taken (marginally) more seriously in receiving that feedback. As I mentioned, the main problem with Kitify wasn’t that nobody wanted it, it was that they weren’t willing to pay enough; it attracted the most expensive and difficult kits for sale since kits that are easier to produce become independent businesses.

Sending my initial prototype out to potential customers, and business partners, gave me some clues as to other directions Kitify could take, though I ultimately ended up not pursuing these.

How the site looks now.

Once the prototype was built, I had to decide whether to build out a full application with all the features I thought were important for it to be a real product. The prototype wasn’t big enough – it couldn’t be used for much. But building out the full feature set I imagined would allow me to do tests with a real product that would actually encapsulate some of the assumptions I had been making (for example, what kinds of kits people would put on the service). In retrospect, there were probably cheaper ways to test my assumptions but, as I said, I like building things.

However, to get all these features built out, I would either have to pay a huge amount of money, or wait a very, very long time for the engineer I was working with to complete the project in his free time. I figured I’d better learn how to build a fully-functioning, modern web application – I already knew Javascript, but it was time to learn Rails.
I’m good at learning from prototypes, so I started with what my engineer built for me, and went from there. For about two months, I worked full-time on getting what I would consider a “version 1” of Kitify built. You can check out the code here, or the site here – in the course of building the site I had to do lots of interesting stuff, like learn how to implement AJAX file uploads (by far the most time-consuming piece of the final product).

Eventually I learned that it’s much better, when you get stuck, to look for a simpler way of doing things rather than press on through. Problem-solving abilities can be a liability because you lose the heuristic of figuring out a new way when a problem seems impossible to solve.

The file uploads are a good example of this – what happens now on Kitify is that you click a file upload button, and you get a popup that lets you actually choose which file to upload. For a couple of weeks, I was obsessed with making it so that the file upload button led directly to a file upload dialog (no second button press) in all major browsers. It turns out this is impossible, and… actually doesn’t matter.

Comments Off

Building Kitify, my first modern web app (in Rails), Part 2

Filed under: Everything Else — Tags: amazon, concept statement, do-it-yourself, kitify, mechanical turk, pitching, surveys — Justin Dunham on August 4, 2012

This entry is the second in a series about Kitify, a web app I built that was intended to let DIY project creators easily sell kits for their projects. You can see all the published entries by clicking here.

The first thing I did when starting to work on Kitify was (attempt to) validate the idea. There’s a lesson in this very process, which is that in retrospect I would have worked on Kitify no matter what the results had been, thus largely defeating the purpose of doing the experiments and surveys! Nevertheless, I’ll talk about what I did, and how, here.

Concept statement

The concept statement is a great tool that lets you succinctly , yet thoroughly, summarize a business idea, how much value it will create and for who, how much of that value you expect to keep and how, and why it will survive competition. The elements are (a) name, target customers, benefits, product form, and price, and (b) differentiating attributes and how they will be achieved, and (c) cost. Here’s the product statement for Kitify:

Kitify makes it easy and fun for do-it-yourself project creators to document, share and sell kits for their projects, via web-based “kit creation software” and a backend logistics network for selling complete kits when requested, at a price of 90% of kit revenue.

Kitify will be differentiated from Instructables, MakerShed and other kit sharing and selling sites by integrating project creation software with the business and operational capabilities necessary to sell products.

This will be achieved through modern web development frameworks that allow complex web applications to be built reliably and quickly, and backend software built to make pass-through ordering and processing quick for Kitify.

The approximate cost to deliver the kit-packaging service will be half of kit revenue, and a relatively small amount per month for providing the kit creation software.

Surveys and primary research

After informally talking about the idea with some friends, and also getting some feedback based on an informal video describing the idea, I ran some surveys on Amazon Mechanical Turk. Mechanical Turk is great for this – it’s cheap, it lets you build surveys quickly, and a reasonably broad segment of the American population is available for surveying. (Note that while this is true in general, the Mechanical Turk respondent population is skewed toward lower-income participants, which means that while you can get some participants from most demographic segments, you’ll need to pay extra to run enough surveys such that they participate.)

I ran a few surveys, mostly concentrating on how much markup people would expect over the parts cost of a kit, and what sorts of problems they faced in building projects in the first place. I also asked a lot of questions about do-it-yourself habits. One of the problems with the Kitify idea in general is that a lot of people who are interested in doing do-it-yourself projects are doing it to save money – which Kitify’s business model doesn’t help with.

Of those respondents who had completed do-it-yourself projects, about 70%, home improvement and construction projects were the most popular. These would also be the hardest for Kitify to deal with, unless we teamed up with Home Depot or some other large retailer that could take care of the shipping and logistics for us (potentially an interesting future idea).

I asked a lot of questions about specific experiences with projects, as well. One of the things I was most interested in was why people did do-it-yourself projects, and what problems they were facing. These would be important in figuring out whether there was a problem for Kitify to solve. I phrased these questions as assessments of respondents’ agreement or disagreement with particular statements. For example, I might ask whether participants did DIY projects to save money, or whether they did them for fun.

A chart showing the various problems people have had with do-it-yourself projects.

Here’s a summary, but interestingly, most participants did experience problems or worry about completing projects, but tended to complete them anyway. Participants did not seem to have problems actually tracking down parts, also. You can also view the full survey results, and download them, here.

Pitch decks

Since I happened to be taking an entrepreneurship class at the time I was developing Kitify, and since I ended up raising a (very small) amount of seed funding, I ended up writing a couple of pitch decks as well. The video here is my one-minute pitch presentation, which I used to assess initial interest in the idea.

There’s a lot of advice on writing pitch decks on Google and the various hacker blogs, so I won’t reiterate any of that here. I ended up focusing on the basics of the idea: the size of the market, why and how much customers would be willing to pay, and how we’d expect it to work. I’m good at presenting ideas and convincing people, so this was a fun exercise, though not at all helpful from the perspective of launching the business. I think the most amusing part was coming up with a set of financial projections.

Comments Off

Building Kitify, my first modern web app (in Rails)

Filed under: Everything Else — Tags: diy, kitify, kits, rails, rubyonrails — Justin Dunham on July 27, 2012

Kitify logo (created in Powerpoint, actually)

This entry is the first in a series about Kitify (source code), a web app I built that was originally intended to let DIY project creators easily sell kits for their projects. You can see all the published entries by clicking here.

Kitify makes it easy and fun for do-it-yourself project creators to document, share and sell kits for their projects, via web-based “kit creation software” and a backend logistics network for selling complete kits when requested. (Check it out if you have a moment – it doesn’t even require an account to get started!)

I got the idea for Kitify while building this vacuum-forming machine. The Instructable for this is great – it only takes about $100 worth of parts to build something that will make impressive, cool-looking plastic molds. But it took me forever to actually track down all the necessary parts, including a couple of wasted trips to Home Depot.

I thought it’d be great to have a service that accepts an Instructable, like the vacuum-forming machine instructions, as input. The business then boxes up all the parts that are necessary to build the project, and ships you that, as a kit. That’s what the name means, too – Kitify is a service that makes written instructions into kits. We’d make our money through a large markup, which consumers would be willing to pay since they wouldn’t have to spend time and money on gathering parts.

The real competitive advantage a company like Kitify could build is kit-building knowledge:

Where to source parts (so you’ll pay us for finding components for you)
How to get them cheaply (so we can maximize our profit while charging plausible prices)
What the correct parts are to buy (so you’ll pay us to ensure you have the correct parts)
Advice on assembly (so you’ll pay us for the time we save you)
Custom-made parts that make assembly easier (saves you time, and makes sourcing easier for us)

Since DIY is an increasingly popular pastime in the US, and one that I’m personally passionate about, I thought this would be a really interesting idea to pursue.

Over the next few entries, I’ll write about the process of researching and building Kitify, which included a fair amount of market research and a lot of writing pitches (both of which were probably superfluous in retrospect), and finally learning how to write a proper, modern web application in Ruby on Rails.

Comments Off