Suggestions for a Startup Web Company

mochaone asks "I've always admired the Slashdot crew for putting together a great site that has vastly contributed to the internet experience. I have an idea for a website that I think has great potential also. I would like to know how slashdot (or any other webcompanies) got started and what tips they might offer? Should I use webhosting services or provide content on my own computers? What's a typical server setup -- separate boxes for web servers, database, banners, etc? T1 line or T3? How often should I backup data if providing content on my own computers and should I store backups offsite? Any other tips are welcome. More interested in the high-level, architectural issues rather than the "Use Debian over Redhat" or "Use Python over Perl" issues. I think those have been covered in other Ask Slashdot features. "

Comments

Load balancing - the easy way

[toofast]

I use different boxes for different type of content: ordinary Pentium 100's for the static pages and PII-350 + for dynamic content (perl, c++, asp). You could add a server just for images and graphics.

This type of load balancing is real easy, but it's not fail-safe: if one server dies, all the site is affected. That's why I have a few old boxes with replicated content that are ready to rock in case a server dies. All I need to change is the IP.

A T1 line is not very hard to saturate, and to some extent, only one server could probably manage the whole static/dynamic/graphic content.

We have a T1 line and host our own content. This way you get much better control. We use one tape backup per server, and investigate our logfiles as to when the best time to backup is. That's typically 3am for us.

To think about...

[sporty]

• Co-location vs dedicated own
• Much bandwidth can incur more charges in a co-lo
• Co-lo's have less responsibility for facilities, line maintenance, etc...

• Backups
• 
  Daily if not half daily. Do full backups at least once a week and incrementals in-between. If you could do full's everyday, all the better. If you can also do redundancy, that would kick butt too, but redundancy (what?) redundancy (what?) is no replacement for backups. Take backups offsite. A must.

  As for services, have a different host-name for each service... so if you wanna move your database off of your web machine, www.myhost.com still hosts the web and db.myhost.com still hosts databases.

  Make sure to use the latest (or at least clostest) to the newest stable unix you can. Make sure you keep your software up to date security wise and feature wise when it is intelligeble. (If we are on HTTP 1.2, you should probably upgrade to keep up on standards.)

  Other tips, make sure you have a policy for the machine. Even if its for 3 people working on the machine, if rules aren't established early on, chaos may ensue when conflicts arise or the company grows. Most important, be openminded to learning. But you seem to have that. ;>
  
  ---

Have you thought of a market?

[mr]

You need to answer basic business questions 1st.

What is the market you are serving?
Why are customers going to come to you, and keep coming back to you over others?
Does anyone in your group of people understand basic accounting?
Do you know how to run the accounting package you have chosen?
How are you going to link this accoutning package to your business?

And the REALLY big one:
Do you have the money to do this?

Sweat, blood and credit card advances only go so far.

Go to the public library, any of the small business web sites, and even (gasp) the IRS and do some reading. They will tell you ALL kinds of questions you should be asking. Like Insurance, type of business org., etc.

After you have done the above mentioned research *THEN* start wondering about DS1 or DS3, colocation, etc.

...

[Signal 11]

How to "work the web" for dummies:

• Patent everything. If you can use a mouse with it - patent it.
• If your product sucks, blame Microsoft. Even if it doesn't, Microsoft is the reason nobody knows about it.
• Use atleast seven of the following buzzwords in any promotional material. Super PHBs comb for this stuff via keywords, and you DO want your website to show up, right? Paradigm, proactive, "think outside the box", revolutionary, third-wave, interactive, multimedia, 3D, any word with i, e, or x in it. For example: iBrain, e-data, or Xtreme.
• Your HTML code should suck - amazon.com, microsoft.com, networksolutions.com, yahoo.com - all their HTML sucks. Yours should too.
• Get vulture capital, and then immediately go to IPO (see this example) without creating a product. Claim your business is riding the 'bleeding edge' of technology, and products are obsolete - you sell ideas, not products!
• Run linux. Hey, with Microsoft on the out-and-out, it helps to run an OS loved by millions. Try to get it linked to slashdot too. Get an interview if they won't post it and convince them you have a new "open source" methodology to designing websites!
• Marketing, marketing, marketing. You can't go wrong with huge banners proclaiming you're THE hip business to do business with on the 'net. Just don't claim you invented the internet unless you're running for president. Everything else is 'OK'.
• Whatever you lack in content - make up for it in huge flashing banner ads and broken HTML that only renders correctly once in a blue moon. Web surfers love to see people using technology so new they can't even view it!

