i) É de qualificar como contrato de prestação de serviços inominado o contrato em que uma parte adjudica a outra a prestação de serviços na área informática, designadamente serviços de desenvolvimento e implementação de software “à medida”, com vista a proceder à automatização do processo do negócio de transporte de mercadorias no contexto do comércio eletrónico online desde o pedido do cliente até à entrega e envio da fatura;
ii) A apelante fez acionar a excepção de não cumprimento do contrato (art. 428º, nº 1, do CC), pois a A. só podia reclamar o pagamento da última prestação (facto 2.g.), após a aceitação final pelo cliente, a R./recorrente, o que não está comprovado nos autos;
iii) A excepção do contrato não cumprido deve ser sempre usada nos limites da boa fé, valendo tanto para o caso de falta integral do cumprimento, como para o cumprimento parcial ou defeituoso, tratando-se de uma excepção material dilatória que invocada com sucesso leva a que o contrato entre numa suspensão de eficácia até que se processe o cumprimento, ou eventualmente, seja resolvido com base na definitividade/impossibilidade do cumprimento, podendo ser invocada fora da simultaneidade temporal, pelo contraente que deva cumprir em segundo lugar (por ex: o serviço deve estar concluído antes do seu pagamento), e pressupondo a sua invocação a existência de um incumprimento minimamente grave, mas não ínfimo ou insignificante, devendo nos cumprimentos parciais ou defeituosos ser invocada proporcionalmente à quantidade/qualidade do incumprimento.

I – Relatório

 1. A..., S.A., com sede em ..., instaurou procedimento de injunção contra B..., Lda., com sede na ..., pedindo a condenação da ré a pagar-lhe a quantia de 7.424,29 €.

Alegou, em síntese, que celebrou com a ré um contrato de prestação de serviços, através do qual se obrigou a construir uma aplicação/desenvolvimento de software por um preço total de 52.500 €, encontrando-se por pagar a última prestação no valor de 5.250 €, acrescido de IVA, mais juros e outro.

A requerida deduziu oposição, na qual alegou que o contrato de prestação de serviços, de obtenção de um “software à medida” não está concluído, sendo que o produto final contratado apresentava defeitos.

A autora, respondeu, alegando, que o objeto do contrato celebrado consistia na prestação de horas de apoio técnico informático e não na entrega de um produto finalizado. E que inexiste lugar à excepção de não cumprimento invocada pela ré, no âmbito do contrato de empreitada. 

*

A final, foi proferida sentença que julgou procedente a acção e, em consequência, condenou a R. a pagar à A. a quantia de 6.457,50 €, acrescida de juros de mora à taxa legal supletiva comerciais contados a partir de 22.7.2021 até integral pagamento, acrescida da quantia de 40 €, absolvendo a R. da instância quanto aos demais pedidos.

*

2. A A. recorreu, formulando as seguintes conclusões:

1. A recorrente não se conforma com o julgamento dos pontos 2.º, 7.º, 8.º, 14.º e 15.º da matéria de facto provada, tão pouco com a não consideração dos factos alegados em 25.º a 33.º da oposição e do conteúdo do contrato de prestação de serviços e de fornecimento do software em apreço, cfr. Doc. 4 junto com a oposição, na parte em que elenca as características e os objectivos visados pelo dito software, os quais conduziram a que o Tribunal a quo considerasse que do contrato celebrado entre a recorrida e a recorrente emergia para aquela uma mera obrigação de meios.

2. Com o devido e merecido respeito, o Tribunal a quo julgou erradamente a vontade negocial expressa pelas partes quer na fase pré-negocial, quer nos escritos particulares que vieram a titular o contrato em apreço.

3. A redacção dos pontos 7. e 8. dos factos provados não encontra exacta correspondência com a alegação dos artigos 6.º, 7.º, 8.º da oposição que lhes serviu de base, tendo daqueles sido retirada a referência expressa à procura de um “software à medida” sem justificação plausível.

4. Sendo pacificamente aceite que um programa informático é constituído por um conjunto de instruções que compõem e descrevem uma tarefa a ser realizada por um computador, com vista à obtenção de determinado resultado, e pretendendo a recorrente, precisamente, uma aplicação informática que procedesse à automatização do processo do negócio de transporte de mercadorias no contexto do comércio electrónico online desde o pedido do cliente até à entrega e envio da factura – o referido Projeto C... – não se alcança a razão pela qual a alegação do artigo 6.º da oposição foi alterada, dela se retirando a referência expressa à procura de empresas especializadas na criação e desenvolvimentos de “software à medida”?

5. Atenta a relevância da questão para o apuramento do objecto do contrato e bem assim do alcance das manifestações de vontade expressas na fase pré-contratual,

6. Tal matéria encontra-se corroborada pelo Documento 2 junto com aquele articulado e bem assim, e além do mais, pela inquirição da testemunha AA, na audiência de julgamento de 30/06/2023, (registo áudio no ficheiro Diligencia_77825-22.6YIPRT_2023-06-30_10-27-03.mp3 entre os minutos 00:09:42 e 00:10:20 e entre os minutos 00:10:49 e 00:12:29), pelas declarações de parte de BB, legal representante da recorrente, na audiência de 01/06/2023 (registo áudio no ficheiro Diligencia_77825-22.6YIPRT_2023-06-01_16-03-57.mp3 entre os minutos 00:01:32 e 00:03:48 e entre os minutos 00:06:53 e 00:07:40) e ainda pela inquirição da testemunha AA, na audiência de julgamento de 11/03/2024, (registo áudio no ficheiro Diligencia_77825-22.6YIPRT_2024-03-11_10-17-13 (1).mp3 entre os minutos 00:06:38 e 00:07:44 e entre os minutos 00:07:53 e 00:09:08.

7. Donde, a redacção dos Factos Provados nos pontos 7. e 8. deverá ser alterada, por forma a ir ao encontro do efectivamente alegado nos artigos 6.º e 7.º da Oposição, nos seguintes e precisos termos:

7: No decorrer desse ano de 2019, a Ré procurou no mercado empresas especializadas na criação e desenvolvimento de um “software à medida” que procedesse à automatização do processo do negócio de transporte de mercadorias no contexto do comércio electrónico online desde o pedido do cliente até à entrega e envio da factura – o C...”.

8: Para tanto, forneceu às empresas então contactadas – entre elas a Autora – informação sobre o modelo de negócio a implementar e bem assim os requisitos tecnológicos que pretendia fossem desenvolvidos, sob a denominação C....

8. Em coerência, deverá ser retirado do elenco da factualidade não provada o facto inserto na sua alínea a.

9. Ainda com respeito à fase pré-contratual, foi consignado – e bem – no ponto 6 dos Factos Provados da D. sentença recorrida que «A ré foi constituída em agosto de 2019, com vista ao exercício da atividade de prestação de serviços de transporte de mercadorias no contexto do comércio eletrónico online, encontrando-se integrada no grupo empresarial D... SGPS, juntamente com outras sociedades comerciais que operam no mercado com o uso na marca registada E....»

10. A relevância deste ponto, que congrega o alegado nos pontos 3.º. 4.º e 5.º da oposição, articula com a circunstância de a recorrente ter procurado, no mercado, empresas especializadas na criação e desenvolvimento de um “software à medida” que procedesse à automatização do processo do negócio de transporte de mercadorias no contexto do comércio electrónico online desde o pedido do cliente até à entrega e envio da factura, conforme alegado em 6.º da oposição e corroborado pelos acima indicados meios de prova.

11. Donde, deverão ser aditados ao elenco dos Factos Provados os seguintes pontos:

6-A: No decorrer desse ano de 2019, a Ré procurou no mercado empresas especializadas na criação e desenvolvimento de um “software à medida” que procedesse à automatização do processo do negócio de transporte de mercadorias no contexto do comércio electrónico online desde o pedido do cliente até à entrega e envio da factura – o C...”.

6-B: Para tanto, forneceu às empresas então contactadas – entre elas a Autora – informação sobre o modelo de negócio a implementar e bem assim os requisitos tecnológicos que pretendia fossem desenvolvidos, sob a denominação C....

12. Sempre com o devido e merecido respeito, o Tribunal a quo julgou de forma imprecisa a matéria de facto relacionada com o conteúdo das obrigações da autora emergentes do contrato, designadamente ao caracterizar tal contrato no Ponto 2 dos Factos Provados, de forma genérica, como uma prestação de serviços de desenvolvimento de software.

13. Conforme resulta do escrito particular que titulou o contrato, junto como Documento 4 da oposição de fls..e cujo conteúdo ali se deu por integralmente reproduzido para todos os legais efeitos, e bem assim da proposta que o constitui, o leque das obrigações assumidas pela recorrida em termos de desenvolvimento e entrega do programa informático encontra-se concretizado em termos que deverão constar, discriminadamente, da matéria de facto provada.

14. Com efeito, em termos do âmbito da prestação de serviços, o Ponto 1 do escrito intitulado “Contrato de Prestação de Serviços” remete para os serviços de desenvolvimento de software descritos, aliás de forma minuciosa, na “Proposta Comercial”

15. Como tal, a redacção do Ponto 2 dos Factos Provados deverá ser alterada, fazendo referência, desde logo, às obrigações enunciadas na Proposta Comercial, nos seguintes termos:

2. No âmbito da sua atividade comercial, as partes celebraram, em 20.09.2019, um acordo escrito através do qual a autora obrigou-se a prestar serviços de desenvolvimento do software denominado C... e a fornecê-lo a ré, nos termos enunciados na Proposta Comercial junta a fls.. como Documento 4 da oposição, obrigando-se a ré a pagar à autora o preço total de €52.500 em prestações mensais, da seguinte forma:

a. Na data de celebração do presente contrato: 21.000,00€ + IVA;

b. A 27/09/2019: 5.250,00€ + IVA;

c. A 28/10/2019: 5.250,00€ + IVA:

d. A 28/11/2019: 5.250,00€ + IVA;

e. A 27/12/2019: 5.250,00€ + IVA;

f. A 28/01/2020: 5.250,00€ + IVA;

g. Após aceitação final pelo Cliente: 5.250,00€ + IVA.

16. Tendo em consideração, além do mais, o elenco das características e objectivos enunciados no escrito intitulado “Contrato de Prestação de Serviços” junto como Documento 4 da oposição de fls.., deverão ser aditados ao elenco dos Factos Provados os seguintes pontos:

2-A. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a integrar, através de interfaces de programação de aplicações (API’s - Application Programming Interface), com os sistemas da E... então em utilização, encapsulando toda a lógica de negócio do C..., incluindo ligação a gateways de pagamento, mecanismo de notificações, etc.;

2-B. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a facilitar a integração do C... em lojas online através de kits de desenvolvimento de software (SDK - Software Development Kit);

2-C. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a integrar com plataformas de eCommerce de terceiros, a selecionar de acordo com as prioridades definidas pelo Cliente;

2-D. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a integrar aplicações para acompanhamento de encomendas e gestão de processos dos utilizadores;

2-E. A autora obrigou-se ao desenvolvimento e fornecimento do referido software com o objetivo de assegurar que os utilizadores dos diversos canais de eCommerce possam solicitar e gerir os seus envios, efetuar pagamentos, acompanhar envios em trânsito, entre outros que venham a ser identificados e que se enquadrem no âmbito descrito;

2-F. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a assegurar funcionalidades direcionadas para os integradores, de modo a que possam de forma simples subscrever os serviços da E... e disponibilizá-los aos seus clientes;

2-G. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a assegurar, de forma autónoma o pedido de cotação, suportado pelo sistema ORCA, a confirmação de serviço, a gestão do envio, suportado pelo sistema GESREC, o tracking e a facturação;

2-H. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a receber pagamentos através dos sistemas MB MULTIBANCO, MB WAY, PAYPAL, MASTERCARD, VISA e BITCOIN;

2-I. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a suportar, desde a sua fase inicial (e sem prejuízo de posterior evolução ao longo do tempo de modo a suportar um número crescente de plataformas de eComerce de destino), bibliotecas, plug-ins ou extensões para suportar as seguintes integrações Websites HTML/CSS/JavaScript, Shopify, WooCommerce / WordPress / Magento;

2-J. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a seja possível aos integradores optar entre três cenários distintos:

1.º - Utilização simples do serviço de transporte C..., cobrando ao cliente e entregando à E... os custos de transporte;

2.º - Delegação no C... não só do serviço de transporte, mas também da cobrança, recebendo posteriormente o valor dos artigos vendidos em si;

3.º - Delegação completa no C... de todo o “carrinho de compras”, ficando a E... encarregue do levantamento, transporte, recolha e cobrança dos artigos comercializados;

2-K. A autora obrigou-se ainda, no contexto do desenvolvimento e fornecimento do referido software, a desenvolver uma aplicação web para disponibilizar todas as funcionalidades implementadas pelo “backend”, e que incluiria todas as gateways de pagamento e integrações atrás descritas, garantindo consistência da linguagem gráfica em dispositivos desktop ou mobile.

2-L. Para implementação dos requisitos gerais enunciados, a autora obrigou-se a alocar todos os recursos necessários, incluindo programadores, QA e testes, acompanhamento de um Arquiteto de Software, DevOps e a infraestrutura necessária ao ambiente de testes.

17. Cumpre sublinhar que a circunstância de o projecto inicial ter conhecido alturas alterações na sua fase de desenvolvimento – de resto, a maior parte delas decorrentes da incapacidade da autora em programar – não significa que, à partida, não existisse um produto final definido, como resulta de forma clarividente do teor da citada proposta comercial e para cujo conteúdo o clausulado do contrato remeteu para feitos da determinação das obrigações emergentes do contrato.

18. A recorrida obrigou-se, pois, a fornecer um software informático com determinadas características à recorrente, e não apenas à prestação de tempo e know how ao seu desenvolvimento, conforme, aliás, resulta da evidência de ter considerado, em 24/11/2021 que a implementação do Braintree jé se encontrava concluída e que considerava o projecto como concluído, ao mesmo tempo que desvalorizava os inúmeros problemas que impediam o funcionamento do software enunciados na matéria de facto provada (cfr., além do mais, pontos 20, 21, 25, 26, 28, 29, 33, 34, 35, 36 e 37 dos factos provados), referindo-se aos mesmos como bugs usuais e normais, cfr. declarações de parte do legal representante da recorrida, ficheiro Diligencia_77825-22.6YIPRT_2023-06-01_14-47-21.mp3 entre os minutos 00:37:57 e 00:38:35.

19. Sempre com o devido e merecido respeito, o Tribunal a quo julgou de forma imprecisa a matéria de facto inserta nos Pontos 17. e 18. dos Factos Provados, relacionada com o acordo estabelecido entre as partes, em Novembro de 2019, no sentido de prorrogar o prazo de execução do contrato para o mês de Março de 2020.

20. Em bom rigor, a narração do Ponto 17 revela-se contraditória ao alegado e provado, o que claramente se revela ser resultado de mero lapso de escrita – erro material. Com efeito, onde se diz “novembro de 2020” queria-se dizer “novembro de 2019” (sob pena de anacronismo).

21. Por seu lado, onde se diz “ré” pretendia-se dizer “autora” e onde se diz “autora” pretendia-se dizer “ré”, conforme se alcança da correspondência com o alegado em 25.º e 33.º da oposição, pois não foi a recorrente que alegou não ter facultado à autora a documentação necessária sobre as interligações, mas antes o contrário.

22. Sendo que a recorrente não aceitou essa imputação e que o acordo de prorrogar o prazo do contrato não tem qualquer nexo causal com essa circunstância, daí resultando que deverá apenas consignar-se, em substituição dos Pontos 17 e 18 dos Factos Provados, o seguinte facto:

17. Em novembro de 2019, as partes acordaram prolongar prazo de execução do contrato até ao mês de Março de 2020.

23. Aqui chegados, resta subsumir tal factualidade à questão de direito, a saber, ao julgamento da verificação da excepção do não cumprimento alegada pela recorrente para recusar o pagamento da última prestação devida após aceitação final pelo cliente, cfr. Ponto 2, alínea g) dos Factos Provados.

