Criação de Sites
Desenvolvimento web e sites em código próprio
A escolha entre montar um site num construtor e escrever o site em código raramente é sobre qualidade. É sobre quem vai depender de quem, e por quanto tempo.
Falar com um especialistaO que é desenvolvimento web sob medida?
Desenvolvimento web sob medida é construir o site escrevendo o código, em vez de montá-lo dentro de uma plataforma que já traz tudo pronto. Na prática, cada elemento existe porque alguém decidiu que ele deveria existir, e o site carrega apenas o que usa. A diferença aparece menos no dia da entrega e mais depois: em quem consegue manter, no que acontece se você trocar de fornecedor, e em quanto custa a terceira mudança. Vale marcar o que isso não significa aqui: não é desenvolvimento de sistema, painel administrativo ou área restrita, que são outro tipo de projeto e não fazem parte do que entregamos.
- O que é
- Site escrito em código, não montado em construtor
- O que não é
- Sistema, painel ou área restrita, que são outro projeto
- A pergunta que decide
- Quem vai manter o site depois de pronto
- Quando não vale
- Quando a equipe precisa mexer em tudo sozinha
A diferença entre um site montado e um site escrito
Os dois caminhos entregam um site no ar, com endereço próprio, que abre no celular e aparece no Google. A diferença não está no resultado visível, e é por isso que ela quase nunca aparece na hora de decidir.
Um site montado parte de uma base que já existe. A plataforma traz o tema, os blocos, os recursos e o painel de edição, e o trabalho é escolher, encaixar e personalizar dentro do que ela permite. É rápido, é acessível e resolve muito bem uma quantidade enorme de casos.
Um site escrito parte do zero. Não há tema, não há bloco pronto, não há recurso embutido esperando ser ativado. Cada coisa que existe na página está ali porque foi escrita, e nada além disso é carregado. Demora mais para o primeiro resultado aparecer e devolve controle total sobre o que o site faz.
A consequência prática mais importante é sobre dependência. No caminho montado, você depende da plataforma: das regras dela, do preço dela, dos recursos que ela decide manter ou descontinuar. No caminho escrito, você depende de quem sabe mexer em código, que pode ser a gente, pode ser outro fornecedor, pode ser alguém do seu time. São dependências de natureza diferente, e nenhuma das duas é ausência de dependência.
- Montado: rápido, acessível, limitado ao que a plataforma permite
- Escrito: mais lento no início, sem limite de estrutura, sem peso extra
- A diferença aparece depois da entrega, não no dia dela
- Os dois criam dependência, de tipos diferentes
Construtor ou código: o que cada um resolve melhor
Vale comparar com honestidade, porque a discussão costuma ser feita por quem tem interesse em um dos lados. Construtor visual não é solução ruim, é solução com um perfil de uso claro, e boa parte dos sites do mundo está muito bem servida por ele.
O critério que mais separa os dois não é qualidade nem preço inicial. É a frequência com que o site precisa mudar e quem precisa fazer essa mudança. Site que muda toda semana pelas mãos de alguém não técnico pede construtor. Site que muda pouco, ou que muda por quem sabe mexer em código, aproveita melhor o caminho escrito.
O segundo critério é o quanto o projeto precisa fugir do padrão. Enquanto o que você quer cabe no que a plataforma oferece, ela entrega mais rápido e mais barato. Quando começa a exigir contorno, extensão e remendo para conseguir algo específico, o custo se inverte, e o que parecia econômico vira caro e frágil.
Construtor visual e código próprio lado a lado
Comparação por critério, sem torcida. A escolha certa depende de qual linha pesa mais no seu caso.
| Critério | Construtor visual | Código próprio |
|---|---|---|
| Tempo até o primeiro site no ar | Curto, boa parte já vem pronta | Maior, tudo é construído |
| Quem consegue editar | Qualquer pessoa treinada, pelo painel | Depende do que for combinado na entrega |
| Peso da página | Carrega recursos que o site não usa | Carrega apenas o que existe na página |
| Limite de estrutura | O que a plataforma permite | Nenhum, mas tudo custa tempo de escrita |
| Manutenção | Atualizar plataforma e extensões periodicamente | Pouca rotina, mais atenção em mudança grande |
| Custo ao longo do tempo | Mensalidade e extensões, previsível e contínuo | Concentrado no início, menor depois |
| Se você trocar de fornecedor | Fica preso à plataforma escolhida | O código é seu e vai junto |
Não existe linha vencedora universal. Um site institucional que muda três vezes por ano e um blog atualizado toda semana por um estagiário pedem decisões opostas.
Quem vai manter o site depois decide a tecnologia
Esta é a pergunta que deveria abrir todo projeto e quase nunca é feita antes de a decisão já estar tomada. A resposta dela determina mais o resultado de longo prazo do que qualquer discussão sobre linguagem ou plataforma.
Se alguém do seu time vai atualizar textos, trocar fotos e publicar novidades toda semana, o projeto precisa ser desenhado para isso desde o começo. Entregar um site em código para uma equipe sem ninguém técnico, sem nenhuma área editável, cria uma dependência ruim: cada vírgula vira chamado para o fornecedor, e o site congela porque mexer dá trabalho.
Se o site muda pouco, o quadro se inverte. Institucional que recebe ajuste algumas vezes por ano não justifica pagar mensalidade de plataforma nem carregar o peso de um painel completo que ninguém abre. Ali o caminho escrito é mais leve, mais barato no acumulado e mais estável.
Existe meio termo, e é onde a maioria dos projetos deveria estar. Site em código com as áreas que de fato mudam deixadas editáveis, e o resto fixo. Isso exige decidir antes o que vai mudar, e é uma conversa que evita tanto o site engessado quanto o painel gigante sem uso.
Por isso essa pergunta entra no nosso diagnóstico antes de qualquer proposta. Vender a mesma solução para quem publica toda semana e para quem publica uma vez por ano seria mais fácil e resolveria pior para os dois.
O que acontece se você trocar de fornecedor
Ninguém pensa nisso ao contratar, e é o cenário que mais custa caro quando acontece. Vale considerar antes, porque a decisão técnica define quanto essa troca vai doer.
Site escrito em código é um conjunto de arquivos. Se eles estão com você, num repositório em seu nome, qualquer desenvolvedor competente consegue abrir, entender e continuar. Pode demorar um pouco para se ambientar, e é uma continuação, não um recomeço. O que foi construído continua valendo.
Site montado em plataforma vive dentro dela. Sair significa, na prática, refazer: a estrutura, os blocos e as configurações não existem fora daquele ambiente. Costuma ser possível exportar conteúdo em texto, e é bem diferente de levar o site. Isso não é defeito escondido, é como a ferramenta funciona, e vale saber antes em vez de descobrir na hora da briga.
Existe um terceiro cenário, pior que os dois, que é o site em código que ninguém entende. Código sem organização, sem padrão e sem documentação prende tanto quanto plataforma, com o agravante de não ter suporte para ligar. É por isso que escrever de forma previsível não é preciosismo técnico, é o que garante que outra pessoa consiga assumir.
A pergunta prática para fazer a qualquer fornecedor, inclusive a nós, é direta: se eu quiser sair daqui um ano, o que exatamente eu levo comigo? A resposta diz muito.
- Código em repositório no seu nome viaja com você
- Site de plataforma raramente sai de dentro dela
- Código desorganizado prende tanto quanto plataforma
- Pergunte antes de contratar o que você leva se sair
Segurança e atualização exigem coisas diferentes
Aqui os dois caminhos divergem de verdade, e a diferença é de natureza, não de grau.
Um site montado em plataforma popular tem muita coisa rodando: a base, o tema e as extensões instaladas, cada uma escrita por alguém diferente, cada uma com seu ciclo de atualização. Isso amplia a superfície exposta e cria rotina obrigatória. Extensão desatualizada é uma das causas mais comuns de site invadido, e o problema não é a plataforma em si, é o abandono. Site montado e deixado sem atualizar por dois anos é convite.
Um site escrito carrega bem menos peças. Quando é publicado como conteúdo estático, o que existe no ar são arquivos servidos, sem área administrativa exposta nem banco de dados para atacar. Isso reduz muito a superfície, e não elimina responsabilidade: certificado precisa continuar válido, o domínio precisa continuar renovado, e as bibliotecas usadas precisam ser revisadas em mudanças maiores.
A diferença prática está no tipo de atenção. Um pede rotina frequente e disciplinada. O outro pede pouca rotina e cuidado concentrado nos momentos de mudança. Nenhum dos dois sobrevive a abandono total, e é honesto dizer isso.
O sintoma de negligência, em qualquer um dos caminhos, costuma ser silencioso. Certificado vencido, formulário que parou de enviar e página que deixou de abrir não geram aviso, geram ausência de contato, que é facilmente confundida com falta de demanda.
Acessibilidade não é item opcional
É o assunto menos discutido em orçamento de site e um dos que mais separa trabalho bem feito de trabalho apressado. Vale tratar aqui porque é decisão de construção, não de acabamento.
Acessibilidade é fazer o site funcionar para quem navega de formas diferentes da esperada: usando leitor de tela, navegando só pelo teclado, com baixa visão, com dificuldade motora, ou simplesmente com a tela no sol e sem paciência. Não é um público pequeno nem distante, e boa parte das barreiras é criada sem ninguém perceber.
As falhas mais comuns são banais de evitar e caras de corrigir depois. Imagem sem descrição, que deixa a informação invisível para quem usa leitor de tela. Contraste insuficiente, que torna o texto ilegível para muita gente e no sol para todo mundo. Formulário com campo sem rótulo associado, que impede saber o que preencher. Elemento que só funciona com mouse, que exclui quem navega pelo teclado. Ordem de leitura embaralhada, que faz o conteúdo chegar fora de sequência.
A parte que interessa a quem decide: quase tudo isso se resolve construindo direito desde o começo, com custo próximo de zero. Fica caro quando é remendado no fim, ou quando o site foi montado sobre uma base que não permite corrigir. E há um efeito colateral bem-vindo: site acessível costuma ser mais fácil de o buscador entender, porque as duas coisas dependem de estrutura semântica clara.
Não vendemos isso como serviço separado nem entregamos laudo de conformidade. Tratamos como parte de construir bem, no mesmo lugar em que tratamos estrutura de títulos e endereços.
- Descrição em imagem que carrega informação
- Contraste suficiente para ler no sol e com baixa visão
- Campo de formulário com rótulo associado de verdade
- Tudo alcançável pelo teclado, não só pelo mouse
- Estrutura semântica, que ajuda leitor de tela e buscador ao mesmo tempo
Assumir um site que outra pessoa escreveu
Aceitamos esse tipo de projeto, e a resposta honesta é que depende do que existe. Vale explicar o critério, porque é a mesma avaliação que qualquer fornecedor sério faz e quase ninguém explica.
O que olhamos primeiro não é a qualidade estética, é se dá para trabalhar. Código organizado de forma previsível, dependências identificáveis, ambiente que sobe sem adivinhação e histórico de alterações disponível fazem um site alheio ser perfeitamente assumível, mesmo que ele não tenha sido escrito do jeito que escreveríamos.
O que costuma inviabilizar é outra coisa: ausência de acesso ao código, dependência de uma versão antiga que não recebe mais correção, integrações escritas sem documentação, ou uma base tão personalizada que qualquer atualização quebra alguma coisa. Nesses casos, cada mudança pequena vira investigação, e o custo de manter supera o de refazer em poucos meses.
Também é comum encontrar o cenário intermediário, em que parte serve e parte não. Aí a recomendação costuma ser preservar o que já funciona, principalmente estrutura de endereços e conteúdo que já aparece na busca, e reconstruir só o que trava. Refazer tudo por impulso joga fora posicionamento que levou tempo para existir.
Fazemos essa avaliação antes de orçar, e quando a conclusão é que não vale assumir, dizemos isso com o motivo. É mais barato para os dois lados descobrir agora do que no terceiro mês.
O que torna um site alheio viável ou inviável de assumir
| O que avaliamos | Sinal de que dá para assumir | Sinal de alerta |
|---|---|---|
| Acesso ao código | Repositório disponível, com histórico | Só existe o que está publicado no servidor |
| Organização | Padrão reconhecível, mesmo que diferente do nosso | Cada parte escrita de um jeito, sem critério |
| Dependências | Identificáveis e ainda mantidas | Versões antigas sem correção disponível |
| Ambiente | Sobe local sem adivinhação | Só funciona na máquina de quem fez |
| Personalização da base | Ajustes localizados e documentados | Base alterada por dentro, e atualizar quebra |
| Documentação | Existe o mínimo para entender as decisões | Nada escrito, e quem fez não está disponível |
Nenhum sinal de alerta isolado condena o projeto. A soma de três ou quatro costuma indicar que reconstruir sai mais barato que manter.
O custo aparece na terceira mudança
Comparar propostas pelo valor inicial é o erro mais comum, e ele acontece porque o custo de um site não termina na entrega.
No começo, o caminho montado quase sempre sai mais barato, e com folga. Ele parte de algo pronto e a primeira versão aparece rápido. Se o site vai ficar praticamente como nasceu, essa economia é real e permanece.
A conta muda quando começam as mudanças. A primeira costuma ser simples nos dois caminhos. A segunda também. A terceira é onde a diferença aparece: no caminho montado, alterações que fogem do previsto exigem contorno, extensão nova ou ajuste que briga com a base, e cada camada dessas encarece a próxima. No caminho escrito, mudar é escrever de novo, com o mesmo custo por hora de sempre.
Some a isso o custo recorrente. Mensalidade de plataforma, extensão paga e hospedagem específica são valores pequenos que não somem nunca. Ao longo de alguns anos, esse acumulado costuma ultrapassar a diferença do investimento inicial, sem que ninguém tenha feito a conta.
Nada disso significa que código sai mais barato sempre. Significa que a comparação honesta precisa considerar um horizonte de anos e a quantidade esperada de mudanças, e não apenas o número que está na proposta.
O que perguntar antes de contratar um desenvolvedor
Estas perguntas funcionam com qualquer fornecedor, inclusive conosco, e o valor delas está menos na resposta e mais em como ela é dada. Fornecedor que se irrita com pergunta técnica costuma ser o que menos entrega.
Comece pela propriedade. O que exatamente fica comigo ao final, e onde. Se a resposta for vaga, ou se o código ficar em conta do fornecedor, isso é uma decisão sendo tomada por você sem você.
Depois pergunte pela continuidade. Se eu precisar de outra pessoa daqui a um ano, o que ela vai encontrar. A resposta ideal descreve organização e documentação, não promete que você nunca vai precisar de outra pessoa.
Pergunte também o que você consegue editar sozinho e o que vai depender de chamado. Essa é a pergunta que mais gera arrependimento depois, quando o cliente descobre que trocar uma foto exige abrir ticket.
E pergunte pelo que não está incluso. Manutenção, correção depois da entrega, hospedagem, e o que acontece quando algo quebrar em seis meses. Escopo bem definido protege os dois lados, e fornecedor que evita esse assunto está adiando um conflito.
- O que fica comigo ao final, e em nome de quem
- O que outro desenvolvedor vai encontrar daqui a um ano
- O que eu edito sozinho e o que depende de chamado
- O que não está incluso, e o que acontece se quebrar
Quando código próprio não é o caminho
Vale dizer, porque é a parte que quem vende código costuma omitir.
Se a sua equipe precisa mexer em tudo, com frequência e sem depender de ninguém, construtor visual resolve melhor. Publicar toda semana, criar página nova por conta, alterar estrutura no impulso: nada disso combina com um site que exige alguém técnico para cada ajuste. Insistir em código nesse cenário produz um site que congela.
Se o projeto é loja virtual, a conversa é outra. Catálogo, carrinho, pagamento, estoque e frete formam um problema resolvido de forma madura pelas plataformas de e-commerce, e reconstruir isso do zero raramente compensa. É um pilar separado justamente por isso.
Se o orçamento é apertado e o objetivo é validar uma ideia rápido, começar montado é decisão sensata. Vale gastar pouco para descobrir se existe demanda, e reconstruir depois com informação real, em vez de investir num projeto sob medida para algo que ainda não se provou.
E se o site precisa de funcionalidade de sistema, como área restrita, painel administrativo ou integração contínua com outro software, esse não é o nosso escopo. Dizemos isso antes de orçar e indicamos o caminho, mesmo quando ele passa por outro fornecedor. É a mesma posição que sustentamos na página de site para empresas.
O que fica com você no fim do projeto
Vale detalhar a entrega técnica, que é diferente da questão de domínio e hospedagem estarem no seu nome. Isso é premissa e não se discute. O que se discute aqui é o que você recebe do trabalho em si.
Fica o código, num repositório em seu nome, com o histórico de alterações. Não é formalidade: é o que permite que outra pessoa continue de onde paramos, e é a diferença entre ter um ativo e ter um serviço que precisa ser recontratado.
Fica o acesso a tudo que o site usa para funcionar, com as contas em nome da sua empresa. Nada de recurso essencial pendurado em conta pessoal de quem construiu, que é uma das origens mais comuns de site perdido.
Fica o mínimo de documentação para o site não virar caixa-preta: como subir uma alteração, onde ficam as partes editáveis, quais decisões foram tomadas e por quê. Não é manual extenso, é o suficiente para alguém competente se ambientar sem precisar ligar para nós.
E fica combinado o que acontece depois. O que está coberto, por quanto tempo, e como funciona quando surgir algo novo. Silêncio nesse ponto é o que gera atrito lá na frente.
- Código em repositório no seu nome, com histórico
- Acessos e contas em nome da empresa, nunca pessoais
- Documentação mínima para outra pessoa assumir
- Escopo do que vem depois, combinado por escrito
Como a Axcali conduz um projeto de desenvolvimento
A primeira conversa não é sobre tecnologia. É sobre com que frequência o site vai mudar e quem vai mexer nele.
Entender o ciclo de vida do site
Levantamos com que frequência o conteúdo muda e quem faz essa mudança. É o que determina a tecnologia e o que precisa ficar editável, e decidir isso depois custa caro.
Escolher a stack pelo projeto
Definimos a abordagem a partir de orçamento, prazo e de quem mantém, e não por preferência. Quando construtor resolve melhor, dizemos, mesmo que o projeto fique menor.
Estrutura e endereços antes do código
Fechamos a arquitetura de páginas e URLs antes de escrever. É a decisão mais cara de reverter, principalmente quando já existe posicionamento a preservar.
Construir com estrutura semântica
Escrevemos com marcação correta e navegação por teclado desde o início, o que atende acessibilidade e ajuda o buscador ao mesmo tempo. Feito assim, custa quase nada; remendado depois, custa caro.
Conferir em aparelho e em conexão real
Testamos em celular de verdade, em mais de um sistema, e com conexão limitada. Comportamento de teclado, rolagem e elemento fixo não aparece redimensionando a janela.
Medição no ar antes de publicar
Deixamos clique no WhatsApp, no telefone e envio de formulário registrados como evento. Site publicado sem isso não permite dizer, meses depois, se trouxe alguém.
Entrega com código, acesso e documentação
Repositório em seu nome, contas em nome da empresa e o mínimo escrito para outra pessoa assumir. Combinamos também o que fica coberto depois da entrega.
Sites que cresceram sem precisar ser refeitos
Nos três a estrutura foi pensada para receber páginas novas ao longo do tempo: uma por empreendimento na DV Imob, uma por especialidade na UniDuniTEA, e a Digital Aquecedores que começou por uma página de conversão e cresceu em páginas por serviço e por marca. Aparecem sem número porque desempenho de tráfego não prova decisão técnica.
Contratar desenvolvimento web em São Paulo
São Paulo concentra a maior oferta de desenvolvimento do país, e isso é uma vantagem com uma armadilha junto. Existe fornecedor para todo orçamento, e a diferença entre propostas com valores muito distantes quase nunca está explicada no documento.
A dispersão de preço costuma refletir escopo, não qualidade. Um valor mede montar sobre uma base pronta, outro mede escrever do zero, e um terceiro mede alguém que vai desaparecer depois da entrega. Comparar sem alinhar o que está incluído é como comparar aluguel sem olhar a metragem.
Trabalho remoto virou padrão na área, e isso é bom para você. A escolha deixou de ser limitada a quem está perto, e passou a depender de organização e de comunicação. O que continua valendo o encontro presencial é a fase de definição, quando decidir o que o site precisa fazer rende mais numa conversa cara a cara.
A Axcali fica em São Paulo, atende empresas da capital e da região metropolitana, e trabalha de forma remota com clientes de todo o Brasil.
- São Paulo capital
- Zona Sul
- Zona Oeste
- Pinheiros
- Vila Mariana
- Itaim Bibi
- Brooklin
- Grande ABC
- Região metropolitana
Perguntas frequentes
O que mais perguntam sobre desenvolvimento de sites em código próprio.
Qual a diferença entre site em código próprio e site de plataforma?
Um é escrito, o outro é montado. No de plataforma, a base, o tema e os recursos já existem e o trabalho é encaixar dentro do que ela permite, o que é rápido e resolve muito bem uma quantidade enorme de casos. No de código, nada existe até ser escrito, o que demora mais no início e devolve controle total sobre estrutura e peso. A diferença aparece depois da entrega, em quem consegue manter e no que acontece se você trocar de fornecedor.
Consigo editar o site sozinho se ele for em código?
Depende inteiramente do que for combinado antes. Dá para deixar áreas editáveis, e é o que fazemos quando existe conteúdo que muda com frequência. O que não funciona é entregar um site totalmente fixo para uma equipe que precisa publicar toda semana: cada ajuste vira chamado e o site congela. Por isso perguntamos no começo com que frequência as coisas mudam e quem vai mexer, antes de decidir a tecnologia.
O que acontece se eu quiser trocar de fornecedor?
Se o site é em código e o repositório está em seu nome, você leva os arquivos e qualquer desenvolvedor competente continua de onde paramos. Leva algum tempo de ambientação e é continuação, não recomeço. Site de plataforma raramente sai de dentro dela: costuma ser possível exportar o conteúdo em texto, o que é diferente de levar o site. Vale fazer essa pergunta a qualquer fornecedor antes de assinar.
Vocês assumem um site que outra pessoa desenvolveu?
Sim, avaliando a base antes. O que importa não é se foi escrito do nosso jeito, é se dá para trabalhar: acesso ao código com histórico, organização previsível, dependências ainda mantidas e ambiente que sobe sem adivinhação. O que costuma inviabilizar é base muito personalizada por dentro, versão antiga sem correção disponível ou ausência de acesso ao código. Fazemos essa avaliação antes de orçar e dizemos o motivo quando não vale.
Site em código próprio é mais caro?
No investimento inicial, quase sempre é, e com folga. No acumulado de alguns anos, costuma não ser. O caminho montado tem mensalidade de plataforma e extensões que não somem nunca, e alterações que fogem do previsto ficam progressivamente mais caras porque exigem contorno. O caminho escrito concentra o custo no começo e cobra o mesmo por hora depois. A comparação honesta considera anos e quantidade de mudanças, não só o número da proposta.
Site em código precisa de manutenção?
Precisa, de um tipo diferente. Site de plataforma pede rotina frequente de atualizar base e extensões, e extensão desatualizada é uma das causas mais comuns de invasão. Site escrito, principalmente quando publicado como conteúdo estático, tem bem menos peças expostas e pede pouca rotina, com atenção concentrada nas mudanças maiores. O que os dois têm em comum é que nenhum sobrevive a abandono: certificado vence e formulário para de enviar em silêncio.
Meu site de plataforma vive quebrando. Migrar resolve?
Às vezes, e vale entender a causa antes de decidir. Quebra recorrente costuma vir de excesso de extensões que brigam entre si, de base personalizada por dentro que quebra a cada atualização, ou de falta de manutenção acumulada. As duas primeiras normalmente melhoram com reconstrução. A terceira melhora com disciplina, e migrar sem mudar o hábito só troca o tipo de problema. Olhamos o que existe antes de recomendar.
Vocês fazem área restrita, painel ou integração com sistema?
Não faz parte do que entregamos, e preferimos dizer isso a improvisar. Nosso escopo é o site: estrutura, conteúdo, caminhos de contato e medição. Área restrita, painel administrativo e integração contínua com outro software são outro tipo de projeto, com outra disciplina de manutenção. Quando o seu caso pede algo assim, avaliamos junto e apontamos o caminho, mesmo que ele passe por outro fornecedor.
Site em código funciona com blog?
Funciona, e a decisão está em quem vai publicar. Se os textos são escritos por alguém não técnico, com frequência, vale deixar essa área editável desde o projeto, o que é perfeitamente possível. Se a publicação é esporádica ou passa por quem mexe no código, nem isso é necessário. O que não recomendamos é entregar blog em área fixa para quem pretende publicar toda semana: em pouco tempo ele para, e blog parado comunica abandono.
Preciso de um desenvolvedor fixo depois que o site fica pronto?
Na maioria dos casos, não. Site institucional em código pede pouca intervenção, e o que costuma surgir é ajuste pontual, que cabe em demanda avulsa. O que evita a dependência não é ter alguém contratado, é a entrega estar organizada: código em repositório seu, contas em nome da empresa e o mínimo de documentação para outra pessoa assumir. Com isso você escolhe quando e com quem continuar, em vez de ficar preso a um fornecedor.
Continue por aqui
Vamos falar sobre desenvolvimento web?
Explique seu cenário e retornamos com um diagnóstico honesto do que vale a pena fazer primeiro.