Entrepreneur: I have an idea for a web app that will revolutionize the [blank] industry, and make us bajillions!

me: That’s great! I can tell you are passionate and excited, and that’s critical to your success. But do you have enough cash to pay for this coffee?

Entrepreneur: Yes, we have some funding to get started. And I have a business plan explaining our strategy, and I have a powerpoint deck of what the product does.

Me: That’s even better! I’ll have another espresso then.

Entrepreneur: We’d like you to get us started on our website development. Here’s our feature set for beta release. How long is this going to take? How many people, and what other stuff do we need?

Me: Ummm….and that’s where the conversation gets difficult. Because the business plan doesn’t go into great detail about the product (it shouldn’t), and the powerpoint slides have a bunch of boxes and arrows but don’t show what the screens look like or what actions the user takes, we can assume the founding team hasn’t thought much about how people actually use their product.


So at this point in the conversation, I face an uphill climb. I have to explain to (and convince) my client that they have a lot of hard work figuring out how their users are going to use this tool to accomplish their tasks, what those steps are, and what they look like. I have to tell them I don’t know how long this is going to take, and I doubt anyone else knows either.

Most of these conversations end with me suggesting some homework for the founders. It’s kind of a toolkit of useful things that you probably need, but it’s definitely not everything you need. But it’s a start.

• read “Getting Real“, the 37signals book. PDF, online, or print version, I don’t care. Read it, and know it. When in doubt, consult this book. When not in doubt, consult this book and make sure you are still on the path. I hate to use the word ‘bible’, but it’s the closest thing we have. It lays out the process of building a web product, from concept to delivery and beyond. If you’re under 25, I guess you can real Paul Graham too.
• setup a server on slicehost for development (for rails, anyway). Easy, cheap, and upgradeable.
• likewise, set up a subversion repository to hold your source code on svnrepository.com. You could host your own, but I like the peace of mind I get knowing my source is backed up and secure. As a bonus, you get a Trac instance for bug tracking, and it includes a wiki and other tools to make developing your web app easier.
• hire a designer, probably a freelance one, to draw some wireframes for you. Give them lots of your time, because that’s how you’re going to figure out what exactly your app does. This is probably the most important person on your team right now, and you should be focused on this. Ideally you can find a good reference through your network, but if not post a well-crafted ad on craigslist and look at their portfolios.
• At the same time, you probably want a developer to start working on your site. Maybe the developer came first, and she’s found someone designer-y to work with — even better. Just get some stuff down on paper so you can discuss it, scrutinize it, see what works and what doesn’t. If your designer is good, and you’ve spent enough time with them describing what you want, they should have something workable.
• Start building your product. Get your developer, or outsourcer, or nephew or whatever to hack some code.
• Your developers are probably following some sort of Agile process like Scrum. You should be seeing new features and changes on a daily or weekly basis. This is important, so you can play with your app as it is being born and give some feedback, change it, and make it better. If you’re waiting weeks or months before peeking, you’re doing it wrong. Good chefs taste as they cook.
• Once you have something you like, and works, and does what it’s supposed to, consider doing a limited release. Announce to your friends and families, have them play with it, ask for their feedback. If you can’t get your loved ones to pay attention to something you’ve been slaving over, well, that’s not a good sign.
• While you’re at it, put some site monitoring on it like site24×7.com — so you’ll know if you get swamped with too much traffic from Digg or Slashdot or nytimes.com, should they write about your site.
• Go slow. look how your userbase is growing, if it is at all. Get some more users — email more friends, or blog about it, or buy a few Google ads. Setup Google Analytics to track visitors to your site, and learn what is working and what isn’t. Measure, always measure.
• Get more feedback. Listen to your users. Make them happy. As your userbase starts to grow, spend some time thinking about how you can handle the extra load.

… and that’s about it. You’ve just built and launched an app. Hopefully, you have some users and they like it,maybe even willing to pay for it. Maybe it sucks, and is a stupid idea. But more likely, it works, has some flaws, and could use some work. So work on it. Improve. Iterate.

Of course, what is considered ‘best practices’ today may not be the preferred methods of tomorrow. So I read a lot to stay on top of where the industry is going. A have a million feeds in my Google Reader account, but only a handful I consider invaluable — including TechCrunch, Found+Read, Read/Write Web, and Signal vs. Noise.