24. Questão esta que entronca com a natureza da obrigação assumida pela recorrida no âmbito deste contrato, a saber, se se vinculou a uma obrigação de meios ou a uma obrigação de resultado.

25. Estaremos todos de acordo, como nos ensina João Cura Mariano, in “Responsabilidade Contratual do Empreiteiro pelos Defeitos de Obra”, 7.ª edição, Almedina, p. 44, referido na D. sentença recorrida, que nas obrigações de meios o devedor compromete-se a desenvolver prudente e diligentemente certa atividade para a obtenção de determinado efeitos, mas sem assegurar que o mesmo se produza, enquanto nas obrigações de resulta o devedor compromete-se a conseguir com a sua atividade um determinado efeito útil.

26. Aliás, e em bom rigor, nem sequer a recorrente tem nada a apontar à solução de direito gizada pelo Tribunal a quo, atenta à matéria de facto ali considerada como provada.

27. A recorrente insurge-se – isso sim – contra o julgamento de matéria de facto, na parte em que conclui decorrer do contrato para a recorrida uma mera obrigação de meios, pois, insiste-se, resultou de tal compromisso o fornecimento de um software com as características e funcionalidades melhor elencadas na proposta comercial que é parte integrante do contrato, em determinado prazo e mediante o pagamento de determinado preço.

28. Emerge, pois, do contrato, uma obrigação de resultado.

29. Nas obrigações de resultado só há cumprimento quando o resultado efectivamente ocorrer, sendo que o devedor (do resultado) só é remunerado se tal resultado definidor da prestação ocorrer, presumindo-se deste a culpa pela sua não obtenção, cfr. artigo 799.º, n.º 1, do Código Civil.

30. Relevando-se evidente a correspectividade e interdependência da obrigação de fornecimento do programa informático com as características definidas na proposta comercial e a obrigação de pagamento da última tranche acordada, aliás condicionada no próprio contrato à aceitação do cliente, cfr. Ponto 3, al. g) do contrato e Ponto 2., al. g) dos Factos Provados, aceitação essa, evidentemente, à conformidade do produto, isto é, do resultado.

31. Aliás, nem sequer faria sentido condicionar o pagamento da última tranche à aceitação do adjudicante, caso não estivesse em causa uma obrigação de resultado.

32. Repete-se, não foram desenvolvidos nem entregues pela recorrida, além do mais, os items de integrações com plataformas de eCommerce de terceiros identificados no facto provado 33 e nem sequer o programa fornecido e entregue pela recorrida permitia executar uma operação tão linear com a emissão automática de uma fatura (cfr. facto provado 34), facto que, só por si, evidencia a circunstância de o programa informático não se encontrar concluído em termos de poder ser lançado ao mercado.

33. Estando aquelas obrigações ligadas entre si por um nexo sinalagmático, portanto, interdependentes ou recíprocas, a recorrente tinha o direito de se recusar a pagar a parte restante do preço – como fez – enquanto a recorrida não lhe entregasse o software com as características e funcionalidades elencadas no contrato e, em particular, no documento intitulado proposta comercial, sem prejuízo das alterações acordadas e melhor elencadas nos Factos Provados, isto é, de invocar excepção de não cumprimento do contrato, cfr. artigo 428.º, n.º 1, do Código Civil.

- // -

Com o devido respeito, a D. sentença recorrida decidiu assente em erro nos pressupostos de facto e de direito acima identificados, o conduziu à violação, além do mais, do disposto nos artigos 428.º e 799.º, n.º 1, do Código Civil.

Nestes termos, e nos melhores de direito aplicáveis, deverá a D. Sentença recorrida ser revogada em conformidade, julgando a acção improcedente, por não provada, e procedente a excepção do não cumprimento, absolvendo-se a recorrente do pedido.

É o que se pede e se espera desse Tribunal, assim se fazendo a costumada JUSTIÇA !                                                                                                                        

3. A R. contra-alegou, concluindo que:

A A Recorrida toma como seus, de modo integral, o Relatório, a Motivação e a Fundamentação da douta decisão recorrida, que, nessa medida, deverá ser plenamente confirmada.

B Importa sublinhar que a metodologia de trabalho contratada, e utilizada pela Recorrida para a execução do objecto do contrato, foi o modelo SCRUM e a metodologia agile, conforme resulta da proposta apresentada, do contrato e do depoimento da testemunha CC.

C Esta metodologia caracteriza-se como uma metodologia prática, cujo resultado resulta de inúmeras lapidações e ajustes que acontecem nas reuniões de cada sprint.

D Cada sprint consiste, portanto, num período (in casu de duas semanas) durante o qual a equipa desenvolve as funcionalidades definidas na reunião que encerra a sprint anterior.

E Neste sentindo entendeu corretamente o Tribunal a quo dar como provado o ponto 2 da matéria de facto.

F Ora, sendo esta a metodologia seguida, por comum acordo das partes, pode concluir-se, desde logo, qual foi a vontade negocial das partes: a de conceber um projecto que, partindo da ideia original, vai sendo redefinido nas team meetings.

G Ao contrário do que alega a Recorrente, não estamos perante a concretização de detalhes, mas antes perante a concretização do projeto em si, conforme resulta do pedido de orçamento, da proposta de orçamento, do contrato e do depoimento da testemunha CC (conforme transcrição).

H Analisado o pedido de orçamento, resulta que existem muitas reticências e muitas funcionalidades dependentes de concretização.

I Analisada a proposta de orçamento apresentada pela Recorrida, somos confrontados com um documento carecido de concretização.

J Em concreto, na proposta apresentada pela Recorrida para desenvolvimento do projeto designado “C...”, contam-se, pelo menos, 15 expressões de sugestão, possibilidade, escolha, alternativa ou eventualidade, que demonstram tratar-se do desenvolvimento embrionário de um software que vai sendo concretizado gradualmente pelo cliente.

K Por sua vez, ao contrário do que alega a Recorrente, não se trata de algumas funcionalidades terem sido alteradas. Verificaram-se inúmeras alterações ou afinações ao projecto, que implicam, obrigatoriamente, o dispêndio de horas de trabalho, o que resulta, desde logo, do depoimento da testemunha AA.

L O facto de a obrigação contratada ser uma obrigação de meios, não significa que não haja um resultado!!!

M Não deverão, assim, ser dados como provados os factos 6-A e 6-B, tal como requerido nas alegações de recurso. Da mesma forma, não deverá ser alterado o ponto 2 (com aditamento das alíneas a. a l.) dos

factos provados.

N Importa distinguir das exigências legítimas na fase de desenvolvimento do produto, das exigências adicionais de desenvolvimento adicional, bem como das exigências de manutenção que estavam, claramente, fora do âmbito do desenvolvimento do projecto.

O Certo é que resultou de toda a prova produzida que este incumprimento da Recorrente mais não foi do que uma tentativa de se furtar à sua obrigação.

P Entendeu também, erradamente, a Recorrente – com o devido respeito - adulterar o sentido da expressão “após aceitação final pelo cliente”, procurando dar a entender que se trataria de um resultado

carecido de um crivo final de aceitação por parte do Cliente (aqui a Recorrente).

Q À luz do modelo Scrum a resposta é fácil: esta aceitação diz respeito à conformidade do produto a que se chegou com as orientações dadas e com as opções do Cliente (a Recorrente) ao longo de todas as sprints.

R No que toca à alegação da exceção de não cumprimento (artigo 428º, n.º 1 Código Civil) importa recordar o Acórdão do Tribunal da Relação de Coimbra nº 131004/16.4YIPRT.C1, datado de 21-02-2018, bem como o Acórdão do Tribunal da Relação de Coimbra, nº 220/12.5TBSEI-B.C1, datado de 03-12-2019.

S Conforme resultou provado, a obrigação da Recorrida foi integralmente cumprida; tendo ultrapassado, aliás, o tempo contratado.

T Resta, portanto, que a Recorrente cumpra a sua obrigação: o pagamento da última prestação.

Nestes termos e nos mais de direito, deverá a o recurso interposto improceder, mantendo-se a decisão recorrida.

II - Factos Provados

1. A autora A... S.A. é uma sociedade cujo objeto social é a prestação de serviços de programação informática.
2. No âmbito da sua atividade comercial, as partes celebraram, em 20.09.2019, um acordo escrito através do qual a autora obrigou-se a prestar serviços de desenvolvimento de software e a ré obrigou-se a pagar o preço total de €52.500 em prestações mensais, da seguinte forma: a. Na data de celebração do presente contrato: 21.000,00€ + IVA;
b. A 27/09/2019: 5.250,00€ + IVA;
c. A 28/10/2019: 5.250,00€ + IVA:
d. A 28/11/2019: 5.250,00€ + IVA;
e. A 27/12/2019: 5.250,00€ + IVA;
f. A 28/01/2020: 5.250,00€ + IVA;
g. Após aceitação final pelo Cliente: 5.250,00€ + IVA.
3. A ré pagou as quantias previstas nos pontos 2a. a 2f.
4. A prestação indicada no ponto 2g. venceu-se a 2.09.2020.
5. A 13.07.2021 a autora solicitou à ré o pagamento da quantia mencionado no ponto 2g. no prazo de 8 dias.
6. A ré foi constituída em agosto de 2019, com vista ao exercício da atividade de prestação de serviços de transporte de mercadorias no contexto do comércio eletrónico online, encontrando-se integrada no grupo empresarial D... SGPS, juntamente com outras sociedades comerciais que operam no mercado com o uso na marca registada E...®.
7. Em 2019, a ré procurou no mercado empresas que procedessem à automatização do processo do negócio de transporte de mercadorias no contexto do comércio eletrónico online desde o pedido do cliente até à entrega e envio da fatura – Projeto C....
8. Nessa procura, a ré forneceu à autora informação sobre o modelo de negócio a implementar e bem assim as funcionalidades que pretendia que fossem integradas, suscetível de ser alterado e definido.

9. Em resultado dessa procura, a ré recebeu duas propostas, uma delas apresentada pela autora.

10. Em 24.09.2019, ocorreu uma reunião entre colaboradores da autora e da ré com o propósito de definir o plano de trabalhos (reunião kick-off).

11. Nessa reunião foram definidos sete componentes – denominados User Stories – a desenvolver pela autora.

12. Nessa mesma reunião decidiu-se que o desenvolvimento do projeto se iniciaria no dia 30.09.2019.

13. O desenvolvimento do projeto iniciou-se com construção de interfaces que permitem a interligação entre diferentes softwares (API’s).

14. Em 01.10.2019 a ré facultou à autora os acessos às API’s que já se encontravam desenvolvidas pela sua equipa interna.

15. Sendo que o desenvolvimento das restantes API’s, tais como os plugins para os métodos de pagamentos, os plugins para a interligação de lojas e ligação com os fornecedores da ré ficaram ao encargo da autora.

16. A autora encontrou dificuldades ao efetuar a interligação com um dos sistemas da ré (Olympus), o que determinou que a ré tenha abdicado desta funcionalidade sem redução do preço.

17. A ré, em novembro de 2020, alegou que não tinha facultado à autora toda a documentação necessária sobre as interligações.

18. As partes acordaram prolongar o desenvolvimento da aplicação até ao início de março de 2020.

19. Em 04.03.2020, a ré esquematizou, através de email remetido à ré, uma lista de assuntos pendentes relacionados com a evolução do projeto.

20. As intervenções e os pedidos formulados pela autora à ré, no seguimento desse ponto de situação manifestavam desconhecimento do trabalho realizado, ausência de documentação relativa ao trabalho já efetuado por parte dos colaboradores da autora alocados ao projeto.

21. A autora questionou a ré, a 9.03.2020, acerca da intenção de ativar as propostas adicionais relacionadas com a manutenção do programa informático.

22. No dia 9.03.2020 ainda não tinha sido feita a aplicação IOS.

23. A ré negou a ativação dessas propostas adicionais de manutenção.

24. Em data não concretamente apurada, mas em data anterior a 17.06.2020, a autora entregou uma versão da aplicação Android para ser testada pela ré.

25. A aplicação apresentou problemas bloqueantes que impediam o normal funcionamento e o próprio teste.

26. No período compreendido entre junho e novembro de 2020, a ré continuou a reportar problemas que impediam o funcionamento do software, tais como, além do mais, com os pagamentos automáticos através do sistema PayPal e da plataforma IfthenPay.

27. No dia 3.08.2020, a emitiu a fatura relativa à entrega final do projeto.

28. À data as aplicações não apresentavam sinais de estabilidade e o programa informático ainda apresentava falhas.

29. A ré continuou a reportar os problemas relacionados com os testes efetuados às aplicações designadamente a circunstância da API de pagamentos do PayPal ter deixado de funcionar para o sistema iOS.

30. Perante tal constatação, a autora sugeriu substituir esta API pelo sistema Braintree.

31. Questionada a propósito do impacto dessa substituição em termos de custos, a autora respondeu que se trataria de um impacto mínimo.

32. No dia 24.11.2020, a autora informou que a implementação do Braintree já se encontrava concluída e que considerava o projeto como concluído.

33. Como tal, a ré comunicou à autora que considerava que o software não tinha uma base minimamente estável.

34. A autora, no seguimento da reunião ocorrida entre 06.01.2020, procedeu à correção de alguns problemas sinalizados, mas as funcionalidades de pagamento e automatização de faturas ainda se encontravam inoperacionais.

35. No dia 23.03.2021, a autora teve conhecimento dos problemas identificados pela ré na aplicação Android.

36. Não foram desenvolvidos nem entregues com os seguintes items de integrações com plataformas de eCommerce de terceiros: a) Criação de “widgets” passíveis de serem facilmente incorporados e customizados; b) Shopify: criação de uma aplicação diretamente no “marketplace” da Shopify, c) WooCommerce / Wordpress / Magento: criação de módulos em PHP, recorrendo às API’s disponibilizadas por uma das plataformas.

37. O trabalho desenvolvido e entregue pela autora não permite a emissão automática de uma fatura.

38. O projeto foi desenvolvido por sprints (com duração de 2 semanas).

39. Estavam previstas 6 sprints para o desenvolvimento deste produto.

40. No início do projeto, a ré pretendia três apps mobile.

41. O projeto foi sendo alterado pelas partes.

42. A autora foi informada da integração do sistema Moloni no produto final.

43. O software permitia, à data da sua entrega pela autora, efetuar um pedido de recolha pelo cliente.

44. No decurso do desenvolvimento do produto final, a autora foi informada pela Paypal de que as suas bibliotecas de integração iriam ser descontinuadas e que deveriam integrar o Braintree.

45. A ré forneceu os links de acesso, mas estes deixavam de funcionar.

46. A ré não enviava no decurso dos sprints a informação relativa à lógica do negócio.

*

Factos não provados:
a. As empresas que a ré contactou para o Projeto C... eram especializadas na criação e desenvolvimento de um “software à medida”.

( …)

*

III - Do Direito

1. Uma vez que o âmbito objectivo dos recursos é delimitado pelas conclusões apresentadas pelos recorrentes (arts. 635º, nº 4, e 639º, do NCPC), apreciaremos, apenas, as questões que ali foram enunciadas.

Nesta conformidade, a única questão a resolver é a seguinte.

- Alteração da matéria de facto.

- Cumprimento/Incumprimento do contrato.

2. A recorrente impugna a decisão da matéria de facto, invocando que: a matéria dos factos provados 7. e 8. deve ser dada por provada, segundo a redacção que propõe, retirando-se a a) dos factos não provados; que o facto provado 2. deve ficar provado, mas com alteração e vários aditamentos; e, ainda, os factos provados 17. e 18., que devem ser fundidos, com modificação da sua redacção, que indica. Tudo de acordo com os meios probatórios que menciona (cfr. conclusões de recurso 1. a 22.).

Por sua vez, a recorrida opõe-se, conforme as conclusões (as B a M) das suas contra-alegações de recurso.

Na motivação da decisão da matéria de facto escreveu-se que:

“O tribunal formou a sua convicção mobilizando os documentos juntos aos autos, concatenados com o teor das declarações de parte do representante legal da autora e do representante legal da ré e dos depoimentos das testemunhas ouvidas em sede de audiência de julgamento, e ainda em conjugação com as regras da experiência comum, levando em consideração as regras legais de repartição do ónus da prova, nos termos que abaixo se consignam.

Quanto à prova documental, foi apreciado e valorado o teor dos seguintes elementos documentais juntos aos autos:

(…)

- Apresentação da C... (documento 2 junto com a oposição);

- Proposta para a C... apresentada pela A... (documento 3 junto com a oposição);

- Contrato de prestação de serviços celebrado entre as partes (documento 4 junto com a oposição);

(…)

Foram valoradas as declarações de parte do representante legal da autora DD (administrador da A..., S.A. desde 2017) que referiu que a ré encomendou software para e-commerce, que incluía site e app móveis de IOS e Android. Foi explicado que o desenvolvimento de software seguiu um método flexível – modelo Scrum – fracionado em sprints de 2 semanas. Durante os vários sprints, segundo o representante legal da autora, as partes iam acordando nos próximos passos e nos ajustes a fazer ao projeto inicialmente definido. Reiterou por diversas vezes o representante legal da autora que o produto que foi inicialmente contratualizado poderia, no final dos sprints, não coincidir com o produto alcançado, uma vez que o backlog (uma espécie de caderno de encargos) ia sendo alterado por acordo de ambas as partes. Segundo o representante legal da autora, aquilo que se obrigaram, que no seu entender foi um “pacote” de tempo da equipa a fim de desenvolver o produto pretendido pela ré, estava concluído. Ainda que genericamente, referiu igualmente a existência de instabilidade de serviços da ré, nomeadamente o ORCA.

Confrontado com o documento 7 junto com a oposição referiu o representante legal que os serviços nele elencados não estão completos porque nada dizem sobre a lógica do negócio a implementar, ponto essencial para desenvolver as aplicações que a ré pretendia.

Perante o consumo de sprints sem que o projeto se encontrasse a ser desenvolvido como inicialmente projetado, a autora sugeriu que se parasse o projeto a fim de a ré definir o objeto do negócio, o que foi recusado.

Quanto ao produto entregue a final, o representante legal da autora referiu que foi entregue uma versão em pré-produção (versão beta) que seria gerida pela ré, sendo que estava utilizável.

Quanto ao funcionário EE, foi referido que o mesmo trabalhava na vertente de lógica de negócio, tendo saído da empresa da autora em março de 2020, num momento em que os sprints contratados já se haviam consumido.

O objetivo inicialmente delineado, referiu o representante legal da autora, foi a conceção de 2 aplicações móveis, BackOffice e uma aplicação de gestão. Quanto à aplicação IOS, a mesma nunca foi entregue, admitiu, afirmando que tal se deveu, na realidade, ao facto de a ré nunca ter entregado o código da app store para que pudesse ser a aplicação publicada. No entanto, entregaram a versão Android da aplicação. Quanto à entrega da aplicação de BackOffice, o representante legal da autora mostrou-se menos seguro quanto à sua efetiva entrega.

Questionado sobre o motivo do atraso na entrega das aplicações que tinham ficado definidas, o representante legal da autora atribui à falta de definições do plano apresentado pela ré a culpa pelo atraso. O representante legal da autora afirmou que o Shopify não foi integrado na aplicação, tendo o representante legal da ré, nas respetivas declarações de parte, e em complemento, referido que abdicou da tal integração por causa dos atrasos.

Declarações de parte do representante legal da ré FF (sócio gerente da sociedade ré desde 2019) apresentou uma versão diversa daquela que havia sido apresentada pelo representante legal da autora, porquanto foi insistindo variadas vezes que o objeto contratado consistia no desenvolvimento de um produto, negando perentoriamente que não foi adquirido tempo e que não foi celebrado um contrato de prestação de serviços.

Referiu BB que o modelo adotado consistir numa “parceria” da qual resultavam obrigações para ambas as partes: tudo o que consistia em lógica de negócio incumbia à autora de desenvolver.

De forma coincidente, o representante legal da ré identificou igualmente um atraso no desenvolvimento do projeto, pelo que negou, não só perante o tribunal, como também perante a autora, segundo disse, que tal atraso se devesse à falta de colaboração da ré no desenvolvimento de integrações que estavam dependentes da ré. Aquando da reunião que existiu a fim de ser proposto, pela autora a pausa do projeto, as aplicações móveis, segundo o representante legal da ré, ainda não estavam desenvolvidas e faltam cerca de 2 sprints para terminar o tempo contratado.

Aquando da entrega da versão-teste da app Android, referiu os que os funcionários da ré verificaram a existência de problemas bloqueantes que foram de imediato reportados à autora (cfr. documento 12 junto com a contestação). Relatou o representante legal da ré alguns dos problemas identificados: a aplicação não mostrava o estado do envio, não permitia o pagamento através do paypal, a referência multibanco não era gerada e a fatura só era gerada na primeira utilização. Algumas versões-teste enviadas pela autora, segundo o representante legal da ré, não permitiam fazer o seu respetivo download. Os problemas reportados, segundo o representante legal da ré, não foram totalmente resolvidos. A ré sanou sozinha e sem auxílio da autora o problema de integração da Paypal.

Assumindo que a ré não pagou a última tranche do pagamento, referiu o representante legal da ré que não procedeu ao pagamento porque não tinham o MVP (minimum viable product) sendo que a não apresentação de um produto a funcionar e viável não era imputável à ré. Referiu que sempre deu acesso a todos os serviços que a autora precisou para fazer as devidas integrações.

Explicou, por fim, o representante legal da ré que os dois blocos macro contratados consistiam no BackOffice: que consistia no algoritmo necessário para a encomenda, desta a criação do envio até à faturação, pelo que este interface seria posteriormente ligado às aplicações móveis.

Foram valorados os depoimentos das seguintes testemunhas:

- CC (gestor de projetos na A... há 10 anos) referiu, quando confrontado com o documento 16 junto com a oposição, que a ré demorava a responder às solicitações da autora o que para além de traduzir um juízo subjetivo, é contrariado pelos sucessivos emails juntos aos autos cujas respostas são tendencialmente enviadas no dia do email ou no dia seguinte. Explicou a testemunha que o documento 5 junto com a oposição foi entregue no primeiro sprint e consistia num plano genérico, sendo que o acordado, segundo a testemunha, foi que a ré que se responsabilizou pelos interfaces dos CTT e DHL, mas no decurso do projeto percebeu-se que tinha de ser a autora a fazer, tendo integrado a DPD. Não foram feitas todas as integrações de transportadores por falta de tempo, segundo a testemunha CC.

(…)

- AA (fornecedor do projeto da ré) participou no projeto da ré, e em sede de inquirição referiu que atenta a falta de capacidade técnica da ré para efetuar as aplicações que pretendiam fizeram um caderno de encargos a fim de contratar uma empresa especializada e competente tecnicamente. Foi a testemunha AA o responsável pela elaboração da proposta constante do documento 2 junto com a oposição. Percorrendo o documento 2 junto com a oposição, a testemunha AA referiu que as lojas Pick me nunca foram integradas no produto apresentado pela autora, pelo que só o DPD foi integrado. Da inquirição da testemunha resultou que foi apresentado um “bolo de ideias” (nas suas palavras) com o projeto que pretendiam que fosse feito, sendo que a autora apresentou um período de tempo (conjunto de sprints) no qual executariam as tarefas que tinham sido pedidas, tendo referido que “deixaram abertura” para durante a execução do projeto incluírem ou excluírem funcionalidades ou lojas.

Era nas reuniões ao início de cada sprint, segundo a testemunha, que se definiam as funcionalidades a integrar aquele sprint. De forma espontânea referiu que a proposta da A... correspondia à expectativa do projeto que a ré pretendia alcançar, sendo que o contratado não era específico em todos os pontos. Referiu a testemunha que foram pedidas 2 aplicações de loja e uma aplicação parceiro esta (até então nunca referida) que foi abdicada por não haver mais tempo. O tempo fixado para o cumprimento do projeto apresentado pela ré foi fixado pela autora atendendo ao trabalho a executar e que a autora considerou ser necessário para o executar.

Ao longo da sua inquirição, a testemunha reforçou que durante a execução do projeto houve cedências quanto às funcionalidades e integrações que iam sendo feitas. Para além da Shopify, segundo a testemunha, nenhuma plataforma e-commerce foi integrada, nem foi integrado o sistema de subscrições. Mais uma vez, à semelhança do que fora dito pelo representante legal da ré, mencionou a testemunha que o processo de envio da aplicação entregue nunca chegou ao fim. Explicou a testemunha, à semelhança do que foi dito pelo representante legal da ré, foi GG quem fez os testes das versões que iam sendo enviadas pela autora à ré, sendo que depois dos testes eram pedidas à autora correções.

-Patrícia HH, cônjuge do representante legal da ré, pertence ao grupo que a ré integra e participou na fase final do desenvolvimento do projeto a fim de testar as versões enviadas pela autora. Segundo a testemunha, a sua área de intervenção foi sempre o frontend, e não o programa em si, pelo que reportava diretamente com a autora os problemas que encontrava. Os problemas que encontrou estavam identificados nos documentos 12, 16 e 20 juntos com a oposição, tendo a testemunha se recordado de alguns problemas neles identificados. Segundo a testemunha, não foi apresentada uma versão “aceitável”, isto é, uma versão que, nas suas palavras, conferisse credibilidade ao cliente, pelo que segundo disse não estava a aplicação entregue pela autora pronta para entrar no mercado. Por fim, referiu a testemunha que depois do envio à autora do relatório do documento 20 junto com a oposição, não foi enviada por esta mais nenhuma versão melhorada.

(…)

Foram as partes igualmente unânimes no que respeita ao teor do documento 2 junto com a contestação, elaborado pela aqui testemunha AA: tratava-se de uma apresentação do produto que a ré pretendia (ainda que em traços genéricos e sem concretizações dos vários elementos a elaborar) a fim de permitir que as empresas competentes apresentassem as respetivas propostas, como efetivamente a autora fez (documento 3 junto com a contestação). No entanto, o representante legal da autora, em sede de declarações de parte, referiu que aquando da proposta encontrava-se ainda a faltar a costumer journey, isto é, o a descrição detalhada do que o cliente pretende fazer com determinada funcionalidade.

Quanto à aplicação Moloni, respeitante à emissão de faturas, o representante legal da autora referiu que tal funcionalidade era controlada pela ré e que a faturação estava a funcionar o que foi negado pela testemunha GG. Por sua vez, o representante legal da ré referiu que a ré, que tinha a aplicação Moloni, entregou o API à autora para que aquela integrasse o Moloni no software de faturação que estavam a criar. BB referiu que as API internas foram entregues logo no início do contrato à autora e que a mesma não as integrou no produto final.

