Имеет смысл продавать backend / fullstack библиотеки?

Question

[Владислав]

Добрый день, друзья!

Цель:
Продавать непростые backend / fullstack библиотеки. За совсем большими деньгами не гонюсь, хочу заниматься любимым делом)
Вы, инженеры ПО - мои потенциальные клиенты.
Вопросы:

1. Имеет ли смысл?
   
2. Что еще (не) нужно в характеристиках продукта?
   
3. backend или fullstack?
   
4. Что лучше? В частности, любые части или гибкие фичи целиком, с REST / GraphQL Api?
   

Кто я:

1. Frontend инженер;
   
2. Работал по неполному Scrum / Agile, но прочел о и готов применять Extreme programming и Agile;
   
3. Владею Software design, TDD, BDD;
   
4. Теория DDD, применял его принципы, когда узнавал требования;
   
5. Допройду https://portswigger.net/web-security и https://web.dev/secure/;
   
6. Буду UI дизайнер;
   
7. Буду backend инженер
   

Кем не являюсь:

1. Не работал на позициях security специалиста;
   
2. Не участвовал в open-source;
   
3. Не DevOps-инженер;
   
4. Не владею System Design (Large scalable distibuted systems:
   Web Scalability for Startup Engineers - https://amzn.to/39c55QV;
   Designing Data Intensive Applications - https://amzn.to/3fxgOLm;
   Building Microservices - https://amzn.to/2UUPsFi;
   System Design Interview - https://amzn.to/33gpRev);
   Не работал в крупных компаниях (Яндекс, Google, Amazon, ...)
   

Характеристики продукта:

1. Качественный лог GIT;
   
2. Документация по https://diataxis.fr/, например https://www.gatsbyjs.com/docs/quick-start/;
   
3. Безопасность, своими усилиями;
   
4. Семантическое версионирование;
   
5. Качественный, тщательно протестированный код;
   
6. Continuous delivery
   

Comments

[DevMan]

что такое бэкенд-шаблон?

[Владислав]

DevMan, Не знаю, я лишь хочу узнать потребность. Это может быть реализация любых непростых задач.
Например, части backend или гибкие фичи целиком, с REST / GraphQL Api

Иными словами, библиотека.

[DevMan]

Владислав Савченко, если не знаете/понимаете, то с чего решили что это бэкенд-шаблон?

[Владислав]

DevMan, спасибо за интерес к моему вопросу

Конечно, кстати, гибкое API далеко не всегда предпочтительно.

Я не знаю саму потребность, но я имею представление о задачах в бэкенд разработке, тем более, что впереди еще долгие месяцы изучения, консультаций и наверняка, хоть какое-то участие в Open source.

Моя проблема - я скверно оцениваю сроки. Я работал в 4 компаниях / крупных фриланс проектах, много учился, но долго нигде не задерживался. Поэтому вариант - frontend / backend / fullstack библиотека / паттерн - для меня очень важен.

[DevMan]

Владислав Савченко, читайте мой ответ.

Answer 1

[DevMan]

1. бэк - очень размытое понятие.
2. бэк очень привязан к языку и хотелкам конкретного человека.

я бы вообще не заморачивался бэком и делал только фронт.

Comments

[Владислав]

Спасибо!

Answer 2

[Александр Нестеров]

Насчет бекэнда.
Ну если только вы придумаете какое-то дико гениальное решение, в котором:
1. будет реализовано множество необходимых функций
2. С "шаблоном" будет крайне удобно и быстро работать.
3. При этом производительность будет можно сравнить с кодом на Си/плюсах
В противном случае - никто у вас ничего покупать не будет - бесплатных фреймворков слишком много.

Comments

[Владислав]

Спасибо!

Answer 3

[Вячеслав]

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