Антон

Странно, что у тс переменая $headers называется не $zagolovki

папка vendor должна быть в исключениях, на сервере нужно запускать composer install (не update), который установит из composer.lock ту же версию, что на дев-машине (update обновит и вы будете иметь разные версии фреймворка).

Читая Ваш вопрос,вспомнил себя 5-ей летней давности:) На тот момент мой бэкграунд состоял из дюжины сайтов на различных CMS и одного стартапа,который ясное дело не взлетел. Я к тому моменту долго вынашивал план по реабилитации одного замороженного проекта (спортивный портал),который разрабатывал со своими товарищами ещё в студенческие годы. Изначально задачи написать свой движок не было,но... всё началось с разработки шаблонизатора с синтаксисом а-ля CMS MODx. Много читал о том,что данная реализация выделяется на фоне остальных конкурентов,по сути являясь визитной карточкой последней. На поверку оказалось, что это всего навсего синтаксическая абстракция над Smarty,со всеми вытекающими по производительности. К примеру,моя реализация имеет альтернативную поддержку нативного php-шаблонизатора
<?=$this->getSnippet('List', $params)?>
для тех, кто терпеть не может синтаксические абстракции (Smarty, Twing, Fenom и иже с ними.) из-за их низкой производительности и иным религиозным соображениям.
Шло время, кодовая база росла. От паттерна Singleton до DI (Dependency Injection), к Service Locator-у. Много чего выпилено в угоду существующих решений. За последние 2 года,не без помощи Composer,стало в разы больше готовых решений,причём несколько на реализацию конкретно задачи. К примеру,из последнего - был заменён собственный файловый менеджер (манипуляция с файловой системой) на библиотеку Flysystem, ибо последняя помимо всего прочего, умеет "бегать" в облака. Круто же ;) Единственное,в моей реализации была возможность поиска по regexp-паттерну,пришлось писать абстракцию.

Совет: Для программиста хорошим тоном является умение в своём коде наметить точки роста,а именно,чтобы другой разработчик при использовании текущего решения мог легко абстрагироваться,к примеру,через наследования от базового класса.

Вот сходу антипример. Достаточно популярная библиотека для валидации данных Respect Validation. Требовалось реализовать интернационализацию сообщений, не было возможности вывести иерархию выброшенных во время валидации ошибок одним большим массивом,а также хотелось вернуть,к примеру,только первую ошибку (first) или последнюю (last). Пришлось форкнуть,ибо абстрагироваться попросту невозможно.

Совет: Иногда сталкиваешься с тем, что не все возможности какой-либо библиотеки задокументированы,даже если она достаточно популярна и имеет свой красивый "твиттеробутстраповый" сайт. Загляните в unit-тесты,возможно,откроете для себя что-то новое;)

Если всё же надумаете писать свой фреймворк,то опирайтесь на существующие решения. Выберите для себя один-два популярных фреймворка и изучите,как реализован в них тот или иной функционал,хотя бы визуально,благо документации навалом. Начните с модели MVC. Посмотрите как реализованы actions,а именно доступ к ним,фильтрация на входе и выходе в action. Я,к примеру,не сторонник реализации псевдо-аннотаций,как в Symfony,ибо в PHP поддержки нативных аннотаций пока нет,а всё остальное - это жалкое подобие через медленные Reflections,даже если всё это кэшируется. Вот и автор АОП парадигмы для PHP всё это понимает, но всё равно продолжает разрабатывать свой проект Go!. Реализация конечно интересная,но я обойдусь событийной моделью (Observer или PubSub).
Взгляните как устроен роутинг, ибо это основополагающая для реализации SOAP и REST. К примеру,моё решение испытало влияние Lavarel Routing по части использования групп. Нынче в силу распространённости мобильных платформ всё чаще используется REST не только на основе url-а,но и на основе кастомных заголовков (X-<имя прагмы>).
Обратите внимания на то,как осуществляется обработка ошибок/exceptions. К примеру,Yii давно ругают на то,что нет возможности верной идентификации того или иного исключения. Лучше для каждой отдельной задачи (к примеру, FileManager) свой класс Exception,который наследуется от базового:

class Exception extends BaseException
{
    const FILE_EXISTS = 'File exists: {path}';

    public function __construct(
        $level = self::ERROR,
        $msg = null,
        array $dataReplace = null,
        \Exception $handler = null
    ) {
        return parent::__construct($level, $msg, $dataReplace, $handler);
    }
}