A pedra de toque no presente caso é compreender o que foi efetivamente contratado: porquanto segundo a autora, adotando o modelo scrum, ficaram inicialmente definidos os vetores custo e preço, ao passo que segundo a ré o que ficou definido foi o preço e o âmbito.

Porém, o próprio representante legal da ré foi referindo que o âmbito do negócio ia sendo concretizado ao longo do desenvolvimento do projeto. Questionado acerca do que havia sido inicialmente contratado o representante legal da ré disse, num primeiro momento, que foi um produto definido, no entanto admitiu, posteriormente, que o âmbito do negócio seria concretizado à medida que era desenvolvido, tendo em momento posterior referido que tais ajustes, apesar de possíveis e efetivamente realizados, não eram queridos por parte da ré, o que se estranhou atendendo ao modelo adotado.

Os representantes legais de ambas as partes disseram que foram feitos sprints adicionais, o que levanta a questão de saber efetivamente se o que foi acordado foi um período de tempo, ou por sua vez, um produto final. Porque sendo a primeira a solução correta, não se compreende como forneceu a autora, sem contrapartida, mais sprints de 2 semanas.

A testemunha CC reiterou que foi adotado o modelo scrum e que foram fixados os vetores custo e tempo, sendo que diretamente inquirido sobre a contradição perante a realização de mais sprints do que os contratados, referiu a testemunha que se deveu a “boa vontade”.

Ora, da proposta constante do documento 3 junto com a oposição resulta que findo o período piloto, a implementação será considerada como definitivamente aceite, sendo implementadas as alterações solicitadas num prazo máximo adicional de 2 sprints. Quer isto dizer que à ré foram dadas 4 semanas para identificar erros e alterações ao produto apresentado, o que parece justificar que o desenvolvimento do projeto tivesse durado para além das 12 semanas.

Apesar de não ser desconhecido ao tribunal que o nomen iuris dado pelas partes ao contrato celebrado não vincula o tribunal, a verdade é que do contrato celebrado constante do documento 4 junto com a oposição resulta que as partes celebraram um contrato de prestação de serviços de desenvolvimento de software descritos na proposta comercial com as características e horizonte temporal aí indicados.

Em síntese, os factos provados elencados nos pontos 1 a 6, … resultaram do acordo tácito entre as partes, por falta de impugnação dos mesmos (artigo 574.º, do CPC). Para além disso, foram ainda apurados através do teor do contrato celebrado entre as partes e junto aos autos. Daí resulta que o objeto do contrato seria o desenvolvimento de software, sendo que o pagamento faseado do preço final resulta igualmente das faturas emitidas pela autora e juntas aos autos. Na realidade, nunca a ré colocou em causa o não pagamento da última fatura emitida pela autora, referente à última tranche devida pelo serviço prestado, faltando, deste modo, 5.250€ relativos à fatura n.º 165.

O conteúdo do contrato, na adoção do modelo scrum, era definido por sprints. Isto é, se inicialmente foi pedido à autora, de forma parcamente detalhada, o que era pretendido (com indicações genéricas das funcionalidades pretendidas no produto final e descritas no documento 2 junto com a oposição), a verdade é que os serviços a desenvolver e a prestar iam sendo definidos à medida que o contrato ia sendo executado. Isso resultou claro da prova produzida em audiência de julgamento, porquanto todos os intervenientes referiram que quer na apresentação do que era pretendido por parte da ré, como ao longo da execução do contrato foram feitos ajustes nos serviços, operações e funcionalidades que iam sendo realizadas e integradas. Deste modo, conforme foi afirmado pela testemunha AA, pessoa que esteve à frente da apresentação do projeto pretendido, a ré tinha conhecimento que inevitavelmente o modelo apresentado seria o método scrum, um modelo dinâmico para um projeto que foi apelidado igualmente de dinâmico, sabendo a ré ab initio que nem todas as funcionalidades elencadas na fls. 23v. dos autos podiam ou tinham que estar no produto final apresentado. A ré pretendia necessariamente uma aplicação que funcionasse. E se isso não é colocado em momento algum em crise, isto é, que a vontade da ré se traduzia na obtenção de um produto final que funcionasse, que iria para além do produto mínimo viável, a testemunha explicou que eram fixados objetivos parciais, o que dava flexibilidade quanto ao produto final que ia ser entregue. O desenvolvimento das interligações entre as demais funcionalidades pretendidas pela ré ia sendo definido ao longo do contrato.

O método de execução do contrato celebrado foi o cerne da discussão ocorrida nos autos e sobre a qual menos consenso houve. Se é verdade que todos os intervenientes processuais referiram a utilização do modelo scrum, baseado num programa flexível de desenvolvimento de software, foram já díspares as versões sobre a concreta efetivação daquele modelo no caso concreto. Assente em objetivos gerais que a ré pretendia ver definidos e implementados no produto contratado e vertidos no documento 5 junto com a oposição (as denominadas user stories indicadas no facto provado sob o ponto 11), foram duas as versões tendencialmente apresentadas. Como acima vimos, se por um lado, o representante legal da autora e as testemunhas por si arroladas referiram que os serviços informáticos prestados pela autora eram e foram definidos em função do tempo despendido e delineado à partida para o desenvolvimento do produto que a ré pretendia, por outro lado, o representante legal da ré tentou contrariar tal versão, afirmando e reiterando veementemente que o que havia sido contratada a construção de 2 aplicações móveis e um aplicação de backend. No entanto, se por um lado a testemunha AA tentou secundar este entendimento, a verdade é que ao longo do seu depoimento demonstrou que o produto final não foi concretamente fixado, o que se encaixa com o modelo scrum, e que o mesmo ia sendo, por acordo ou necessidade, ajustado durante o decurso do tempo, com a retirada ou inserção de novas funcionalidades (facto provado sob o ponto 41, com resulta evidente, para além do mais, dos documentos junto na audiência realizada a 16.06.2023).

(…)

Os factos sob os pontos … 17 foram julgados como provados em virtude de análise dos elementos documentais juntos autos, nomeadamente o documento 7 e bem ainda das declarações de parte dos representantes legais das partes, …. Tendo ainda sido mencionada por aqueles a proposta de adiamento do projeto fundada no atraso do desenvolvimento do projeto por falta de definição da lógica de negócio, assim como a sua não aceitação.

O facto vertido no ponto 18 resultou provado pelo confronto com as notas das reuniões entregues na audiência de julgamento realizada a 16.06.2023, sendo que os representantes legais referiram igualmente o prolongamento do desenvolvimento da aplicação em virtude das dificuldades sentidas (ainda que a “culpa” desses atrasos tenha criado divergência).

(…)

No que concerne à matéria vertida nos pontos 6.º a 8.º da oposição, importa em primeiro lugar sanar aquele que parece ser um evidente lapso de escrita da oposição, porquanto na oposição apresentada consta que foi a autora quem procurou no mercado empresas especializadas na criação e desenvolvimento de software. Essa procura no mercado, como foi explanado pela testemunha AA, foi realizada por parte da ré, B..., que contactou com três empresas que conheciam a área de intervenção da E... e que tinham competências para “interpretar as necessidades e juntar as valências” pretendidas pela B... no projeto C.... Segundo a testemunha AA, à data do período negocial em causa, era gerente da sociedade ré tendo por esse motivo conhecimento do iter negocial. Segundo o mesmo foram por si recebidas duas propostas: a da A..., aqui autora, e a da empresa F... (facto provado sob o ponto 9). Ora, se o tribunal, do depoimento da testemunha, ficou convencido que a ré procurou junto do mercado quem pudesse realizar o projeto que pretendiam, o tribunal desconhece quais as demais empresas contactadas, desconhecendo ainda a sua especialização (facto não provado sob a alínea a. e facto provado sob o ponto 7).

Quanto à informação prestada pela ré à autora em momento prévio à celebração do contrato, com o objetivo de a ré obter para si propostas contratuais a fim de celebrar o contrato, conforme resultou amplamente discutido nas sessões de julgamento realizadas, o objetivo pretendido pela ré encontrava respaldo na apresentação constante do documento 2 junto com a oposição. Ora, foi este o documento que serviu de base à proposta apresentada pela A..., para a qual, na realidade a A... remete em determinados pontos no documento 3 junto com a oposição. A apresentação do “produto” pretendido pela ré foi realizada pela testemunha AA, com base no documento 2 junto com a oposição. E é deste documento que se retira o “modelo de negócio a implementar e bem assim os requisitos tecnológicos que pretendia que fossem desenvolvidos”. Como referiu a testemunha AA na sua primeira inquirição, foi apresentado à autora um “bolo de ideias” constante naquela apresentação. Foi o mesmo que havia sido dito pelo representante legal da autora que referiu que o que fora encomendado foi o software para e-commerce com funcionalidades de entrega de serviços e interação com clientes, sendo que o produto final iria ser definido a cada sprint.

Ora, resultou comprovado da conjugação da prova documental com a prova testemunhal, mormente da testemunha AA, que foi explicado à autora o que se pretendia: a interligação das funcionalidades previstas na fls. 23v. dos autos (orçamento, lojas pick me, plano de subscrição, tracking, integrações com parceiros, CRM particulares, CRM lojas, integração marketing digital, integrações com lojas, faturação, modelos de pagamento, my C..., app gestão de loja, app particular e app parceiro), num modelo de negócio dirigido tendencialmente aos consumidores, totalmente informatizado e sem personalização – facto provado sob o ponto 8.

Como explicou também a testemunha AA, as diferentes cores constantes do diapositivo de fls. 23v. dos autos têm diferentes significados: as funcionalidades a vermelho eram urgentes e obrigatórias, as brancas, apesar de serem importantes não eram prioritárias e podiam não ser desenvolvidas logo, mas sim ao longo do tempo e a funcionalidade a verde (a faturação) tinha ainda de ser trabalhada em conjunto, estando à data da apresentação do que a B... pretendia ainda indefinida quanto à sua contratação. Ou seja, retira-se da prova produzida e da explicação detalhada da testemunha AA, que esteve encarregue da apresentação do produto pretendido, que não existia definido e delimitado qual o produto final que a ré pretendia comprar, mas sim foi apresentado um conjunto de funcionalidades, suscetíveis de serem, ao longo do tempo, excluídas ou alteradas cuja integração se pretendia, sendo que não existia completamente definido o que deveria ser entregue, tal ia sendo definido em conjunto.

Assim, antes da apresentação da proposta por parte da autora, o que foi apresentado foram os elementos negociais constantes do documento 2 junto com a oposição, sendo a tais elementos a que se reporta o facto provado sob o ponto 8. No entanto, é apodítica a latitude de tal apresentação, sendo ambígua e deixando claramente abertura para ser definida pela ré.”.

