5 ways I screwed up my first website

Growing up in the time of the dot com bubble was a surreal thing. In 1999, I was 16  or 17 years old, and a junior at the University of Washington. I had started using the Internet early – as a progression from playing with BBSes to using apps like gopher and archie/veronica at the public libraries. Anyway, it seemed like they were handing out money left and right in Silicon Valley, and I figured that my friends and I were pretty much as smart as everyone else – so why not start our own website?

But first, we needed an idea. It turned out that I was about to rent an apartment with one of my best friends, Jake Kreuzter, which turned out to be an enormously annoying experience. We ended up wandering around the UW, calling phone numbers as we walked around, because there was no centralized place to find apartments. There must be an easier way!

So we decided to start Local-Rent, a website where local landlords could post their apartments and people could go rent it. After coming up with this idea, we recruited a couple other friends from the Early Entrance Program that were really smart and reasonably technical. This included our good friends John Richmond, Thor Sletten, and a bunch of other people. This larger group also entertained other random ideas beyond Local-Rent.

This large group, however, did not go well. It wasn’t clear what people were going to do, and slowly but surely, people got bored and it was left to 3 of us. (Jake, John, and myself)

We started building the site, but went way overboard. This, in particular, was my fault. (But remember, I was 16 at the time, so sue me) We started coded stuff up in PHP and MySQL, but we came up with a massive schema and lots of features for the website. We had tables for tenants, landlords, apartment complexes, individual apartments, transactions, rental agreements, the whole thing. Note that this was all speculative, since we really didn’t understand too much about the renting business anyway, and we also completely focused on the technology.

One thing led to another, and we ended up having a really complex application – in fact, in the living room we had put up a bunch of Post-Its representing the structure of the app, and it was huge. Furthermore, we started by coding up layers within the application. So rather than working on the user interface and all of that, instead, John and I ended up building an ORM (object relational mapper) for database rows to get instantiated as PHP objects. As an aside: It was a neat experience, from a software engineering point of view, since we didn’t know ORMs existed as a general concept and it just made sense to us. So now, to see stuff like Hibernate and ActiveRecord is pretty cool.

Anyway, after a couple months of working very hard and getting no where other than the backend infrastructure, we gave up. The feature list seemed huge, and it seemed like we’d never get to the end.

In retrospect, it was a fantastic experience. It was great to understand some of the tendencies that you can get wrapped into – and the entire engineer-as-entrepreneur thing is especially hard because it’s easy to get sidetracked by technology rather than users. So even though it was a colossal failure, I’m happy I wasted a summer doing this when I was 17. It was fun in itself, and I became a better person for it.

In the end, we never finished the site, but years later, it would become very exciting to see Craigslist succeed. Although our idea was really a subset of what Craigslist has become, it makes me happy to see a community, locally-focused classified section where random people post sublets, residential housing, and other rental opportunities. It somewhat validates the thinking of a couple eager teenagers with PHP h@x0ring skillz :)

All in all, I learned a bunch of really important ways, by screwing up:

1) It’s easy to bite off more than you can chew
When we first started, we defined way too much stuff to do. It was fun to dream up the "next big thing," and people with big vision also tend to go overboard with this. But the practical reality is, defining something really big can be demoralizing. It takes too long to build and see results, and you take on a ton of risk by making your invention a big, high-stakes bet instead of a bunch of little bets.

Instead, the right thing to do would probably be to define the vision, make that your North Star, but then step back. You’d look at all the little micro-releases you could do to build up to your North Star, and start to go from there. If you have to integrate some things, do it incrementally, and not all at once at the end.

For Local-Rent, it would have been better to make a little forum-like application for people to post generic listings right away, and try and reach out to rental people. Probably the project would have gone to the next level right away, as we started thinking about the major business hurdles to seed this kind of marketplace.

I see people making this type of mistake even now – you’ll hear startup people that need to be in stealth for one or two years for a consumer media application. It’s just silly. Launch your site already!

2) It’s easy to chase shiny-technology things, if you’re a nerd
This applies to me, but maybe not to everyone. It’s often tempting to use each startup opportunity to learn something new, and thus, take on additional technical risk. In our case, we really, really didn’t need an ORM to make the business work. So why did we work on it? Because it was fun :) Thats a good reason if the goal of the project is to play with technology. But it’s a bad one of you actually want to get stuff done.

Hilariously, I still find myself making this mistake from time to time now. The fundametnal aspect of it is, I do these types of startup projects to learn new technical things anyway. That’s an integral part of the goal. But getting too distracted is bad, and I can catch myself easily from that standpoint.

3) More people at the beginning isn’t better
Although this didn’t create too much of a problem in the long run, it seemed like a really good idea to bring in lots of smart people early on. We brought in friends just because we thought they could contribute one way or another. Frankly, it’s just distracting. You end up creating busywork that doesn’t need to exist in the first place, just to give people stuff to do.

The group eventually evolved into a mix that did balance out. You want everyone to be able to contribute very concretely in the beginning. So no finance people or business people that just muck around with PowerPoint and Excel. That is 1/2 of one fo the guys’ jobs. Instead, you grab one or two engineers that are really good at shipping stuff really fast, and you have one business-y technical guy. (In recent cases, I’m the latter). That way, you can focus on making things rather than talking about making things.

4) Focus on the customer (and make it concrete)
Another symptom of playing around with technology instead of focusing on the business was not talking to any customers. Although Jake and I, as renters, were part of the consumer market, we really should have spent a lot of time with the other side of the equation (homeowners) as well as potential partners (classifieds, newspapers, etc.).

The right way to go about this is to be very specific about your target audience, and vet ideas and prototypes with them first. I’m a huge fan of thinking through and incorporating user personas into your design process. If you and your developers are arguing about whether or not "Landlord Larry" really uses the site in X or Y way, you’re on the right track.

5) Failing ain’t so bad
And finally, as I mentioned above, trying this project and then giving up was a rewarding experience. I learned about lots of stuff that didn’t work, which then implied some hypotheses around what could work. And although your ego can take a hit, at the end of the day, you’ll forget it and be happy that you learned so much.

As soon as Local-Rent was over, it only took another year to dream up something else and try it. This time, we had a lot more success getting it off the ground. I’ll write more about that project some other time.

Exit mobile version