--

I'm a lawyer representing IDG

[Hobbex]

And I order you and Slashdot to immediately seize and desist all usage of our internationally copyrighted phrase "... for dummies". We have court decisions backing IDG's exclusive right to address the dummies of the world.

Though, given how in line your advice is with other IDG publishings, we may consider giving you a book contract for this one...

-
We cannot reason ourselves out of our basic irrationality. All we can do is learn the art of being irrational in a reasonable way.

My experience

[RobertGraham]

I work for a startup and help maintain the website. We currently get about 20,000 users/day, but are still growing rapidly. Here are my recommendations:

It's about the content, stupid Ultimately, the growth and popularity of your site is determined by the quality of its content, not its looks. Don't worry about looks until much, much later. Too many people shift too many resources too early into good looks. Remember, you've got finite resources. I've seen many sites fail because they spend all their effort getting the look just right, and never get the content right. Marketing types fret a lot about protraying the right image and all that crap; they have to fret about something because they rarely understand any of the actual details.

All code has bugs This simple law of programming applies to websites. Whatever ideas you have now about your website are not complete. Slashdot is always tweaking its content to create a better user experience. This actually dovetails with the point above: too many sites get customer feedback about things that need to be changed, but cannot because it would break the cool graphics, or the master design. Design your system NOW for constant tweaking, or you won't survive.

KISS (Keep it Simple, Stupid) People get enamored with the latest technologies and build websites that require the latest browsers with all featuers turned on. If you do this, you'll kill your site. Test with Lynx and make sure it provides an adequate (though not wonderful) user experience, then it'll likely work for everyone else. Cool stuff like Java, plugins, scripting, etc. are nice for sprucing up sites a bit, but if you depend upon them, you'll kill your site.

Focus! This is how marketing departments kill good work. Engineers try to create very focussed products that solve specific needs well, marketing tries to broaden the product's appeal, overloading it with features that end up satisfying no-one. Start broadening your appeal only after you've created a solid user base. For example, our company does business with another company that we have to help figure out very basic issues, because they aren't focusing on the technical problems but the "story" of where they are going. If they don't clean up their act, they will fail.

RAIL Redundent Array of Inexpensive Links. Grab two DSL lines from independent providers; that's all you need for a really popular site. Of course, that's assuming that you've followed the KISS principle above -- a lot of sites have huge graphics that quickly eat up bandwidth. You could easily maintain 20,000 hits/day and not eat up a 384-SDSL link. The chief problem isn't bandwidth by reliability. Even hosting companies like AboveNet and Exodus go down when backhoes take out their backbones. A RAIL solution solves this problem: DSL lines are a lot less reliable, but two DSL lines (from different vendors) are more reliable.

Backups You MUST have offsite backups. Also, assume any machine connected to the Internet will be corrupted (i.e. static content should be kept internally and regularly mirrored out onto the Internet servers).

Hacking um, you WILL be "hacked". Plan for it. I mean it. For example, your servers front-ending your site will easily be hacked, but if you plan on that contigency, you can usually harden your database server against further incursion. Don't believe me? Follow these steps: (1) go to Yahoo and search for "wwwboard passwd". (2)about every other link will be a pointer to an WS_FTP.LOG, which you replace with the file "passwd.txt" (3) run these passwords you get through a 'crack' program (4) poof, you thousands of passwords with only a few hours worth of work. Note: in this example, firewalls don't help.

