Spec-Driven Development | a especificação orienta cada passo

Software no prazo e no orçamento com que nos comprometemos.

Descreve o que precisa por palavras suas. Nós transformamos isso numa especificação que lê e aprova, e numa estimativa de prazo e orçamento que cumprimos. Até a um sistema a funcionar em produção.

A estimativa vinculativa chega depois de uma fase de especificação, não depois de uma conversa. Quem lhe dá um número ao fim de uma hora está a adivinhar.

Conversa Fala. Nós gravamos. Especificação Duas versões. Livro de regras. Aprovação + estimativa Aprova. Comprometemo-nos. Desenvolver e testar Agentes de IA, supervisionados. Revisão Staging. Correções. Produção Alojamento. Manutenção. Docs vivos.
Azul: a IA executaVerde: uma pessoa decide

Comprometemo-nos com prazo e orçamento

Uma especificação que aprova, uma estimativa que cumprimos e um sistema que entra em produção. Uma só equipa para a especificação, o desenvolvimento e a manutenção.

  • Estimativa vinculativa depois da especificação, não depois de uma conversa
  • Cada alteração passa pela especificação antes de qualquer código

O livro de regras de desenvolvimento

Centenas de regras acumuladas ao longo de décadas, em capítulos como segurança, desempenho e experiência de utilização. Cada requisito que escrevemos é verificado contra elas.

  • A especificação inclui o que não sabia que devia pedir
  • Duas versões: uma para si, outra para programadores

Software houses desde 1989

Sócios que dirigem software houses desde 1989, com presença em Portugal desde 2023. Produtos nossos funcionam em clientes há anos.

  • Certificação ISO 27001, trabalho segundo o OWASP Top 10
  • Programadores experientes respondem por cada linha de código

Alguns dos nossos clientes

  • Drive Group
  • IKEA
  • Israel Police Funds
  • Rafa Laboratories
  • Daniel Group
  • Margoa Residences
  • Mor Institute
  • Israel Sports Betting Board
  • Student-Room-Flat
  • Hold-Me
Os nossos serviços

Uma base. Quatro serviços.

Em cada um recebe uma especificação que aprova, uma estimativa que cumprimos e código que se mantém documentado.

Para organizações

Software para organizações

Um sistema novo, a substituição de um sistema antigo ou IA dentro de um produto que já usa.

O software não é o seu negócio, mas o sistema é. Construímo-lo documentado, legível e mantido, para que nunca dependa de uma pessoa ou de um fornecedor. Segurança por omissão: ISO 27001, OWASP Top 10, servidores reforçados.

  • Sistemas novos
  • Substituição de sistemas antigos
  • Integração de IA
Para fundadores

Do protótipo à produção

De uma ideia, ou de um protótipo que encravou, a um produto com que pode angariar investimento.

Dizemos-lhe o que construir agora, o que adiar e quanto vai custar, antes de gastar um cêntimo. Construiu no Lovable ou no Bolt e bateu numa parede? Levamos o produto para produção, com segurança e código que qualquer equipa consegue continuar.

  • Proof of Concept
  • MVP
  • Prototype to Production
Para empresas com equipa de desenvolvimento interna

Modernização da equipa de desenvolvimento

Consultoria e implementação prática de desenvolvimento assistido por IA na equipa que já tem.

Comprou as licenças e viu os programadores voltarem à forma antiga de trabalhar? Instalamos no seu repositório o que corre o nosso próprio desenvolvimento, o kit de ferramentas, as Skills e o livro de regras, e trabalhamos com a equipa até isso se tornar a forma de trabalhar. Programa de primeiros parceiros, vagas limitadas.

  • Agentic Engineering
  • Spec-Driven Development
  • Acompanhamento da equipa
Para empresários

Automação de processos

Ligações entre os seus sistemas, construídas como software.

