обычно есть 2 пути:

1. Оценка по фикс-прайсу
   
2. Или Time&material.
   

Первый путь начинается с анализа ТЗ, конечно же. Иногда, у заказчика есть какое-то описание в виде текстового файлика, мокапа, дизайна или ещё чего-нибудь. Если же нет, то тебе придется как-то формализовать его хотелки, перевести в понятный вид и написать тз самому, не для него, а для себя прежде всего. В нем ты описываешь весь функционал, который требуется, поведение пользователей, примерные нагрузки и т.д.
Чем детальней написано тз - тем лучше.
Например:
Плохое ТЗ: В приложении можно авторизоваться через email/соцсети.
Хорошее ТЗ: В приложении можно авторизоваться через email и соцсети facebook, vk, instagram. Пользователь может проходить авторизацию через любую соцсеть, при этом при авторизации через ещё непривязанную соцсеть мы должны обновлять данные пользователя.

Дальше ты разбиваешь ТЗ на отдельные части, которые ты можешь оценить.
Например:
Авторизация по email: 2-3ч + 3-5 на каждую соцсеть.
На те вещи, которую ты знаешь и много раз делал закладываешь разброс поменьше, то что не делал - побольше. НА интеграции с третьесторонними сервисами типа соц.сетей, платежных систем, закрытых API, невнятно описанных вещей в ТЗ и т.д. делаешь большой рейндж, т.к. велик риск проблем с доступами, сложностей получения, неактульных документаций и прочим. Если что-то непонятно, лучше спросить у заказчика заранее и описать возможные проблемы, возможно, вы найдете другое решение.

В конце концов у тебя получится 2 оценки - оптимистичная и пессимистичная. Можно ещё добавить какой-нибудь коэффициент, на который надо умножить, если твои оценки обычно слишком оптимистичны ("да тут работы на 2 дня", а сидишь неделю) или наоборот, излишне пессимистичны ("мне надо месяц, а делаю за неделю").

Далее ты понимаешь работа займет, к примеру 250-300 чч, умножай её на свою часовую ставку. вот ты и получил примерную стоимость работ. Не забудь прибавить стоимость всех материальных затрат, специфичных для (хостинги, доменное имя, спец. оборудование, доступ к платному АПИ).

Также не забудь учесть, сколько ты сможешь работать, а то он может подумать, что это 250чч - это 1 месяц работы, а в реальности у тебя основная работа/семья/кошка и ты можешь дать только 100чч/месяц.

2 путь сложнее:
Заказчик любит менять концепцию, тз нет и не будет ему важно быстро тестировать свои идеи и что в итоге выйдет он плохо себе представляет - тогда ты просто ему озвучиваешь стоимость часа и сколько времени ты можешь ему уделить. Основные сложности - это то, что можно нагородить говнокода из-за постоянных изменений, и каждая дальнейшая правка будет занимать все больше времени, а рефакторинг в таком случае очень трудно продавить.

Вам указывали недостатки, но, почему-то для вас "Всё минусы какие-то мутные (кроме зависимости от конкретной БД)".
Давайте попробуем посмотреть повнимательнее:
1. Сложность отладки и тестирования - в то время, когда я работал с такими приложениями была проблема с тем, что средства отладки были слишком неразвиты, зачастую приходилось пользоваться dbms_output и все, чтобы отладить процедуру. думаю, нормыльные даббагеры потом появились, но я уже к тому времени ушел. Как сейчас обстоит с этим в РСУБД?
2. Затрудненная версионность - а разве не так? На больших проектах со множеством разработчиков это ещё как будет стрелять. Просто посмотрите как мучаются люди с данной проблемой https://habr.com/ru/articles/330662/, тогда как те, кто использует БЛ вне базы просто пользуются гитом
3. Зависимость от конкретной СУБД. Вы уверены, что БД у вас всегда будет подходить под требования бизнеса на 10 лет? Что, если за 10 лет появятся задачи, которые лучше решать другими инструментами? А если появятся задачи которые можно решить только сторонними инструментами?
4. "Ограниченные возможности языка" - можно ли решить все проблемы с помощь SQL/PL-SQL?
5. Сложности с масштабированием/оптимизацией - здесь тоже намного сложнее все. Кэширование вы тоже на СУБД будете возлагать? Что будет, когда у вас серверов БД будет больше 1?
6. Что насчет интеграций? Что будет, если вам надо будет ходить по АПИ в третьесторонний сервис? вы это тоже заложите в логику в БД?