На мой взгляд базисные знания следующие:

1) Клиентская верстка и стили (html, css). Можно пробежаться глазами хотя бы по теме. Почитать про правила верстки.
2) Клиентская логика, работа с DOM (Javascript, Jquery). Важная тема — стоит уделить ей время.
3) Теория распределенных приложений. — Веб приложения чаще всего являются распределенными. Поэтому стоит изучить архитектурные принципы распределенных приложений. API и т.д.
4) Базы данных (SQL, etc.) — Конечно начать стоит с классического сиквела — но стоит посмотреть и шире — например на nosql решения.

Далее стоит выбрать технологическую платформу. С вашим бэграундом вероятно стоит посмотреть в сторону Microsoft ASP.NET MVC. Это великолепное решение и погружение в обширный мир разработки в рамках решений MS. У них сейчас самые развитые языки программирования (C# 5.0), самые развитые инструментальные среды (MS Visual Studio), одна из самых совершенных виртуальных машин (.Net).
Решение удобнее всего для серьезных и масштабных проектов, хотя и для небольших вполне подойдет.
Следующий кандидат — Ruby on Rails. Это развитое решение с замечательным языком программирования и отличными каркасными решениями, заточенное именно под веб. Возможно лучше подойдет для небольших приложений — но и промышленные продукты без проблем потянет.
Он также очень распространен.
Ну и конечно PHP. Язык программирования данной технологической платформы отстает от требований к разработке больших решений — он скорее подходит для написания скриптов. Однако существует колоссальное количество каркасных решений для данной платформы, которые позволяют реализовывать даже приличного объема продукты. Кроме того данное решение наверное самое распространенное из всех.
И оно потихоньку подтягивается до уровня платформ для разработки промышленных продуктов.
Существует также множество других решений. Например огромный мир Java и решения на базе серверного Javascript.

Скоп работ будет состоять из следующих частей:

1) Клиентская часть (html, css, javascript). Тут вам понадобятся знания по верстке как раз и жаваскрипту. Также следует использовать различные базовые решения и фреймворки. Эта как раз та часть, где слишком глубокие знания (например использование чистого некроссбраузерного javascript) могут быть вредны и лучше все базировать на готовых платформах.
Часто эта часть в web приложениях бывает больше чем хотелось бы.

2) Серверная часть. Тут все определяется технологической платформой описанной в предыдущем абзаце. В веб приложениях как правило немного серверной логики — почти все можно заменить на внешние библиотеки. Но у разработчиков десктопных приложений всегда есть соблазн развивать именно эту часть потому что она им знакома — не поддавайтесь. Специфическая для проекта серверная логика нужна не очень часто. Если ее много — значить кто то увлекся велосипедами. Тоже касается разработок API и систем взаимодействия с внешними сервисами.

3) Базы данных. Конечно обязательно! стоит использовать развитые ORM системы. То есть нужно их изучить под выбранную вами технологическую платформу. Ну и конечно базовые знания баз данных тут тоже очень понадобятся — сиквел, реляционная модель и все остальное.

Дерзайте. Я за вас болею.

Ваша проблема довольно типична на самом деле :) Это не какие то индивидуальные особенности, просто многие боятся самому себе в этом признаться.

Например в рамках классического скрам планирования команда оценивает отдельные фичи или задачи всей командой да еще не в человекочасах, а в абстрактных еденицах, которые переводят в человекочасы опираясь на скорость работы людей до этого. Целая система.

Это делается потому, что в разработке время большинства задач очень трудно оценить адекватно. Большая часть оценок - это просто цифры с неба. Плюс ко всему реальное время обычно "стремится" к запланированному. То есть если вы делаете работу быстрее, вы будете растягивать ее, чтобы не сделать раньше срока, чтобы люди не думал, что вы даете намеренно завышенные оценки. Если же не успеваете - то будете работать как папакарло по выходным, гробя свое здоровье и качество продукта, который вы разрабатываете.

Проблема в том, что сроки очень важны для бизнеса. И если руководитель не может оценить сроки, то он будет стремиться делегировать эту оценку ниже по служебной иерархии. В лучшем случае конечным звеном будет проектный менеджер, который будет работать с командой над оценками сроков, взяв на себя ответственность за них. В худжем он этой отвественности попытается избежать, делегировав оценку сроков каждому отдельному разработчику. Их оценки конечно будут адекватными в очень небольшом количестве случаев. Тем не менее за счет "стремления" реальных сроков к запланированным будет создаваться иллюзия управляемости процесса, что выгодно всем в этой цепочке, кроме самого разработчика и продукта, что он делает (читай заказчика).

В тоже время такие оценки сроков начинают выглядеть как инструменты мотивации людей к работе, подменяя собой традиционные инструменты мотивации: командную работу, премии и т.п. И как инструмент мотивации это действительно работает во многих случаях. Не отменяя конечно побычных эффектов, вредных для вас и проекта в целом.

Что посоветовать - вопрос непростой. Ну, работать в серьезных проектах конечно, с профессиональными людьми. Там таких проблем поменьше.
Ну и конечно учиться оценивать. Ведь ваши беспокойства вызваны неопределенностью. Вы просто не знаете как сказать правильную цифру. Конечно на самом деле никто не знает, некоторые лишь пытаются убедить себя, что знают. Однако вы можете приблизиться к реальности.

• Ведите статистику по тому, сколько времени занимают сделанные вами задачи, или используйте существующую.
  
• Разбивайте задачи на подзадачи и оценивайте их отдельно, а потом складывайте результат.
  
• Сравнивайте задачи с теми, что вы уже делали.
  

Системный подход решает многое.
Ну и конечно классический финт ушами: закладывание рисков. Просто учтите риски, добавив время, проявив храбрость, чтобы сказать большую цифру. И если на самом деле сделаете быстрее, считайте, что учтенные вами риски попросту не случились. Это вашему руководителю будет очень понятно.

Если так заморачиваться по поводу ssd — то зачем он вам вообще нужен? вообще же от него удовольствия не получите.
Не закончатся ваши циклы перезаписи в обычных сценариях использования хоть с файлом подкачки, хоть без него.

Опирайтесь на размер оперативной памяти в вашем решении.

Из комментариев мне кажется, что автора топика трудовой договор реально не волнует. Что он ищет какие то слова, которые можно сказать сотрудникам стартапа, чтобы запретить им рассказывать где они работают. Припугнуть так сказать.
По моему вообще какая то ненормальная практика. С таким подходом к вам нормальные люди работать не пойдут.
Хотя я может что то неправильно понял.

Если уж очень надо чтобы не разглашали — включайте это как пункт трудового договора и подготовьте прояснительную беседу или презентацию с аргументацией того, зачем тут этот пункт. Я сам например до конца не понял зачем он.