Automação que não falha em silêncio: especificação, tratamento de erros, monitorização e propriedade total das contas e dos processos. n8n, Make ou Zapier, consoante o que fizer sentido, e código onde a ferramenta não chega.

  • Integração de sistemas
  • Monitorização e alertas
  • Propriedade total
Como funciona

Três passos. Em cada um sabe exatamente o que recebe.

1
Gratuito

Conversa

Uma hora. Fala, nós perguntamos e gravamos. No fim recebe o que percebemos, as perguntas que vão definir o âmbito e um preço fixo para a fase de especificação.

2
Preço fixo

Especificação

As gravações das reuniões tornam-se uma especificação em duas versões: uma que lê e aprova, e outra para programadores, que inclui o que não sabia que devia pedir. No fim: uma estimativa vinculativa de prazo e orçamento.

A especificação é sua, mesmo que decida não continuar connosco.

3
No orçamento e no prazo que aprovou

Desenvolvimento e entrega

Agentes de IA escrevem e testam o código. Programadores experientes supervisionam e respondem por cada linha. A especificação e o código mantêm-se atualizados e documentados até à entrega, e depois dela.

No DocsRobot, o nosso produto, um sistema de IA testa o produto todas as noites, em hebraico e em inglês, e abre os seus próprios relatórios de erros.

Porque é que a especificação é paga? Porque é a parte em que trabalhamos para si, não em que lhe vendemos. O nosso compromisso aplica-se à especificação que aprovou. Quer mudar algo a meio? A alteração passa pela mesma especificação, e vê o efeito no prazo e no orçamento antes de a aprovar, não depois.
O livro de regras de desenvolvimento

A sua especificação inclui o que não sabia que devia pedir.

Cada requisito que escrevemos é verificado contra o nosso livro de regras de desenvolvimento: centenas de regras acumuladas ao longo de décadas, em capítulos como segurança, desempenho e experiência de utilização. Uma regra relevante que não é óbvia entra na versão da especificação para programadores. Nenhum cliente as pediu à partida. Estão todas em cada sistema que construímos.

Como testar algo que acontece uma vez por mês sem esperar um mês?

O que ganha: faturação mensal, um relatório semanal, um lembrete anual. Tudo totalmente testado antes do lançamento, não depois de passar o primeiro mês.

A regra: qualquer sistema com processos diários, semanais, mensais ou anuais corre num relógio de simulação que controlamos, não no relógio do servidor. Nos testes avançamos o relógio e vemos o que acontece. Sem isso não há testes de aceitação completos para um processo periódico, só espera e esperança.

Um duplo clique nunca cobra duas vezes.

O que ganha: sem clientes cobrados duas vezes, sem registos duplicados, sem chamadas de “como é que isto aconteceu?” para o apoio ao cliente.

A regra: cada operação com efeitos secundários (criar um registo, cobrar, enviar um email, pedir uma assinatura) recebe uma Idempotency-Key. O servidor reserva a chave de forma atómica, guarda o hash do pedido com a resposta final e devolve essa mesma resposta em cada repetição. Mesma chave com outro conteúdo: 409. Redes e clientes repetem pedidos; isso não é uma avaria, é a realidade. Com esta regra, uma repetição deixa de ser fonte de erros e passa a ser um mecanismo de segurança.

Os dados de um cliente não podem chegar a outro cliente. Por construção.

O que ganha: isolamento ao nível da arquitetura, com um teste automático que corre em cada build. Um mecanismo, não uma promessa.

A regra: num sistema multi-cliente a identidade do tenant vem apenas do token autenticado, nunca de um identificador enviado no body, num cabeçalho ou no URL. A filtragem é aplicada num único ponto central, por isso um filtro em falta é estruturalmente impossível. Testes automáticos com dois tenants confirmam que A não vê B através de nenhum endpoint. Não confiamos na disciplina; construímos de forma a que o erro não possa acontecer.

Mais regras de exemplo, e como entram na especificação

Um compromisso que cumprimos

Dois meses, o orçamento que indicámos, e um sistema que entrou em produção.

