Isso parece meio arriscado se você não dominar bem o que irá fazer para o cliente; se houverem bugs (como aqueles bugs relativos a memória difíceis de encontrar que só aparecem depois de certa quantidade de uso, ou os bugs de concorrência de Threads que só aparecem às vezes) isto pode causar prejuízos para o cliente.
Provavelmente você também precisará estar apto a dar suporte ao software que desenvolver para o cliente, como para adicionar novas features nele no futuro, fazer hotfixes, etc. Para isso você precisa ter domínio sobre o código fonte, que tende a se tornar cada vez mais complexo e difícil de manter; então pode ser muito importante você saber fazer o software crescer de forma sustentável; você já usa Testes Automatizados? já conhece o TDD? Você já tem um “workflow” definido (como o GitFlow por exemplo)? Você já consegue ter no seu workflow coisas como Issues, ou user-histories, cronogramas de entregas, etc?
Veja que estou falando sobre pensar ao longo prazo, tendo uma estratégia sustentável para o que você vai começar como sendo um simples sistema para um cliente. É claro que você pode desenvolver um sistema para um cliente e avisar que não dará suporte, mas, isso complica um pouco as coisas para o cliente e para o programador que for dar suporte ao sistema que foi criado por você (é como se ele “caísse de pará-quedas” no seu sistema), além disso, você não estaria fazendo clientes, estaria dispensando eles.
Eu acho que se você conseguir definir um processo de desenvolvimento (um workflow) sustentável, e testá-lo usando-o para fazer um sistema, e então dar suporte a esse sistema adicionando novas features, fazendo hotfixes, tendo controle sobre as versões, e tendo controle sobre os ambientes “desenvolvimento”, “testes”, “produção”, você já vai estar muito bem preparado.
Conforme você desenvolver um sistema e ele crescer, você precisa estar atento se esse crescimento está sendo sustentável, ou se está ficando cada vez mais difícil alterar o sistema. Aqui vale considerar os princípios SOLID, o princípio DRY, e procurar que a arquitetura seja fácil de entender, modificar, depurar, e testar.
Você precisa ser capaz de resolver os problemas que seu cliente vai apresentar, seja de tecnologia, talvez até de legislação, etc., e dar suporte a ele explicando como usar o software (manual de usuário).
Eu vi alguns vídeos da série abaixo e achei bem interessantes: