Боюсь, что огребу за свой совет кучу минусов, но тем не менее:

Месяца три назад, я 2 недели посвятил тестам — что лучше. Правда — у меня стоял PHP 5.4, nginx 1.2 и все это на Debian
Тестировал (и, разумеется, в процессе тестов тюнил ОС и все прочие настройки) четыре варианта — nginx+PHP, nginx+ahache+PHP, nginx+nginx+PHP (в последнем случае есть внешний нгинкс, работающий со статикой и отправляющий запросы к PHP на внутренний нгинкс) и nginx+apache+PHP-FPM.

Внутренние нгинкс и апач запускаются в режиме keepAlive off
У апача отрублено все лишнее (в моем случае оставлены dir, auth, mime, rpaf). ,haccess не используется (если че-то нужно органичить — ставим напрямую в конфигах сайта, все перенаправления — через внешний нгинкс)
У внешнего нгинкса включен gzip, отключено кеширование
Внутренние сервера логируют только ошибки php

Во всех случаях на реальные сайты натравливался siege с увеличенным таймаутом и с 1000 конкурентных запросов.

Да — и машинка — Хетзнеровская с 24 GB памяти.

Результаты получились следующие:

nginx + php — не котируется вообще. выводит память в свап, нагрузка в top — 140 — 150 примерно через минуту после начала осады. Манипуляции с системой и настройками не помогли.

nginx+apache+php-fpm — жрет память и залезает в свап, процессор особо не грузит. Есть проблемы со стабильностью (siege стабильно отрабатывал с параметром не более -c 500)

nginx+apache+php и nginx+nginx+php — примерно одинаковые результаты — средняя нагрузка в top — 3, среднее потребление памяти — 14 — 16 Gb. Количество транзакций также примерно одинаково (apache показывал результаты примерно на 3-4 транзакции в секунду лучше)

nginx+nginx+php работал чуть менее стабильно, чем nginx+apache+php (не чуть, даже — чуть-чуть — то есть пару тройку раз сокет все-таки падал, а в случае apache тaкого не было)

Пришлось остановиться на классике (хотя очень хотелось ограничиться nginxом)

Впрочем — это все — лирика. Я бы рекомендовал провести серию тестов с вашим софтом (и с вашим админом) — возможно вы получите другие результаты. Впрочем — и это почти наверняка — вариант с реверс-прокси будет заведомо более производительным.

Выбираете налогообложение доходов. НДС не платите, НДФЛ не платите, отчеты о расходах не предоставляете. Оплачиваете 6% от всех поступлений на счет + около 12000 в год в ПФ (эту сумму можно уменьшить, вернее учесть ее в общем налогообложении).
Официально на первых порах работаете как один человек, субподрядчикам переводите деньги так, как сочтете нужным (посльку по расходам не отчитываетесь) — главное, чтобы субподрядчики или были как-то отдельно от вас, или чтобы официально их не было вовсе. То есть строго не зарплатные варианты. Договора подряда — возможно, но лучше бы, чтобы субподрядчики тоже оказались чем-то вроде ИП.
Работатет так до конца года — если обороты получаются больше 1000000 в месяц, в конце года считаете, не будет ли выгоднее перейти на налогообложение «доходы — расходы» (но надо иметь в виду, что в последнем случае будет намного больше возни с бумажками и всегда существует риск различия подходов к понятию «расходы» между вами и налоговой).

Вообще говоря, встроенный в PostgreSQL полнотекстовый поиск работает весьма шустро. То еть, тормозов при граничных условиях поиска по 1000000 документам (объем каждого — от 1000 до 300000 символов, средний объем документа — 2000 символов) вообще говоря не наблюдается. Во всяком случае, на выделенном сервере (в данном конкретном случае используется Hetzner с 24Gb памяти, из них PostgreSQL кушает примерно четверть, версия PostgreSQL — 9.2 — на более ранних версиях результаты были немного другими.)
Я бы рекомендовал попробовать протестировать вашу текущую конфигурацию на производительность с разными движками. И, в случае использования постгреса, не использовать подсветку результатов.

Если для опыта, то вам стоит двигаться примерно следующим образом:
1) Крепко-крепко подумать, а надо ли оно вам (потому как, если вдруг начнет получаться — процесс сам по себе затягивает и отвлекает от зарабатывания денег, личной жизни, да и жизни вообще)
2) Прикинуть, что вам не нравится в тех готовых движках, на которых вы делали сайты
3) Составить краткий список того, что должна уметь делать ваша CMS (в глаголах, желательно)
4) Поизучать фреймворки (на разных языках) и выбрать лучший, или, убедившись, что их авторы козлы полнейшие возможности, предоставляемые фреймворками избыточны, либо не достаточны — перейти к следующему пункту
5) Исходя из списка из пункта 3, выбрать хранилище данных. Критерий выбора — как ни удивительно — не его распространенность, но, скорее — возможность выборки требуемых данных минимальным количеством простых запросов.
6) Исходя из выбора хранилища данных, выбрать фреймворк/язык программирования
7) Подобрать хостинг, на котором есть все, что вам нужно
8) Пробежаться по списку из пункта 3 и быстро-быстро все написать. При необходимости — конкретизировать и расширить этот список. При необходимости — вернуться к пункту 4.

Как-то примерно так.

namespace указать надо в html.
типа примерно как-то так
<html xmlns:og="http://ogp.me/ns#">