Алексей Сундуков

>Например предстоит участие в выставках — не будешь же раздавать визитки клиентом с контрагентом ИП?
Ни что не запрещает ИП назвать «Рога и Копыта» и пиарить себя под этим брендом. Вплоть до того, что ни чего не мешает зарегистрировать на ИП торговый знак/марку. Без проблем. Главное в документах указывать ИП и актуальные реквизиты.

>Или инвестора привлекать как?
А тут в чем проблема? Инвестор привлекается не на ИП, ООО, ЗАО или хрен-еще-знает-что, а на активы которыми владеют эту субъекты. Разницу улавливаем? Фирма может быть куплена только потому, что у неё есть имущественные права, но ни чего не мешает этой фирме эти права продать. Сама фирма нафиг ни кому не нужна. С ИП ситуация такая же, отличие только в том, что он не может продать себя. Но он может продать права/активы которыми владеет.

Если вы платите при данных видах деятельности налоги, то от налоговой вопросы возникнуть не могут. Но ряд скользких моментов имеется. К примеру, кому принадлежит сервис, ИП или ООО? Пока учредитель этого ООО сам ИП, то в принципе это не так важно. Но могут возникнуть проблемы если появятся партнеры. Кроме того у конечно клиента может возникнуть недоверие именно в этом контексте. Поэтому что разборки кому принадлежит продукт могут отразиться на нем. Я бы как клиент обратил на это внимание.

Другой аспект это разная ценообразовательная политики для клиентов. Возникает вопрос, почему клиент заплатил X, а Б Y? Нет ли тут сговора? С мелким веб-проектам специально кто-то врят ли будет заморачиваться, но попасть под какую нибудь плановую проверку шансы есть. Даже если ни чего в итоге не инкриминируют, то нервов помотают изрядно. Оно надо?

Ни Эльба, ни МоеДело не снимут с вас ответственности за ведение дел и необходимости хотя бы поверхностных знаний по бухучету и законодательству. В контролирующих органах, отмазка про то, что «это не я, это воооон тот сервис» не прокатит. С наемным бухгалтером ситуация схожая, но там есть с ним договор, трудовые обязанности и в случае его ошибок это снимет с вас личную ответственность.

В общем я бы советовал использовать для себя любой их названных сервисов, вникать по мере возможности в эти вещи и нанять таки бухгалтера.

>хочется именно предоставить возможность клиенту самому управлять своими товарами
Вообще во всех популярных CMS интернет-магазинах есть возможность управлять товарами.

Биржа и интернет-магазин разные группы ПО.

Не могу представить, для какой задачи могут потребовать подобные данные. Если не секрет, то зачем?! В голову лезет только курсовой.

Отпишусь пожалуй о своем опыте.

Ситуация схожая, но изначально товаров нужно было 250 кпозицией. Анализ коробочных решений (который не я делал) показал, что либо коробка на таких объемах не может гарантировать быстрой работы, либо производители коробки хотят таких денег на энтерпрайз, что пилить свое дешевле. Собственно чем в настоящее время и занят.

Свое требует времени, но позволяет полностью контролировать движок и быть точно уверенным в нагрузках, которые он потянет. Кроме того гарантирует более выгодную схему модификации движка, т.е. супорт движка становиться проще как технически, так и финансово. А сапорт движка собственно и есть основная статья расхода для ПО. Что удалось получить на данный момент, так это каталог. Т.е. дерево категорий, карточки товара, админка для менеджеров (создать товар, добавить к товару атрибуты). Количество товаров не ограничено, количество и тип характеристик товаров так же не ограничено и ведется через админку (т.е. дополнительно кодить ни чего не нужно). Нагрузочные тесты показали, что при ~200 МБ ОЗУ под PHP движок держит 300 запросов/сек (при попадании в кэш страница генерится за 10-15 мс) долговременно (т.е. где-то до 25 миллионов хитов в сутки) и может держать пик в 1000 запрос, но не дольше 5 сек, потом начинаются валится 50-ые. Это при каталоге в 250 кпозиций по 10 характеристик на товар. В целом вся связка (веб сервер, субд, кэш) кушает 1-1,5 ГБ ОЗУ. При этом полная развязка данных и шаблонов, поэтому можно иметь сколько угодно вариантов верски, т.е. ни какой смеси из php+html нет.

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

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

Да вот на том же малоизвестном ресурсе habr :D в рекламных баннерах крутиться Jira. Создать в ней на дашборде список назначенных задач с сортировкой по времени и приоритету не проблема.