Cara, antes de tudo, parabéns pelo esforço e pela criatividade. Dá para ver no seu texto que você não está reclamando por reclamar; você está tentando resolver um problema real dentro de limitações bem concretas. Esse tipo de iniciativa tem valor. Muita gente só apontaria o problema. Você foi lá e construiu uma ponte.
Dito isso, preciso te falar uma coisa com respeito e franqueza, porque já vivi algo muito parecido há bastante tempo.
O risco técnico da sua solução é apenas uma parte da história. O risco maior é organizacional. Quando a empresa não te dá ambiente, não te dá arquitetura, não te dá apoio formal, mas aceita que você resolva tudo sozinho com criatividade, acontece uma armadilha: quanto mais competente você for, mais você mascara a fragilidade estrutural da empresa. A automação melhora a rotina, seu chefe gosta, todo mundo passa a depender de você, mas seu cargo não muda, seu salário não muda, e muitas vezes você ainda vira uma ameaça silenciosa para o departamento de TI ou para a burocracia interna.
Pior: você começa resolvendo um gargalo legítimo e, sem perceber, pode acabar virando o “milagreiro oficial” da operação. A empresa economiza estrutura porque você compensa com esforço, improviso e inteligência. Isso parece reconhecimento no começo, mas muitas vezes é só dependência sem valorização real. E dependência sem valorização cobra caro com o tempo.
Falo isso porque já passei por ambiente onde fiz trabalho muito acima do cargo, automatizei, projetei, implantei, segurei rojão, e vi de perto como isso pode virar um tiro no pé. Você melhora tanto o sistema precário que a empresa perde o incentivo de amadurecer. E aí o profissional cresce tecnicamente, mas fica preso num papel pequeno demais para o tamanho do que entrega.
Por isso, eu enxergo duas saídas saudáveis para você.
A primeira é a mais radical, mas às vezes a mais lúcida: pedir demissão e procurar um ambiente onde sua capacidade seja tratada como engenharia, não como remendo permanente.
A segunda, caso você queira continuar aí, é parar de empurrar concorrência de escrita para SMB e assumir uma arquitetura mínima, simples e honesta. Em vez de cada estação disputar arquivo compartilhado, eleja uma máquina ou um processo como master e centralize a escrita nela. Pode ser um pequeno processo .NET auto-hospedado, com uma Web API simples, usando SQLite local, LocalDB ou outro mecanismo local ao host. Os demais clientes só consomem a API. Não precisa IIS, não precisa um “grande servidor”, não precisa nada pomposo. Só precisa parar de tratar filesystem compartilhado como se fosse coordenador transacional.
Se nem isso for politicamente aceitável, então o problema já deixou de ser técnico. Aí é sinal de que a organização quer resultado de sistema sem aceitar as condições mínimas para existir um sistema. Nesse cenário, você corre o risco de passar anos sustentando uma estrutura frágil nas costas.
Seu esforço é bom. Sua criatividade é boa. Seu texto mostra capacidade real. Mas justamente por isso vale o alerta: cuidado para não usar seu talento para consolidar um ambiente que nunca vai te devolver, em estrutura e reconhecimento, o que você está entregando.
Às vezes a solução mais inteligente não é fazer a gambiarra funcionar melhor. É perceber que você está bom demais para ser transformado em infraestrutura invisível. --Dica rápida, bem prática: se você tem um Visual Studio Community e consegue rodar um projeto básico em Blazor na sua máquina, já vale um teste muito simples. Abre esse projeto localmente, descobre o IP da sua estação e tenta acessar pelo navegador de outra máquina da rede usando IP e porta. Se a estação do seu colega não usa proxy no navegador, há uma chance muito alta de isso já funcionar sem IIS, sem SQL Server e sem nenhuma grande cerimônia.
Se abrir no browser, você já provou o ponto principal: a rede provavelmente aceita um pequeno servidor web auto-hospedado dentro do próprio app. A partir daí, você pode evoluir para um servidor seu com Blazor Server, por exemplo, e usar uma API simples por trás. O banco deixa de ser o problema central, porque pode ser qualquer coisa local à máquina host: PostgreSQL, SQL Server, Access, SQLite, o que fizer sentido para o seu cenário e para o que você consegue operar.
Se não abrir no navegador, ainda vale testar com algo mais cru: um client console .NET simples, um GET básico, ou até um curl. Se esse teste conseguir trazer a página inicial ou algum endpoint, então o caminho continua viável e o gargalo pode estar só no browser, proxy ou política local.
O mais importante aqui é que isso te permite sair da lógica de “arquivo compartilhado tentando virar banco” e entrar numa arquitetura mínima, mas muito mais honesta: sua estação vira o host, os outros acessam por IP e porta, e enquanto sua máquina estiver ligada o sistema existe. Isso já serve como MVP real. Depois, se a empresa topar, você dá o próximo passo e sobe isso num servidor web de verdade, em Linux ou container, sem custo alto e com muito mais legitimidade técnica.
Na prática, esse tipo de escassez muitas vezes se resolve quando a solução não exige investimento financeiro. E mesmo que a empresa não abrace de vez, esse experimento já te capacita, te tira da zona do remendo e te aproxima de um modelo mais profissional.
Se até um teste desses for barrado, eu honestamente não perderia energia tentando convencer demais. Usa o que for possível no curto prazo, aproveita o que já construiu como aprendizado e começa a se preparar para sair. Porque daí o problema não é mais técnico, é cultural, e isso raramente melhora.