I’ve sometimes been asked for advice on how to go about setting up a website for a new business. What I’ve said usually boils down to this:
“Quick, cheap or good: pick two.” If someone asks *me* for advice, I assume they want “cheap and good, but not quick.”
A slight improvement is to use a site-generating tool that’s *separate* from the hosting provider, which at least means you’ll have *access* to the underlying code (even if it’s messy) so someone might be able to make small fixes later. My barber generated a site with such a tool, and when she started to have hosting problems I put the files onto my Appspot account and made some *very small* code fixes but nothing major (doing it ‘properly’ would need a rewrite).
1. Your startup may ‘succeed’ and get big very quickly, in which case you’ll want a *good* site in place that can scale up quickly,
2. or your startup may ‘fail’ in which case you’ll want the loss to have been cheap and you’ll want to have at least learned some skills along the way—and making it good is a way to learn.
(Barely a day after writing this, I received a personal email from Facebook’s infrastructure department asking if I want to interview for a senior job there—I turned it down citing their bad privacy record, but it’s interesting that they said they were asking because I knew Python, Nginx and Unix + GNU/Linux, which is probably what you’ll learn if you set yourself the task of building a *good* web server for your company.)
Common advice for startups to test the market by releasing a “minimum viable product” early should not apply to your system’s overall architecture: you might still want to release it early, but at least it should be clear that you *are* developing something to be taken seriously and you *do* know where you’re going. It may be “minimum” but let’s not forget the “viable” part.
Cheap and good means learning things yourself. No ‘shortcuts’ (otherwise it won’t be cheap and/or it won’t be good). In particular:
1. You will learn to write your own HTML code in a programmer’s text editor. Properly. No excuses (see above). You might then make template code to generate parts of it, but you’ll still need to *understand* what this is doing—don’t just pick some third-party tool without fully understanding how it works, otherwise you will likely run into a problem like “I want to change X but the third-party framework I’m using doesn’t let me make that change” so you’re no longer in *full* control of the quality of your site.
Too many developers seem to be in a race to use as *many* third-party components as possible, perhaps thinking a ‘laundry list’ of ‘technologies’ would make them more employable in future—and the component makers are happy to oblige by inventing more and more items for the list. But “I touched a hundred tools without understanding any of them” is not as good as “I really know what I’m doing with the basics” so get that *first* and then you’ll know how to evaluate which third-party components are worth using (if any).
2. Learn the importance of a ‘text first’ approach. Fancy graphics can come later, but *search engines may penalise your ranking* if you use graphical controls that blind people can’t read because there is no text for their assistive technology to speak. I of course actually care about blind and partially-sighted people so I want you to do ‘accessibility’ for its own sake, and in some countries you are also required to do it by law, but I think my “trump card” argument is accessibility is good SEO—the details of the ranking algorithms are proprietary secrets, and it is said they use accessibility as one of their ‘quality signals’ but we don’t know what specific things they look for, so you’d better just *do accessibility properly* if you want to rank well.
Too many sites design the graphics first and then try to add hidden text labels as an afterthought. They can miss things (and be penalised). You’re less likely to make this mistake if you make it text-only *first*, adding graphics only later. If any tutorial tells you otherwise, it’s wrong and please don’t use it.
While you’re at it, learn how to write code that labels which human language the text is in, e.g. English or Chinese. Search engines and screen-readers may do better jobs if languages are properly labelled, especially if you use two or more on the same page.
3. “Mobile first” is good too as search engines also evaluate sites based on how well they work on a small mobile-phone screen (which some people use, and meanwhile partially-sighted people using giant print on desktops essentially turns the desktop screen into an enlarged mobile-phone screen). This basically means don’t do fancy screen layouts, or if you *do* then make it “responsive Web design” that responds to any window size—and I mean *any* window size, not just a few presets for specific test devices. Try *slowly* dragging your browser window’s resizer from full width to very narrow column, and check your site looks sensible at *every* size in between: this usually requires proper logic. People who think they can do it with two separate rigid designs (one for a big screen and one for a small screen) don’t *really* know what responsive design *is*: there are thousands of devices out there and you won’t know the zoom settings of each one, plus the search engine that evaluates your site for mobile compatibility might randomly change the size of screen it looks at.
By the way, if any learning material tells you to do your screen measurements in “pixels” *throw it away* because you should be using font-dependent units (e.g. ems)—there *are* times when pixel-measurements really are needed (e.g. image gallery), but in general you need to learn to respect different font-size settings, which you may also be ‘graded’ on during ranking. Don’t just scramble to fix this at the end—it’s easier if you know it all along.
4. Avoid indiscriminate copying. Most of the world’s web design is bad, so please don’t just copy the design of some other website without thinking. Not only do you risk litigation, you could also be copying their mistakes. Do your research properly first: what did they get right and what did they get wrong? You can probably do *better* than them if you don’t let them restrict your design decisions.
5. Learn to run a lightweight server. Even if you’ll end up paying a data-centre to host your site, you’ll still benefit from knowing how servers *work* so you won’t need as much support from them (plus you’ll have the skills to evaluate how good their data-centre really is), so I highly recommend running the prototype on your *own* equipment. And challenging yourself to reduce the server resource consumption not only teaches you new skills but will also save on data-centre costs if your company expands later: being able to serve dozens of people with nothing more than a Raspberry Pi plugged into your router and a dynamic DNS account, should make you able to serve *thousands* of people from a modest instance at a data centre, so you can avoid excessive “scale-up” costs and also reduce climate change.
Nginx may be harder to set up than the more traditional Apache server, but the extra effort buys you a *lot* more performance per server unit. Any ‘back-end’ logic is best handled within an asynchronous framework, like TornadoWeb or FastAPI in Python—again perhaps not as straightforward as conventional programming but it *will* scale better. Large media files are best avoided, but if you must have them then you might need to think about serving them from somewhere *other* than your more flexible but bandwidth-limited prototype logic server—and that separation is good practice for if you get big enough to want to use a CDN to spread the server load.
6. Use version control. If you don’t know what a version-control system like Git is, learn it now and use it from the start. Not only will it help you keep a log of what you’ve changed and when (which might be useful if you have a “how did this thing break?” situation later), it also gives you more assurance that “it’s OK” to try things out, as you can always go back to the stable version. If you later end up collaborating with other people on the code, version control becomes *even more* useful, but even for code you’re writing all by yourself it is still worth keeping that log.
Not only should you keep track of the code and data of your site, but if you’re running that lightweight home server you should be running, you should also keep its configuration files in version control.
7. If you control a (sub)domain (as you should), use it to register for Google Search Console Tools and make sure it can email you if it finds a problem with your site. Don’t *rely* on this as the only way to find problems—Google will *not* tell you about *every* problem it finds; ideally you should try to avoid making the mistakes in the first place, and you should also carefully test all aspects of the site yourself. But if Google does want to tell you about a problem, then you probably do want to receive that information.
The above notes are provided in the hope that they will be useful, but I cannot accept legal liability for things like what your company does. All material © Silas S. Brown unless otherwise stated. Apache is a registered trademark of The Apache Software Foundation. Facebook is a trademark of Facebook, Inc. Git is a trademark of the Software Freedom Conservancy. Google is a trademark of Google LLC. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Python is a trademark of the Python Software Foundation. Unix is a trademark of The Open Group. Any other trademarks I mentioned without realising are trademarks of their respective holders.