Тогда в базовом классе BaseException можно легко реализовать логирование (к примеру, воспользоваться Monolog) и красивую визуальную выдачу в режиме дебага (к примеру, Whoops).
Желательно сразу избавить себя от привычки делать "жирные" контроллеры/actions. В этом может Вам помочь различные реализации валидации,фильтрации данных,а также задания дефолтовых значение на уровне модели. Обратите внимание на метод rules. Тогда в Вашем контроллере будет лишь метод отправки уже обработанных данных на вьюху.
Что касается ORM и DBAL (синонимы: DAO и Query Builder), то в этом случае уж точно не стоит изобретать свой "велосипед". Написать по возможности единый интерфейс для различных реляционных и нереляционных решений (СУБД, Систем полнотекстового поиска/индексаторов (Sphinx, Elasticsearch)) - более чем нетривиальная задача. Я в своём фреймворке взял за основу AR (ORM) и Query Builder Yii2. Да,в Yii отсутствует модульность,а потому всё достаточно зависимо друг от друга,но если захотеть, то можно.
Чувствуете этот момент. Вы препарируете почти готовое (прим. Yii2 еще в состоянии беты),одно из самых выдающихся на текущий момент решений и тем самым разбираетесь во всех тонкостях, попутно проявляете активность в исправлении ошибок.
Научитесь писать unit тесты. Множество ошибок всплывут на поверхности,да и сон Ваш тогда будет более крепким.
Вы наверно могли для себя заметить на том же stackoverflow или иных ресурсах, задаются достаточно тривиальные вопросы по фреймворкам. Вот и сейчас пока пишу Вам этот большущий ответ,в разделе "Похожие вопросы" красуется такой вопрос "Как реализовать правильно авторизацию с сессиями ... Отсутствует элементарная дисциплина к самостоятельности. И я даже догадываюсь почему так. Фреймворков стало больше,фреймворки стали лучше. Programmer Frendly,а не страшный зверь для избранных,как было когда-то. Правда,некоторые и по сей день недружелюбно скалятся;) Так или иначе,если есть желание задать вопрос из серии каким образом в JQuery сравнить две переменные,то стоит задуматься,а надо ли тебе всё это.
Не в коем случае не нужно уверять себя в том,что Ваш инструмент взлетит. Он не уникален,и в конечном счёте скорее всего будет состоять из множества готовых библиотек (прим. в моём случае 60 против 40% вендорного кода. Если учитывать значимость,то в этом случае, уже счёт будет не в мою пользу). К сожалению, не могу найти ссылку на англоязычную статью, где автор сетует на полный отказ от фреймворков в пользу packagist. Даже если в уникальности вашего решения нет сомнения,это ничего Вам не гарантирует. Необходимо грамотное продвижение - множество статей на тематические ресурсах,а также участие в конференциях. К примеру, PHPDaemon хоть и стартовал первым, но пока вчистую проигрывает ReactPHP, а всего-навсего необходимо было уделить внимание написанию документации. Автор PHPDaemon, Василий Зорин,как-то на вопрос чем отчается его проект от React,указал на то,что последний использует его идеи. Конечно печально за нашего соотечественника,но его проект попахивает откровенным эгоизмом.
Делайте Ваш инструмент прежде всего для себя,и возможно,когда-нибудь он станет интересен кому-то ещё. Так или иначе,Вы получите бесценный опыт. Главное,постараться довести это дело до конца. Отличительной чертой нашей ремесленной профессии является терпение. Вот Вам и проверка этого замечательного человеческого качества:) Кстати,чтобы интерес не угас,стоит свои наработки применять,если не в продакшене,то хотя бы небольшой проект для экспериментов.
Заметил за собой,что пока занимался разработкой инструмента,гораздо больше получил опыта,чем на предыдущих двух работах. Но это субъективно. Можно с самого начала устроится в такое место,где замечательный отзывчивый коллектив и не менее интересные проекты/стартап, а не "натяни шаблон на Wordpress". Считаю,что пусть CMS-сника - это путь в никуда, и Кипелов здесь не причём:) Чем раньше, тем раньше;)
Мне, как и sWinDos тоже забавно смотреть на свои исходники годичной давности:)) Вам знакомо такое понятие,как "Тезаурус"? В трактовке теории информации,это экспоненциальный рост знаний/опыта до какого-то предела, после которого, эффективность полученных знаний/опыта заметно падает. Получается этакая кривая Гаусса или что-то вроде жизненного цикла знаний/опыта в отдельно взятой предметной области.

Совет: Запомните,Ваши проекты на github-е и контрибьюторская активность - это твёрдое, незыблемое портфолио. На собеседовании в большинстве компаний вы вправе выбрать свой сценарий поведения и темы для бесед.

P.S. Я специально не стал затрагивать моральную и финансовую сторону вопроса. Opensource или заработок? Вечные поиски свободного времени между семьёй,работой и отдыхом. Смотрю здесь уже кто-то отметился:) Если Вы ещё студент и не обременены чем-либо,то дерзайте. Вполне возможно уже по окончанию университета или даже раньше, Вы выйдите уверенным таким коренастым мидлом:) К слову,в первой организации, с которой я начал свой профессиональный путь проповедовали процедурное программирование,ибо ООП никем не понималось должным образом.