Joost Bonsen, who has long been involved in fostering entrepreneurial activities at MIT (including the Developmental Entrepreneurship seminar, the Nuts-and-Bolts of Business Plans IAP seminar, and the 50K / 100K competitions) is on the exec team for the new center. I’m very excited for Joost, his hard work in this area deserves this kind of support.

I ran into Joost Monday night at the Muddy Charles pub, where he was hosting an event for MIT entrepreneurs and friends. Also present were Cory and Erica of IntutiveAutomata, makers of Autom, the weight-loss coach robot. It’s an interesting idea, that a human-like device pushes our social and behavioral buttons in a way that keeps us motivated — more so than a website or other low-touch support system could. I’m curious to see what the results of their clinical trials are.

It turns out, ruby compiled wth gcc 4.0 on powerPC macs — which my laptop is one — is known to exhibit these strange behaviors. David Heinemeier Hansson himself mentioned this in this blog post.

Turns out, the solution is to set gcc to 3.3 mode, rebuild ruby and any dependent libraries. You can do this with ‘gcc_select 3.3′, then running configure, make, make install as usual.

On the way to finding this fix, I tried updating to Ruby 1.8.5 patchlevel 2. To get this to work, I had to configure, make, and install, then go into the source tarball in ext/readline and run :

cd ext/readline

> ruby extconf.rb

> make 

> sudo cp readline.bundle /usr/local/lib/ruby/site_ruby/1.8/powerpc-darwin8.9.0

Those instructions came from this mailing list archive.

So if you’re running ruby patchlevel 2 — which is the latest ruby that works with rails 1.2.2 — make sure you compile with gcc 3.3, and copy over the readline bundle as described above.

I’m pretty disappointed this much hackery is required to get ruby working on my machine, which is a fairly standard platform. Ruby should “just work” with gcc 4.0, and the Makefile should do the right thing with the readline module as well. Grrr.
In the near future I hope to get an Intel mac to develop on, and have access to all the latest ruby/rails goodies on that. But at least now all my tests are passing, and I’m not getting any more strange Fixnum errors.

More details when I return…

This post will talk you through the basics of database tuning. Ready? here we go:

1) hardware is important.

Ideally, your mySQL server will be on its own dedicated box. Sharing it with Apache and the rest of your application may be fine starting off, but eventually you’ll want a dedicated machine for it. This also helps establish the right infrastructure for scalability, so you can add more webserver boxes which all connect to your database machine.

So of course, things like RAM (speed and amount of), disk (speed and size of), and CPU horsepower all matter. Get as much as you can.

2) get the right tools. To even begin to tune the performance of your database, you need to be able to measure it. So get some good tools like

* mytop (monitor mysql queries and performance)
* ab (apache benchmark, for load-testing apache)
* top (cpu/memory performance, process management)
* iostat (disk/cpu performance)

and and learn how to use them. Test your database using whatever queries and scenarios your encounter in your ‘real world ‘ application. As you tune you want to see queries per second go up, and time per request go down.
3) you run top, and find that your database is occupying 99% of the CPU. Now what?

If your database is thrashing, now is the time to take action. Start by looking at your sql queries in your application. Turn on ‘log slow queries‘ in mysqldb — this will show you which sql statements are slowing down your db. I had a situation where I was calling ‘.lower()’ on some columns before doing string comparisons in my application, but this was unnecessary — mySQL is case-insensitive by default, and using .lower() was causing my indexes to be ignored! So go through all your SQL statements very carefully, and pay special attention to the functions you call and any that show up in the slow queries log.
4) create good indexes. Indexes make queries on your tables go faster. Creating the right indexes is a fine art, but for starters create an index on everything in your WHERE clause. If there’s more than one column in your WHERE clause, create an index that covers both (or all) those columns. Make sure your indexes are being used by running ‘describe’ on your queries, for example : DESC select * from items;

This will show you what indexes are available, and which ones are being used. Do this for every query in your application.
5) Tune some mySQL parameters on the server. Some basic ones are query-cache-type and query-cache-size (to turn on query caching), and thread_cache_size (to enable thread caching). Turning on both of these should help.

At this point, you should have a reasonably fast database; you should also see your CPU usage for mysqld go way down. But to make your entire app run smoothly, you’ll want to take a look at how mysql interacts with apache (httpd). Although not everyone uses apache for their webserver, chances are you do, and if you adjust some of the apache params things will get even better.

For example, if Apache is set to allow 200 max connections, then your database should never get more than that number of simultaneous connections (one mysql connection per apache client), so you can scale back those attributes — which should free up ram and CPU.