Gregary: всегда нужно до начала проекта предупреждать клиента о необходимости покупки аккаунтов, сторонних библиотек и прочих затратах. Иначе это выглядит как вымогательство. Но раз уже так сложилось - договаривайтесь. В конце-концов это в интересах клиента.
Grow-Progress.com: такая хрень на любом рынке. У таксистов это яндекс.такси и убер цену сбивают, у других кто-то другой. А по факту нужно просто научиться продавать свои услуги и создавать свою клиентскую базу.
Manoo: В таком случае нужны:
1) Сильный дизайнер.
2) Backend-разработчик, который способен спроектировать удобное API. Это важное условие, чтобы потом это же API использовали мобильные разработчики.
3) Frontend-разработчик.
Вы все таки проведите исследование целевой аудитории, проверьте, может стоит начать таки с мобильного приложения. Сейчас мобильная аудитория гораздо больше, чем web. На последних двух проектах убедился в этом - мобильных пользователей на порядок больше, и многие из них не пользуются ноутбуками и ПК вообще. Только смартфон или планшет.
internetbrothers: Night дал самый адекватный ответ на ваш вопрос. Прибыльные проекты строятся не от названия домена, а от определения проблемы и ее успешного решения, за которое люди готовы платить. Сам участвовал в нескольких проектах, построенных от названия домена. Все закончилось ничем, потому что никто не хочет платить за решение надуманной проблемы.
А пока самый вероятный шанс заработать - перепродать этот домен дороже.
belozerowrockdev У parse есть механизмы, которые при обновлении контента оповещают клиентов о необходимости синхронизироваться?
В любом случае озвученной риск, когда нужно будет срочно внести изменения в меню, а связи нет, это не снимает. Просто учитывайте его.
rockdev: минус в том, что нужно будет периодически синхронизироваться, а в это время может отсутствовать связь и т.п.. К тому же он платный, хоть и сумма копеечная, но за своевременной оплатой следить надо. Главный риск - нужно срочно поменять цену блюд, а ближайшая синхронизация через неделю + внезапно упала связь.
Локальный сервер наоборот, не парит, а упрощает задачу, так как можно вообще отказаться от периодической синхронизации. Нет зависимости от провайдеров и от Parse, изменения можно вносить мгновенно. Только бюджет вырастет на стоимость разработки админки.
Насчет Parse - не читал, но осуждаю :) Набросать простейшую админку на ASP - 2-5 часов. Может быть на Parse это займет полчаса, но на мой взгляд риски и ограничения не перекрывают выигрыш во времени разработки.
des1roer: Если посмотреть код внимательно, то можно увидеть, что одна строка - один параметр. command.Parameters.AddWithValue("@demographics", demoXml); Но действительно, если много строк в самом запросе - это проблему не решит.
Все таки присмотритесь к параметром - это хорошая практика, вместо того чтобы из кусков строку собирать.
Curly Brace: можно конечно воспользоваться OCR, но разве это будет проще? Если изначально разработчик не заложил возможности для взаимодействия с другими программами, будьте добры познать удовольствие извращения, озвученных мной :)
Николас Комаров: мой ум тебя беспокоить не должен. А вот тебе стоит поработать над своей манерой общения. Хамить в ответ на совет, который ты сам же просил далеко не лучшая стратегия. Показываешь себя мудаком.
Просто уточню, что в лучшем случае стажер начинается приносить пользу и прибыль через 3 месяца. А до этого в него только инвестируешь. Конечно, есть исключения, но на фоне общей массы они не заметны.
Nikolas_Williams: тут скорее не в нагрузках дело, Azure прекрасно автоматически масштабируется.
Просто если у вас в планах 200 000 клиентов приложения, лучше сразу делать приложение на нативных инструментах платформы.
По допилке - у меня сейчас на поддержке два проекта на этом стеке. На все времени хватает, никаких трудностей не возникает.