2.1. Relativamente à alteração da redacção do facto provado 2., como defendido pela recorrente, temos por boa a sua sugestão, independentemente dos depoimentos das testemunhas CC e AA, convocadas pela recorrida nas suas contra-alegações de recurso, atendendo ao que consta conjugadamente do teor do Ponto 1. do contrato de prestação de serviços celebrado por escrito entre as partes (Doc. 4 junto com a oposição, a fls. 41 v./52 v.) que remete para os serviços de desenvolvimento de software descritos na proposta comercial (Doc. 3 junto com a oposição, a fls. 32/41).   

Importa, pois, fazer reflectir tal alteração no aludido facto 2. (a negrito, ficando a anterior redacção em letra minúscula), que assim ficará redigido:

2. No âmbito da sua atividade comercial, as partes celebraram, em 20.09.2019, um acordo escrito através do qual a autora obrigou-se a prestar serviços de desenvolvimento do software denominado C... e a fornecê-lo a ré, nos termos enunciados na Proposta Comercial junta como Documento 4 da oposição, e a ré obrigou-se a pagar à autora o preço total de €52.500 em prestações mensais, da seguinte forma:

a. Na data de celebração do presente contrato: 21.000,00€ + IVA;

b. A 27/09/2019: 5.250,00€ + IVA;

c. A 28/10/2019: 5.250,00€ + IVA:

d. A 28/11/2019: 5.250,00€ + IVA;

e. A 27/12/2019: 5.250,00€ + IVA;

f. A 28/01/2020: 5.250,00€ + IVA;

g. Após aceitação final pelo Cliente: 5.250,00€ + IVA.

2.2. Respeitante aos aditamentos ao facto provado 2., como propostos pela apelante, também os temos por pertinentes, independentemente das declarações de parte de DD, invocadas pela apelante nas suas alegações de recurso, atendendo ao que consta do teor da referida proposta comercial seu Ponto 2., que está anexa ao mencionado contrato de prestação de serviços celebrado entre as partes.  

Importa, assim, adicionar tal matéria aos factos provados, sob 2-A. (a negrito), nos seguintes termos:

2-A. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a integrar, através de interfaces de programação de aplicações (API’s - Application Programming Interface), com os sistemas da E... então em utilização, encapsulando toda a lógica de negócio do C..., incluindo ligação a gateways de pagamento, mecanismo de notificações, etc.;

2-B. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a facilitar a integração do C... em lojas online através de kits de desenvolvimento de software (SDK - Software Development Kit);

2-C. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a integrar com plataformas de eCommerce de terceiros, a selecionar de acordo com as prioridades definidas pelo Cliente;

2-D. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a integrar aplicações para acompanhamento de encomendas e gestão de processos dos utilizadores;

2-E. A autora obrigou-se ao desenvolvimento e fornecimento do referido software com o objetivo de assegurar que os utilizadores dos diversos canais de eCommerce possam solicitar e gerir os seus envios, efetuar pagamentos, acompanhar envios em trânsito, entre outros que venham a ser identificados e que se enquadrem no âmbito descrito;

2-F. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a assegurar funcionalidades direcionadas para os integradores, de modo a que possam de forma simples subscrever os serviços da E... e disponibilizá-los aos seus clientes;

2-G. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a assegurar, de forma autónoma o pedido de cotação, suportado pelo sistema ORCA, a confirmação de serviço, a gestão do envio, suportado pelo sistema GESREC, o tracking e a facturação;

2-H. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a receber pagamentos através dos sistemas MB MULTIBANCO, MB WAY, PAYPAL, MASTERCARD, VISA e BITCOIN;

2-I. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a suportar, desde a sua fase inicial (e sem prejuízo de posterior evolução ao longo do tempo de modo a suportar um número crescente de plataformas de eComerce de destino), bibliotecas, plug-ins ou extensões para suportar as seguintes integrações Websites HTML/CSS/JavaScript, Shopify, WooCommerce / WordPress / Magento;

2-J. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a seja possível aos integradores optar entre três cenários distintos:

1.º - Utilização simples do serviço de transporte C..., cobrando ao cliente e entregando à E... os custos de transporte;

2.º - Delegação no C... não só do serviço de transporte, mas também da cobrança, recebendo posteriormente o valor dos artigos vendidos em si;

3.º - Delegação completa no C... de todo o “carrinho de compras”, ficando a E... encarregue do levantamento, transporte, recolha e cobrança dos artigos comercializados;

2-K. A autora obrigou-se ainda, no contexto do desenvolvimento e fornecimento do referido software, a desenvolver uma aplicação web para disponibilizar todas as funcionalidades implementadas pelo “backend”, e que incluiria todas as gateways de pagamento e integrações atrás descritas, garantindo consistência da linguagem gráfica em dispositivos desktop ou mobile.

2-L. Para implementação dos requisitos gerais enunciados, a autora obrigou-se a alocar todos os recursos necessários, incluindo programadores, QA e testes, acompanhamento de um Arquiteto de Software, DevOps e a infraestrutura necessária ao ambiente de testes.

2.3. Quanto aos factos provados 7. e 8. cuja redacção a recorrente propõe, retirando-se a a) dos factos não provados, essa matéria reporta-se à alegação facual produzida nos art. 6º e 7º da oposição, a saber:

“6. No decorrer desse ano de 2019, a Autora procurou no mercado empresas especializadas na criação e desenvolvimento de um “software à medida” que procedesse à automatização do processo do negócio de transporte de mercadorias no contexto do comércio electrónico online desde o pedido do cliente até à entrega e envio da factura – Projeto C....

7. Para tanto, forneceu às empresas então contactadas – entre elas a Autora – informação sobre o modelo de negócio a implementar e bem assim os requisitos tecnológicos que pretendia fossem desenvolvidos – Doc. 2, cujo conteúdo aqui se dá por integralmente reproduzido para todos os legais efeitos.”.

O indicado Doc. 2 (junto com a oposição, a fls. 14 v/31) corresponde ao modelo de negócio a implementar bem como os requisitos tecnológicos que a apelante pretendia que fossem implementados. Este modelo foi confirmado nas declarações de parte da recorrente pelo seu sócio-gerente, engenheiro informático BB (na sessão gravada da audiência de julgamento de 1.6.2023).  

AA, ex sócio-gerente da recorrente, e mentor do projecto, explicou isso mesmo, que foi ele o autor do projecto tendo contactado empresas para os efeitos pretendidos, designadamente a autora e outra, a F... (na sessão gravada de 30.6.2023), e que reconfirmou explicitamente (na sessão gravada de 11.3.2024), nos seguintes termos, que a recorrente transcreveu e cuja transcrição aproveitamos:

“[00:06:38] Mandatário da Ré: Pronto. E aqui quando diz que procuraram no mercado soluções tecnológicas para isso, está a falar de quê? De um problema informático, de um...?

[00:06:45] AA: Não, nós sabíamos que não havia um programa que nós fossemos ao mercado comprar e utilizar, sabia que não existiam, mas sabíamos que muitas das possibilidades que nós queríamos, elas já existiam no mercado. [impercetível] já existia mercado, situações de gestão de modelos de pagamento, modelos de subscrição, [impercetível] informática [impercetível], portanto, todas estas pequenas ferramentas já existiam no mercado uma parte delas, as próprias lojas de distribuição, a gestão de loja, a chamada [impercetível], todo esse tipo de coisas já existia. Agora, juntar isto tudo e criar um programa que juntasse isto tudo, nós sabíamos que não existia, nós queríamos ser os primeiros a ter esse programa, desenvolver o programa, sabíamos que imediatamente todo o investimento [impercetível] e ficar [impercetível] este trabalho.

[00:07:41] Mandatário da Ré: Para fornecer-vos esse programa?

[00:07:44] AA: E fornecer-nos este programa.

(…)»

[00:07:53] Meritíssima Juiz: Consegue o Documento 2 da Oposição, [impercetível]. Diga-me só uma coisa: a Oposição faz menção a uma expressão e eu quero perceber essa expressão que é “à procura de software à medida”. Este software à medida então é as empresas que têm estas várias funcionalidades serem eles a juntar o próprio programa, é isso? Era isso que vocês queriam?

[00:08:22] AA: Não. As empresas [impercetível].

[00:08:27] Meritíssima Juiz: OK, as pessoas a quem vocês pediram propostas?

[00:08:29] AA: Sim, nós pedimos propostas a 3 empresas, acho eu, 3 empresas e nós já fomos criteriosos porque há empresas que achávamos que já conheciam a nossa loja, já conheciam o nosso modelo de negócio, já não fomos ao mercado de forma aberta, já fomos de uma forma mais ou menos selecionada. E aquilo que nós queríamos era que esses parceiros [impercetível] estas nossas necessidades e construíssem uma solução que juntasse todas estas valências.

[00:09:03] Meritíssima Juiz: Ou seja, o que queriam é que eles criassem um produto especificamente para as vossas necessidades, é isso?

[00:09:08] AA: Sim, sim Meritíssima Juiz.

(…)»

Como a recorrente realça, acertadamente, aqui, com clareza, a testemunha explica que o programa informático que a recorrente pretendia não existia no mercado em formato standard. Teria de ser desenvolvido, de forma personalizada, à medida da pretensão da recorrente, por forma a juntar ferramentas informáticas já existentes no mercado num único produto, precisamente o programa informático pretendido pela recorrente. 

De modo que a impugnação à decisão de facto deduzida pela apelante deve ser deferida e consequentemente alterada a redacção dos factos provados 7. e 8., nos termos propostos pela mesma, e eliminada a a) dos factos não provados (ficando em letra minúscula e a nova redacção a negrito), como segue:
7. Em 2019, a ré procurou no mercado empresas especializadas na criação e desenvolvimento de “um software à medida” que procedessem à automatização do processo do negócio de transporte de mercadorias no contexto do comércio eletrónico online desde o pedido do cliente até à entrega e envio da fatura – Projeto C....
8. Nessa procura, a ré forneceu às empreses então contactadas – entre elas a autora - informação sobre o modelo de negócio a implementar e bem assim os requisitos tecnológicos/funcionalidades que pretendia que fossem desenvolvidos, sob a denominação C....

2.4. Relativamente à pretendida fusão/modificação/eliminação atinente aos factos provados 17. e 18., verificamos que o ano apontado no facto 17. está errado, bem como a menção às partes, que está trocada, por lapso do tribunal a quo, levando em consideração o que a recorrente alegou nos arts. 25. a 33. da sua oposição, erro e troca que não merecem da recorrida, nas suas contra-alegações, qualquer discordância. Desta sorte, há que fazer a devida correcção (a negrito, ficando a anterior redacção em letra minúscula). Eliminar tal facto como a recorrente pretende é que não se vê motivo justificado para isso. Consequentemente o facto 18. permanecerá como está.

