pular para o conteúdo
~$ rebootworks
01 — build

software que se encaixa no jeito que você já trabalha

sites, web apps, ferramentas internas e as integrações que fazem seus sistemas conversarem. escopo fechado antes de começar, preview desde o primeiro dia, hardening antes de ir pro ar.

o que a gente faz

se roda no navegador e faz diferença pro seu negócio, entra no escopo.

  • sites institucionais e landing pages
  • agendamento e reservas
  • portais e áreas do cliente
  • dashboards internos
  • orçamentos e faturamento
  • controle de estoque e de ordens de serviço
  • integrações com apis e sistemas de terceiros
  • importação e migração de dados
  • automação de processos
  • recursos de IA com uso real
escrevendo e publicando código de aplicação
ls deliverables/

o que você recebe, sempre

01

escopo por escrito

o que vai ser feito, o que não vai e a data de entrega. tudo combinado antes de alguém abrir o editor.

02

link de preview ao vivo

você recebe o link no primeiro dia e vê o projeto ganhando forma. se a gente estiver indo pro lado errado, você avisa enquanto mudar ainda é barato.

03

o código-fonte

na sua conta do git, no seu nome, com histórico legível. continua seu, com a gente ou sem a gente.

04

suas próprias contas

hospedagem, domínio, banco de dados, analytics: tudo criado no seu nome, com você como dono desde o começo.

05

uma revisão de segurança

a gente ataca o sistema antes de lançar. autenticação, controle de acesso, injeção, segredos, headers, dependências.

06

um documento de handover

como atualizar o conteúdo, pra quem ligar, o que roda onde. escrito pra gente normal, não pra engenheiro.

revisando código antes de publicar
como a gente escolhe ferramentas

tecnologia chata, de propósito

a gente escolhe ferramentas pras quais existe gente no mercado e que dá pra passar adiante. nada de framework que ninguém conhece, plataforma que cobra por usuário pra sempre ou arquitetura que só funciona se a gente continuar por perto.

  • o mais simples que resolve, e nada além disso
  • hospedagem que dá pra levar pra outro provedor
  • uma stack que outro desenvolvedor pega sem precisar de explicação
  • nenhum serviço novo, a não ser que ele tire mais trabalho do que cria
time ./build

prazos aproximados

faixas reais, tiradas de escopos reais. o seu recebe uma data exata no orçamento.

▸
landing page
uma página, com texto seu ou nosso, no ar e com rastreamento.
1–2 dias
▸
site institucional
5–10 páginas, conteúdo editável, formulários, analytics, o básico de SEO.
1–3 dias
▸
integração ou automação
dois sistemas conversando, ou um processo manual que vira um clique.
3–10 dias
▸
ferramenta interna / dashboard
login, perfis de acesso, dados reais, trilha de auditoria.
2–6 semanas
▸
web app pra seus clientes
contas, pagamentos, notificações, um painel de administração.
6–12 semanas
man software

perguntas sobre software

Q:de quem é o código?
seu, desde o primeiro commit. fica na sua conta do git e você leva pra quem quiser. a gente não usa termos de licença, framework próprio nem truque de hospedagem pra deixar a saída cara.

abrir essa pergunta

Q:vocês pegam um sistema que já existe?
sim. a gente começa com uma revisão curta (o que ele faz, em que estado está, onde mora o risco) e te entrega uma avaliação por escrito antes de mexer em qualquer coisa. às vezes a resposta honesta é que reescrever sai mais barato do que consertar.

abrir essa pergunta

Q:vocês usam IA pra escrever código?
usa, do jeito que qualquer time usa hoje: scaffolding, testes, revisão. uma pessoa ainda lê cada linha antes de ir pro ar. o que a gente não faz é enfiar um recurso de IA no seu produto só porque está na moda.

abrir essa pergunta

Q:e as mudanças depois do lançamento?
ou você assume com o documento de handover, ou mantém a gente num contrato mensal pra atender as mudanças conforme aparecem. troca de texto e imagem, em geral, o seu próprio time consegue fazer, porque a gente monta pensando nisso.

abrir essa pergunta

Q:vocês fazem aplicativo pra celular?
a gente faz web apps que funcionam direito no celular, o que cobre a maior parte do que as pessoas querem quando pedem um app. se for um app nativo de loja mesmo, a gente diz se vale a pena e, se não for a nossa praia, indica quem faz.

abrir essa pergunta

todas as perguntas