Выставление счетов без кода: как собрать приложение

Чтобы сделать выставление счетов без кода, опишите в промпте структуру счёта, правило нумерации и статусы оплаты, а ИИ-билдер соберёт приложение сам. В Zugo сборка стоит 6 кредитов и занимает около минуты. Приём оплаты закрывает коннектор Stripe, данные клиентов и счетов живут в Supabase, код выгружается в GitHub.

Счёт кажется простым документом ровно до момента, когда их становится тридцать в месяц. Дальше начинают болеть нумерация, статусы и вопрос «этот уже оплатили?».

Зачем собирать своё, если сервисов много?

Три причины, и ни одна из них не про экономию на подписке. Первая: ваш процесс не совпадает с шаблоном сервиса. Аванс, частичная оплата, акт после закрытия этапа, разные валюты у разных клиентов: чужой продукт умеет что-то одно.

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

Третья: связка с тем, что вы уже ведёте. Если у вас есть учёт заказов или часов, счёт логично рождается из них, а не переписывается вручную в третьей системе. Именно ради этой связки собственное приложение и имеет смысл.

Честная граница: если вам нужна сдача отчётности, интеграция с банком и работа бухгалтера, специализированный сервис выиграет. Своё решение сильно там, где процесс нестандартный и небольшой.

Что написать в промпте?

Оформление билдер придумает. Структуру счёта, правило нумерации и статусы он придумает по-своему, если вы не назовёте свои, поэтому назовите.

Сделай веб-приложение «выставление счетов».
Вход по почте, каждый пользователь видит только свои данные.
Клиент: название, контактное лицо, почта, реквизиты, адрес.
Счёт: номер, дата выставления, срок оплаты, клиент,
позиции (описание, количество, цена, сумма), скидка, итог,
валюта, комментарий, статус.
Нумерация: [формат, например 2026-001], сквозная,
увеличивается автоматически, вручную не редактируется.
Статусы: черновик, отправлен, частично оплачен, оплачен,
просрочен, отменён.
Просроченным счёт становится автоматически на следующий день
после срока оплаты.
Экран «Счета»: список с фильтром по статусу и клиенту,
сумма к получению сверху.
Экран «Счёт»: печатная версия, кнопка «Отправить клиенту»,
кнопка «Отметить оплаченным», ссылка на оплату.
Экран «Клиенты»: список с суммой открытых счетов.
Валюта: доллары. Тон интерфейса: строгий, документальный.

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

Какие экраны и статусы нужны?

Статусов должно быть ровно столько, сколько состояний реально бывает у ваших денег. Каждый лишний это ещё одно место, где счёт зависает, и ещё один спор о том, чем «отправлен» отличается от «ожидает оплаты».

Экран просрочки кажется необязательным, но именно он превращает приложение из генератора документов в инструмент, который возвращает деньги. Без него напоминания зависят от памяти.

Ещё одна вещь, которую стоит заложить сразу: возможность выставить счёт копией предыдущего. Большинство счетов у постоянных клиентов повторяются с точностью до даты и одной позиции, и кнопка «повторить» экономит больше времени, чем любое ускорение формы.

Как принимать оплату и хранить данные?

Коннектор Stripe даёт настоящую ссылку на оплату, которую можно вложить в счёт: клиент нажимает и платит картой, не выясняя реквизиты. Для работы с зарубежными заказчиками это разница между оплатой сегодня и оплатой через две недели. Подробности в статье оплата через Stripe.

Supabase хранит клиентов, счета и позиции в вашей базе Postgres и даёт вход по почте. Фразу «каждый пользователь видит только свои данные» напишите буквально: без неё легко получить приложение, где сотрудники видят чужие счета. Разбор схем хранения лежит в статье приложение с Supabase.

Resend отправляет счёт клиенту письмом и напоминание при просрочке. Автоматическое напоминание на третий день после срока оплаты работает лучше, чем неловкое сообщение через месяц, и не требует от вас волевого усилия.

Экспорт кода в GitHub делайте сразу, как только через приложение прошли первые настоящие деньги. Финансовые данные не должны зависеть от одной подписки.

Сколько это стоит в кредитах?

Free даёт 5 кредитов, что меньше одной полной сборки: это способ осмотреться. Pro стоит $25 в месяц и даёт 200 кредитов, Business стоит $99 в месяц.

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

Что проверить перед первым настоящим счётом?

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

Вторая: нумерация. Выставьте три счёта подряд и убедитесь, что номера идут без пропусков и не сбрасываются. Затем удалите черновик и проверьте, что номер не переиспользовался.

Третья: печатная версия. Откройте счёт в браузере и сохраните в PDF. Проверьте, что реквизиты, срок оплаты и итоговая сумма помещаются на страницу и читаются, а не уезжают за поля.

Каждая найденная мелочь чинится одной фразой в чате и стоит 3 кредита. Как формулировать такие запросы точнее, разобрано в гайде как писать промт для ИИ-билдера.

Как считать деньги, а не документы?

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

Второе число рядом: сколько из этой суммы просрочено. Разница между «ждём оплаты» и «уже должны были заплатить» определяет, кому вы пишете сегодня. Без разделения оба состояния сливаются в общую тревогу, из которой не следует никакого действия.

Третье: средний срок оплаты по клиенту. Он считается из даты выставления и даты оплаты и показывает, кто платит через три дня, а кто через сорок. Это знание меняет условия следующего договора точнее любых переговоров вслепую.

Четвёртое: не удаляйте счета, а отменяйте их. Удаление рвёт нумерацию и стирает историю, а отмена оставляет след и объяснение. Разница кажется формальной ровно до первой сверки с клиентом, который утверждает, что счёт был другой.

Каждое из этих чисел добавляется одной правкой за 3 кредита, и добавлять их лучше по одному, проверяя расчёт на реальных данных.

Чего такое приложение не сделает?

• Не сдаст отчётность. Налоговые формы, декларации и обмен с надзорными системами это работа бухгалтерского сервиса, а не сгенерированного приложения.
• Не свяжется с банком. Автоматическая сверка поступлений по выписке требует банковского API и разработчика. Код выгружается в GitHub и передаётся ему.
• Не заменит юриста. Требования к реквизитам и обязательным полям счёта различаются по странам, и проверять их должен человек.
• Не потянет сложную налоговую логику сразу. Разные ставки, обратное начисление, счета в нескольких валютах доводятся серией правок, а не одним промптом.

Zugo не заменяет команду разработки на финансовом продукте. Он закрывает другое: рабочий генератор счетов со статусами, нумерацией и ссылкой на оплату за минуту.

С чего начать?

Соберите версию с тремя экранами: клиенты, новый счёт, список счетов. Выставьте настоящий счёт настоящему клиенту в первый же день. Практика покажет недостающие поля быстрее, чем любое планирование.

Если счета вырастают из отгрузок со склада, посмотрите соседний сценарий в статье про учёт склада: модель данных там устроена похоже и легко стыкуется. Если клиентов надо ещё и вести по воронке, смотрите разбор CRM без программиста. Своё приложение описывайте на zugo.dev теми словами, которыми объясняете свой процесс выставления счетов коллеге.