In my world, data is everything. Processing data (e.g. searching, filtering, analysing, cleaning it) is second most important (or vice versa). Representation, e.g. viewing and on different devices, with different themes and different capabilities is by far the last item to my list. *In my world*, such websites would provide only processed data (e.g. as a result of a search) in very simple, text-based format. Like JSON or a Perl data structure. All requests should also be sent in some similar way, REST or by means of a form sent by POST.
Of course the question arises: how do you make money without inserting those pesky ads in between your content, or coercing users to follow this or that link, or analysing the way users "navigate" your site in order to "personalise" the content you feed them? I don't know and I won't waste our time giving you advice that I have no clue about.
You insist on "text-only", "barebones" website. Great! Then put lots and lots of effort to design a solid DB for your data instead of wasting effort on writing HTML which is like being in stone-age. I would even hire someone just to create the DB schemas, the tables, how they are linked and how efficient search is done to them with what they call "indices". You will have authors, readers, guests or logged-in and each will have some privileges in reading and writing that data. You have to figure that out on paper first and have it reviewed by some DB expert.
Privileges: you need some form of authentication. In browsers this is achieved by an authentication cookie/token which is set at user-side (e.g. in browser) once user's password is verified. Then all subsequent requests to the site mention that cookie and user attains the privileges its user-status entails. This is easier than it sounds but obviously a very critical part of your site so be careful there.
Then you build your DB and some very high-level functions to insert data, retrieve, search by that or the other, delete data, delete users, send message to users, login or logout a user. These functions should not be concerned whether a webapp calls them or you call them at the command line. They should know nothing about web and should not output html or anything like that. Just JSON or Perl data structures.
Then you create a mock-data generator and start testing your DB and DB functions. At this stage you must also get a book which will guide you to testing your programs and make you understand how important testing is especially when you will be alone on this project. Appreciating the importance of testing is like transgressing onto another programming level. You will be a different person after that.
Now you have a DB, perl functions to manipulate data in that DB and users, functions to check on user privileges, etc. It's time to make some types of listener to handle user requests and spawn the different actions required and finally send back to caller results. That's covered best by replies from fellow Monks. Again, you will be writing lots of test cases to test the listener.
You are done. You have created an entropy-reducing tool and the world will be grateful for organising their space, time and lifes. You can do the most powerful searches and therefore users would love it when the responses match their expectations and more but in the right direction.
Now start thinking for getting something material, in return for all your efforts. Well, maybe you can create a very simple app which will be like a craiglist assistant. It sits in the background (Edit: I mean it runs on user's mobile phone or computer), checking on user's requests or wishes, searching occassionaly the website, shows the results in a nice non-overwhelming manner to user, even goes and buys something if a deal is OK. Or you can sell craiglist data to other websites who have all those designers and personnel to actually build a frontend (the views, the CSS, the html, the javascript) for interacting with your data. Like embedding youtube videos or weather from 3rd-party providers. You will be that 3rd-party provider.
bw, bliako