Quando o fornecedor SaaS de que dependíamos ameaçou desligar o nosso sistema, tínhamos cerca de dois meses para o substituir por um nosso. A Assembly ouviu o que precisávamos, voltou com um âmbito claro, uma data de entrega e um orçamento, e entregou exatamente isso, na data e no orçamento que indicou.

Essa versão entrou em produção e tornou-se a base do nosso negócio digital. Desde então a Assembly tem sido, na prática, a nossa equipa de tecnologia interna, sem surpresas no planeamento financeiro. Se precisa de um parceiro que lhe diga o que é possível, quando e por quanto, e depois o faça, recomendo a Assembly sem hesitar.

Cyril, Managing Partner, Student-Room-Flat
Também no nosso produto. No DocsRobot, o gerador de documentos e sistema de assinaturas que desenvolvemos e vendemos, cada novo módulo foi desenvolvido dentro do orçamento definido para ele à partida.
E os projetos que não vingaram? Vimos muitos de perto. A maioria não falhou por causa do código; o dinheiro acabou antes de o produto estar pronto. Por isso cada projeto de um fundador começa connosco por decidir o que ainda não construir.
O que dizem os clientes

Quem trabalhou connosco, sobre o que lhe importou.

Apesar de ter trabalhado diretamente com programadores na Índia durante muitos anos, escolhi passar o desenvolvimento para a Assembly. O serviço é outra experiência: alguém que percebe mesmo o que precisa e não foge a perguntas diretas, e uma empresa que se sente responsável pelo que entrega. Se sabe o que quer e precisa de um multiplicador de força profissional, fale com a Assembly.

Mani, CEO e proprietário, Hold-Me
Perguntas que ouvimos

Antes de nos contactar

Porque é que a fase de especificação é paga, e não faz parte do orçamento?
Porque uma boa especificação dá trabalho: reuniões gravadas, análise, redação em duas versões e verificação contra o livro de regras. O último sistema que especificámos levou cerca de trinta horas de reuniões. Um fornecedor que lhe dá um número vinculativo depois de uma conversa está a adivinhar, e essa adivinha paga-se mais tarde. A especificação fica sua em qualquer caso.
O que acontece quando mudamos um requisito a meio do desenvolvimento?
A alteração passa pela especificação. Vê o que faz ao prazo e ao orçamento, e aprova ou não, antes de alguém escrever código. O nosso compromisso aplica-se à especificação que aprovou, e por isso continua real mesmo depois de dez alterações.
A especificação é minha se não continuar convosco para o desenvolvimento?
Sim. A especificação e a estimativa. Pode levá-las a qualquer outro fornecedor.
Onde estão os programadores, e quem é responsável?
Programadores experientes supervisionam os agentes de IA e respondem por cada entrega. A responsabilidade pelo projeto é nossa, e do seu lado tem sempre uma pessoa da nossa gestão.
O que é que a IA faz na prática, e o que não faz?
Transforma gravações de conversas numa especificação, prepara instruções técnicas, escreve código e testes, corre os testes e abre relatórios de erros. Não decide o que construir, não aprova a arquitetura e não entrega ao cliente. Em cada um desses pontos há uma pessoa, e sabe quem é.
E a segurança?
Temos certificação ISO 27001. Trabalhamos segundo o OWASP Top 10, reforçamos os servidores dos clientes segundo as normas aplicáveis e, em projetos grandes, corremos testes de intrusão automáticos. Parte do livro de regras trata de segurança, por isso ela está na especificação e não é acrescentada no fim.
O primeiro passo

Uma hora. Sem compromisso.

No fim saberá o que percebemos, que perguntas estão em aberto e quanto custará a especificação. Se acharmos que não vale a pena construir, também o dizemos.

Respondemos num dia útil. Uma hora, sem custo, sem compromisso. Os seus dados servem apenas para lhe responder, conforme a nossa política de privacidade.

Ou diretamente: info [at] assemblyso.com