Решил сам собрать систему онлайн-записи: где споткнусь и не проще ли отдать агентству?

Два года назад из такого же упрямства сам сделал систему записи для нашей клиники. На второй неделе два вип-клиента записались на одно время и столкнулись в холле. Один устроил скандал и влепил 1 звезду на Google Maps. В тот же день свернул самоделку и подключил нормальный сервис. Нервы дороже.

Проблема, в которую вы уперлись, в разработке называется race condition. Когда пользователь уходит на экран оплаты, слот должен холдироваться, а если платеж не прошел — освобождаться через 10 минут. Реализовать это стабильно на коленке через no-code практически нереально.

Если пойдете в агентство писать такую систему с нуля, вам с порога зарядят минимум 70.000–90.000 TL. Готовый софт за 1.500 TL в месяц будет окупать эту сумму лет 4-5. К тому же падения серверов, апдейты и смену API у SMS-провайдеров берет на себя готовый сервис.

для смсок надо через налоговую и оператора имя регистрировать вебхуки отвалятся смс не уйдет клиент не придет лучше вообще не лезьте туда берите готовое решение и не парьтесь.

Забудьте пока про предоплату и SMS. Начните с простых бесплатных плагинов онлайн-записи, которые просто связывают Google Календари мастеров между собой. А когда пойдет больше 20 записей в день, тогда уже подключайте профи или готовый софт.

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

а если чтобы избежать накладок просто написать скрипт: клиент отправляет форму страница сразу обновляется и это время скрывается из списка так не сработает?

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

Я тоже так считаю. То, что делают все, не значит, что это правильно.

Ответ выше точно передал суть вопроса. кстати если не зафиксировать это письменно с самого начала потом возникнут споры.

Пишите, если есть вопросы отвечу по мере возможности.

Этот совет подойдет не всем, на мой взгляд. Пытаться сделать это в одиночку — самый дорогой путь.

Надеюсь, это будет полезно.

Здесь есть ловушка, не могу промолчать. Больше всего времени у нас уходило на то что было непонятно, кто принимает решения.

Любой пункт, не зафиксированный письменно в будущем обе стороны будут помнить по-разному. Если напишете результат здесь это поможет и другим.

У нас так же.

Мы тоже какое-то время назад застряли на том же месте. Если критерии приемки не прописаны, момент завершения работы становится предметом спора.

Мы тоже какое-то время назад застряли на том же месте. Процесс, по которому не ведется учет, не улучшается, потому что вы не знаете, что именно улучшать.

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

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

На этом всё извините если затянул.

Я долго занимался этим вопросом. Решения, работающие в малом масштабе, рушатся при росте, я узнал это слишком поздно.

Я бы пошел этим путем.

Сохранил. График платежей должен быть привязан к этапам работ, а не к датам.

Конечно, если ваша ситуация отличается, всё меняется.