Platform The underlying platform is irrelevent, in both security and performance. You should strongly consider PERL for dynamic content, only because it is the most used (and consequently, when you hire people to work on your site, this is what they'll know). Geeks like to fight over the most technologically elegant solution, but issues like hiring experienced programmers that can maintain it are far more relevent IRL.

Manage growth You will be too optimistic about growth in the beginning, and too pessimistic at some later date. You'll do a bunch of stuff that you think will drive people to your site, but they will fizzle. Then out of the middle of nowhere something happens and hits shoot up 10 fold. Be ready for both (watch cash flow and don't overspend now, but be ready to upgrade capacity at a moment's notice).

HITS Note that one of the Internet scams is people that promise to drive hits toward your site. This is all crap: all such techniques are publically available, and since this is your core business, you need to learn all of them yourself.

Outsourcing Outsource everything that isn't your core business. This is the Internet baby, you don't have time to build a company. You can't hire people fast enough, and you can't hire good enough people. You also don't want to be giving stock options out to people that don't directly influence the companies growth. For example, don't have a human resources person doing health insurance, outsource it to a consultancy. Many of the .com startups use this approach and have surprisingly few people when they go public. Conversely, the previous section is a good example: when it is your core business, DON'T hire consultants or outsource it -- do it yourself.

There's more, but I think this message is getting long enough.

goons law on startups

[goon]

Here's some laws I've formulated after working in 3 startups from '96 to now (sausage.com, www.ringtail.com.au and the company I work for now). They relate a lot to ASP (application service providers) but could be applied to binary apps companies.

1. hire less, hire smarter
   - company iq==(total employee iq/employee#)
   own the data
   - owning/possesing the data allows you to do lots of things with it. Data hosting is a core activity of ASP's. Own/posses the data, you can do lot's of neat things with it.
   complete the data loop
   - from customer/user input into a database, useful information is filtered back to the client using the Internet and it's protocols.
   use the internet protocols 2 your advantage
   • smtp:
     - email back results of non-immediate jobs
     ftp:
     - allow large files/data that can't be email to be accessed.
     http:
     - presentation layer of services
     xml:
     - new one but such organisation could revolutionise your text file storage.
     extend and leverage your logistics.- by using the internet and your database, development tools to automate functionality: ie: web backups of databases the transfer DDL, BCP data, codebase, log files from different areas on the site to a centrally located removable hard disk or Jaz disk: I've don this myself.
     
   develop a minimal rock solid product.
   - one that does not crash or crashes minimally. Customers wont praise you but will let you know if it does not work.
   give your customers a cheap basic product to start with.
   - dont give a cost hurdles for customers to adopt your product.
   leveredege existing binary products
   to use Internet facilities with objective of upgrading customers to the web.- migrate those binary products to use internet protocols with the idea of upgrading all/most of your services to the web.
   Become your own ISP
   with control of web servers, DNS, databases ISDN internet link etc.- you have full control of your domain, you can do everything you possibly can.
   Maximum bandwidth decides you maximum audience.
   - bandwidth dictates the speed, reliability and user experience: Use slashdot growth as an example.
   Fund initial expansion without going into debt.
   - dont waste money and go into debt. Finance growth on profit until venture capital is possible.
   Have bloody lots of fun
   - if you cant code what you want, play the games or build robots, code some great code you wanted to do you will not enjoy the work. Play hard, work hard.
   Dont give up
   - startups fail, dont let this stop you. Check out what happened to Crack.com. Do you think these guys are giving up. Wonder how long ddt and jt are back building FPS or RPG post Transmeta and JiJit? failure makes you smarter!, comebacks make you legends :)
   try to use a higher level dev languge
   , use the source!: scripting not binary- binaries are hard work. The develop, compile, build, create install, release cycle is way to long. Scripts are the way to go. Error, just go to the script (text file) and make a change.