Aquele facto 17. ficará, pois, como segue:

17. A autora, em novembro de 2019, alegou que a ré não tinha facultado à autora toda a documentação necessária sobre as interligações.

3. Na sentença recorrida escreveu-se que:

“Nos presentes autos, a autora peticiona a condenação da ré no pagamento de 6457,50€ a título de responsabilidade civil contratual pelo não cumprimento, por parte da ré, da obrigação de pagamento do preço a que se encontrava adstrita em virtude do contrato de prestação de serviços de desenvolvimento de software celebrado.

Em sede de oposição, a ré invocou a exceção de não cumprimento e de cumprimento defeituoso para justificar o não pagamento da última tranche. Por sua vez, retorquiu a autora que o contrato celebrado consistiu na definição de um período de tempo no decurso do qual a autora disponibilizaria os seus serviços de desenvolvimento de software consoante as necessidades da ré.

Independentemente do nomen iuris que as partes dão aos contratos, na interpretação e na qualificação destes, o que releva na definição do mesmo é a vontade expressa nas respetivas declarações negociais, entendidas estas com o sentido captável pelo declaratário normal, colocado no real circunstancialismo negocial. Assim, o tribunal não se encontra adstrito à qualificação jurídica que as partes atribuem ao acordo entre si celebrado, devendo qualificar o contrato de acordo com a “interpretação da atividade negocial das partes, tendo por elementos de trabalho o texto contratual, as negociações que o antecederam e a vivência da relação negocial estabelecida” (cfr. Acórdão do TRC de 7/2/2006, relator: Cura Mariano, disponível em <http://www.dgsi.pt/jtrc.nsf/c3fb530030ea1c61802568d9005cd5bb/f905e91c7f92fb07802571310053b4ac?OpenDocument>).

Importa, portanto, perceber qual o contrato celebrado entre as partes e quais as obrigações a que se vincularam.

Em primeiro lugar, suscita-se a questão de saber se o acordo celebrado entre as partes consubstancia um contrato de empreitada.

O contrato de empreitada, definido no artigo 1207.º, do CC, implica que uma das partes se obrigue a realizar uma obra, obra essa que se deve materializar numa coisa concreta com utilidade própria para o seu beneficiário e que seja alcançado em conformidade com um projeto (PRATA, Ana, Código Civil anotado, vol. I, p. 1546).

Tem sido amplamente discutida a possibilidade de aplicar o regime do contrato de empreitada a obras intelectuais e incorpóreas como a que se encontra em discussão. O principal argumento contra esta possibilidade centra-se na não transferência típica da propriedade dos direitos de autor ou propriedade intelectual, ficando o empreiteiro com a propriedade dos mesmos. No caso em concreto, apesar de o contrato celebrado entre as partes prever a transferência da propriedade intelectual que tenha sido desenvolvida exclusivamente para a ré, a verdade é que a propriedade intelectual neste caso se encontra abrangida pelo Código de Direitos de Autor e dos Direitos Conexos que prevê como regra supletiva no seu artigo 14.º que o direito de autor pertence ao prestador de serviços, não se podendo falar com total retidão, nestes casos, em contrato de empreitada, mas antes um contrato de prestação de serviços, no qual se poderão aplicar algumas das regras aplicáveis ao contrato de empreitada. Do contrato junto aos autos resulta que a propriedade intelectual antes pertencente à autora se mantém na propriedade daquela, o que afasta a definição do contrato celebrado enquanto contrato de empreitada.

O conceito restrito de obra não permite incluir no âmbito da celebração de um contrato de empreitada criações intelectuais que, apesar do suporte material no qual se encontram exaradas, assumem um carácter incorpóreo, como é o caso do software (MARIANO, João Cura, Responsabilidade Contratual do Empreiteiro pelos Defeitos da Obra, 7.ª edição, Almedina, p. 47).

Neste sentido, afirma Luís Menezes Leitão que, onde se salienta: “A posição que nos parece preferível é a de que a obra intelectual não pode ser objecto de contrato de empreitada, que se restringe às coisa corpóreas, (…). Efectivamente, a noção de obra constante do artigo 1207º do Código Civil, ao contrário do que normalmente acontece nos Códigos Civis estrangeiros, é restringida às coisas corpóreas, dado que o regime de fiscalização (artigo 1209º), da transferência da propriedade (artigo 1212º), das alterações (artigos 1214º e seguintes) e dos defeitos da obra (artigo 1218º e seguintes), é dificilmente compatível com a criação de obras intelectuais, uma vez que nestas tem que ser assegurada uma maior liberdade ao criador e a questão principal prende-se com a atribuição do direito de autor sobre a obra, questão que o regime da empreitada não resolve. Por último, se viesse a abranger as obras intelectuais, o contrato de empreitada passaria a ser uma figura demasiado ampla, esgotando quase completamente o regime da prestação de serviços” (in Direito das Obrigações, vol. III, Almedina, 7.ª edição, p. 518 e ss. No mesmo sentido, vide LIMA, Pires de, VARELA, Antunes, Código Civil Anotado, vol. II, Coimbra Editora, 1986, 3.ª edição, p. 787 e ss.

(…)

Resulta claro da factualidade provada que a autora se vinculou a executar o contrato celebrado de acordo com as regras da arte e regras técnicas com a diligência média de um bom pai de família. As partes estavam vinculadas aos deveres da boa fé e de colaboração, deveres esses que pautaram a relação negocial das partes.

A qualificação jurídica atribuída pelas partes ao contrato celebrado identifica-se com um contrato de prestação de serviços, definido como aquele em que uma das partes se obriga a proporcionar à outra certo resultado do seu trabalho intelectual ou manual, com ou sem retribuição (artigo 1154.º, do CC).

Como modalidades típicas da prestação de serviços prevê-se na lei mandato, o depósito e a empreitada que não esgotam, todavia, as modalidades de prestação de serviços (artigo 1155.º, do CC), como, de resto, esclarece Luís Manuel Teles de Menezes, (in Direito das Obrigações, vol. III, 10ª edição, p. 383) estas três modalidades não esgotam o conteúdo da prestação da prestação de serviços, que constitui uma figura muito ampla. Precisamente por esse motivo, o artigo 1156.º, do CC vem determinar a extensão das disposições sobre o mandato, com as devidas adaptações, aos contratos de prestação de serviços que a lei não regule expressamente. Há assim que reconhecer que o contrato de prestação de serviços é um contrato atípico, que possui três modalidades típicas, as quais estão longe de esgotar o seu campo de aplicação.

Da factualidade julgada como provada resulta que a autora se obrigou a desenvolver software pelo período fixado, em contrapartida da obrigação da ré de pagar o preço. Tal contrato reveste a natureza jurídica de um contrato de prestação de serviços atípico e inominado, sujeito às regras constantes dos artigos 1156.º, do CC, mas a que se poderão eventualmente aplicar por analogia o regime do contrato de empreitada, sempre que tal analogia se justificar.

No âmbito deste contrato, ficou provado que cabia à autora elaborar software aplicacional, no sentido de serem disponibilizadas aplicações à medida das necessidades da ré. Resultou, contudo, igualmente comprovado que a ré não forneceu todas as especificações de negócio necessárias ao desenvolvimento e manutenção da aplicação, tendo apresentado ab initio uma proposta genérica e vaga, que ia sendo concretizada e ajustada com o decurso do tempo. Não existia, deste modo, um produto final especificamente definido aquando da efetuação do convite para contratar, mas tão-só uma ideia genérica das aplicações pretendidas e das funcionalidades que a ré pretendia, sem, contudo, concretizá-las na íntegra e sem que as mesmas fossem todas vinculativas.

No decurso da execução do contrato, atendendo às necessidades específicas da ré e ao resultado de cada reunião de início de sprint, a autora elaborou uma aplicação Android com determinadas características técnicas e qualidades funcionais, cuja utilização cedeu à ré, tendo reservado para si a propriedade desse programa na parte que não fora desenvolvido propositadamente para o sistema aplicacional solicitado pela ré.

Estamos, assim, perante um contrato de desenvolvimento de software «à medida» - Acórdão do TRL 08.09.2015, relatado por Maria do Rosário Morgado, disponível em <http://www.dgsi.pt/jtrl.nsf/33182fc732316039802565fa00497eec/fad21837c6821f2880257ec9002e97da?OpenDocument>.

No nosso ordenamento jurídico, a qualificação jurídica de contratos de desenvolvimento de software é alvo de divergência na doutrina e a jurisprudência, sendo considerado por uns como contrato de empreitada, enquanto outros entendem tratar-se de um contrato inominado de prestação de serviços. Como acima se menciona e fundamenta, o contrato dos autos é de qualificar como contrato de prestação de serviços atípico ou inominado, qualificação jurídica que nem sequer é objeto de controvérsia entre as partes.

Chegados aqui, resta referir, de forma sumária, que a pedra de toque do presente aresto reside no facto de saber se a autora se vinculou a fornecer à ré determinados meios para realizar os seus objetivos, ou se encontrava adstrita a produzir certo resultado.

A doutrina debruçou-se já sobre esta distinção, sendo que alguns Autores distinguem as obrigações de meios como aquelas “que respeitam a prestações destinadas a resultados com carácter aleatório, e de resultado aquelas cujo efeito não apresenta tal característica” (veja-se SILVA, Manuel Gomes da, O dever de prestar e o dever de indemnizar, vol. I, Imprensa FDUL, p. 237). Na obrigação de resultado para além do dever de prestar, existe uma garantia de resultado. Em suma e sem pretensões de exaustão, nas obrigações de meios o devedor compromete-se a desenvolver prudente e diligentemente certa atividade para a obtenção de determinado efeitos, mas sem assegurar que o mesmo se produza, enquanto nas obrigações de resulta o devedor compromete-se a conseguir com a sua atividade um determinado efeito útil (MARIANO, João Cura, Responsabilidade Contratual do Empreiteiro pelos Defeitos da Obra, 7.ª edição, Almedina, p. 44).

Deste modo, e no que tange ao incumprimento, nas obrigações de meios não é suficiente a não verificação do resultado para responsabilizar o devedor, havendo que demonstrar que a sua conduta não correspondeu à diligência a que se tinha vinculado. Cabe ao devedor o ónus de provar de que realizou a prestação (artigo 342.º, n.º 2, do CC) ou de que a falta de cumprimento não procede de culpa sua (artigo 799.º, do CC) a fim de não lhe ser imputada uma obrigação de indemnizar.

Se é verdade que o contrato celebrado entre as partes teve um objetivo muito específico, que consistia na criação de aplicações móveis que permitissem a utilização profissional por parte da ré, sendo tal conhecido da autora, no entanto, a convicção do tribunal é que aquilo a que a ré verdadeiramente se comprometeu foi a desenvolver durante um determinado e acordado período de tempo o software necessário à criação das aplicações pretendidas com as funcionalidades que foram sendo concretizadas, a fim de a autora retirar da criação intelectual da autora toda a sua utilidade.

Importa referir que apesar de constar dos pontos 7 a 9 dos factos provados que a ré instou junto da autora para que esta apresentasse uma proposta de desenvolvimento de software que servisse as pretensões da ré, isto é que permitisse uma plataforma dirigida a consumidores com vista ao transporte de mercadorias, a proposta apresentada pela A... foi ela também vaga e genérica tal como a apresentação constante do documento 2 junto com a oposição. Em momento algum, na fase pré-contratual, por parte da ré, foi indicado especificadamente o produto final que se pretendia. Se é certo que a ré pretendia um produto final funcional, com determinadas funcionalidades, essas funcionalidades e interligações foram definidas ao longo do projeto, no decorrer dos sprints e através da dinâmica usual da criação de software através do modelo scrum. Como a própria testemunha AA terminou por concluir, “o todo não estava definido”, por isso não podia existir, em primeiro lugar, uma proposta da autora concreta com todos os serviços concretos a prestar, nem tão-pouco um produto rígido, definido e detalhado que a autora tivesse que entregar. A ré contratou a autora para prestar os mencionados serviços de desenvolvimento de software consistentes na interligação das funcionalidades já existentes no mercado, que iam sendo definidos entre as partes, necessitando para tal o tempo estipulado.

Neste sentido, diga-se ainda, que as duas aplicações iniciais e a aplicação de gestão discutidas nos autos e referidas pelo representante legal da autora não encontram respaldo nem na apresentação que serviu de suporte à apresentação do que era pretendido pela ré, nem na proposta contratual apresentada pela autora, o que é demonstrativo do que acima se afirma quando ao objeto negocial em causa.

Resultou da prova dos autos que não ficou definido um resultado final operativo específico e concretizável logo ao início, mas sim que durante um período de tempo a autora tudo iria fazer a com vista a conceber uma plataforma informática tendente a obter determinados resultados (que poderiam ser alcançados ou não, como não foram alguns por mútuo acordo das partes).

A prestação que satisfaria o interesse contratual da ré dirigia-se à atividade técnica a desenvolver pela sociedade autora, não tendo sido fixado um resultado final operativo detalhado e concretizado, mas sim uma ideia genérica, pelo que não pode a obrigação da autora deixar de consubstanciar uma obrigação de meios.

In casu, se é verdade que teste após teste, se verificaram invariavelmente falhas bloqueantes na aplicação Android entregue pela autora que impediam que a Ré não era afinal capaz de levar a um sistema informático minimamente idóneo à concretização do fim contratual firmado, não se produzindo o “resultado” almejado pela ré, não podemos deixar de afirmar que o contrato de prestação dos serviços de desenvolvimento de software foi cumprido, porquanto a autora com diligência e ultrapassando até o período contratualmente fixado para a prestação dos serviços.

Conforme refere Antunes Varela: “O cumprimento da obrigação é a realização voluntária da prestação debitória. É a actuação da relação obrigacional, no que toca ao dever de prestar. (...) Na obrigação de resultado, o cumprimento envolve já a produção do efeito a que tende a prestação ou do seu sucedâneo, havendo assim perfeita consciência entre a realização da prestação debitória e a plena satisfação do interesse do credor” (in Código Civil Anotado, Volume II, Almedina 1990, 4.ª edição, p. 7 e ss).

Resultou assim comprovado que a autora cumpriu diligentemente a prestação a que estava adstrita: isto é, não obstante ter resultado comprovado que a aplicação criada pela autora apresentava problemas que a tornavam inapta a ser utilizada pelos clientes da ré, como pretendia a ré, a verdade é que tal não constitui, na ótica do tribunal, incumprimento ou cumprimento defeituoso do contrato, uma vez que a obrigação a que se vinculou a autora foi uma obrigação de meios. Desta forma, cumprida que está a obrigação que vinculava a autora de disponibilizar períodos de tempo (em sprints) para desenvolver software, aplicações e funcionalidades que iam sendo requisitadas, definidas e ajustadas em colaboração entre as partes, resultou igualmente comprovado que a ré não procedeu à sua contraprestação, que consistia no pagamento do preço acordado.

Não colhe, de igual forma, a exceção de não cumprimento do contrato prevista no artigo 428.º, do CC, uma vez que, tratando-se de um contrato sinalagmático verificou-se que a autora cumpriu a sua obrigação, tendo a ré sido interpelada para proceder ao pagamento da última tranche do preço.”.

A recorrente discorda pelas razões constantes das suas conclusões de recurso (as 23. a 33.), enquanto a recorrida pugna pela justeza da posição jurídica expressa na decisão apelada (cfr. conclusões das suas contra-alegações N. a T.).

Á priori, conexionado com o facto provado 2. importava saber se a recorrente não comprou tempo à recorrida, como esta defende, se antes comprou um produto – um programa informático, o qual nunca lhe chegou a ser entregue com os requisitos mínimos para ser lançado ao mercado como aplicação informática, como defende ao invés a recorrente. E se, independentemente da qualificação jurídica a atribuir ao contrato – empreitada ou contrato inominado de prestação de serviços – sempre esteve no propósito das partes a entrega de um produto final. A saber, uma aplicação informática que procedesse à automatização do processo do negócio de transporte de mercadorias no contexto do comércio electrónico online desde o pedido do cliente até à entrega e envio da factura – Projeto C... (facto provado 7.). Perante este último facto era muito duvidoso aceitar a tese da recorrida, de mera compra de tempo, pois se a aplicação informática a criar visava a automatização do processo de negócio de transporte de mercadorias no contexto do comércio electrónico online desde o pedido do cliente até à entrega e envio da factura, o mais crível, obviamente, era que se pretendia alcançar um resultado, não uma mera actividade, pois nas obrigações de resultado o devedor compromete-se a conseguir com a sua atividade um determinado efeito útil, e era justamente esse efeito útil o que a recorrente pretendia.    

Perante os factos agora comprovados – os 2., 2-A. a 2-L., 7., sobretudo este, e 8. -, não temos dúvidas em afirmar que a recorrente visou e contratou com a recorrida um determinado resultado, um produto informático determinado.

No caso, “um software à medida” da pretensão e necessidades da apelante – sobre esta figura pode ver-se Alexandre L. Dias Pereira, Direitos de Autor e Liberdade de Informação, Teses, 2008, págs. 206/211, que refere que em termos de enquadramento jurídico, a licença de software feito à medida obtém-se no quadro de um contrato de encomenda de obra intelectual. E que no direito português, a questão da qualificação jurídica de contratos de software “feito à medida” (ou adaptado) dividiu a doutrina e a jurisprudência, com vários autores a considerarem estarmos perante um contrato de empreitada, enquanto outros entendiam tratar-se de um contrato inominado de prestação de serviços.

Ora, atenta a referida factualidade provada, o contrato dos autos é de qualificar como contrato de prestação de serviços atípico ou inominado, um contrato de desenvolvimento de software «à medida», e não uma empreitada, como a 1ª instância qualificou e bem fundamentou, merecendo, por isso, a nossa adesão.    

Acontece que a apelada não logrou conseguir inteiramente tal desiderato, como decorre dos factos provados 24. a 26., 28. a 37. O que quer dizer que a prestação da A. não foi a devida, na óptica da boa fé, pontualidade e integralidade do cumprimento.

Estamos, pois, perante um cumprimento defeituoso, que se traduz na execução de prestações qualitativas e quantitativas diversas das estipuladas (ou na inobservância de deveres laterais). Trata-se de um cumprimento imperfeito, com vícios materiais ou jurídicos, com prestação de menor qualidade ou quantidade superior ou inferior, imprópria para o fim desejado (vide A. Menezes Cordeiro, Tratado, D. Obrigações, Tomo IV, 2010, págs. 200/201, e J. C. Brandão Proença, Lições de Cumprimento e Não Cumprimento das Obrigações, 1ª Ed., 2011, págs.     354/359).

Perante tal situação, a primeira e mais natural atitude do credor será de recusar a prestação defeituosa e de esperar/reclamar por um cumprimento regular, sustendo, com a excepção do cumprimento defeituoso, o cumprimento da sua contraprestação.

A apelante fez acionar a excepção de não cumprimento do contrato (art. 428º, nº 1, do CC), pois a A. só podia reclamar o pagamento da última prestação (facto 2.g.), após a aceitação final pelo cliente, a R./recorrente. Ora, não está demonstrado nos autos essa aceitação final pela R./recorrente.

A excepção do contrato não cumprido deve ser sempre usada nos limites da boa fé (vide Menezes Cordeiro, ob. cit., pág. 141). E vale tanto para o caso de falta integral do cumprimento, como para o cumprimento parcial ou defeituoso, desde que a sua invocação não contrarie o princípio geral da boa fé (vide A. Varela, CC Anotado, Vol. I, 3ª Ed., nota 3. ao art. 428º, pág. 381). Trata-se de uma excepção material dilatória que invocada com sucesso, como no nosso caso concreto, leva a que o contrato entre numa suspensão de eficácia até que se processe o cumprimento, ou eventualmente, seja resolvido com base na definitividade/impossibilidade do cumprimento. Podendo ser invocada fora da simultaneidade temporal, pelo contraente que deva cumprir em segundo lugar, como no nosso caso, por ex: o serviço deve estar concluído antes do seu pagamento. E pressupondo a sua invocação a existência de um incumprimento minimamente grave, mas não ínfimo ou insignificante. E nos cumprimentos parciais ou defeituosos a ser invocada proporcionalmente à quantidade/qualidade do incumprimento (vide J. C. Brandão Proença, ob. cit., págs. 143/151).

Concluindo. Na nossa situação, perante a factualidade apurada, o recorrente invocou a exceptio nos limites da boa fé, num caso de cumprimento defeituoso, como contraente que devia cumprir em segundo lugar, perante a existência de um incumprimento da recorrida não ínfimo ou insignificante que invoca proporcionalmente face à qualidade do incumprimento, podendo, por isso, recusar a última parcela do pagamento, correspondente a 10% do preço (a recorrida recorda na sua conclusão de recurso R o Ac. desta Rel. de 21.2.2018, mas o mesmo incide sobre um contrato de empreitada e o seu regime jurídico concreto diversamente da situação em apreço nos autos incidente sobre um contrato de prestação de serviços).

Procede, pois, a apelação.

(…)

IV - Decisão

Pelo exposto, julga-se o recurso procedente, assim se revogando a sentença recorrida e, consequentemente, se absolvendo a R./recorrente.

*

Custas pela A./recorrida.

*

                                                                            Coimbra, 10.9.2024

                                                                            Moreira do Carmo

                                                                            Fonte Ramos

                                                                            Fernando Monteiro