Software does not fail in the demo.
It fails at 3 a.m.
We design, build and stabilise the systems a product runs on: distributed services, cloud platforms and AI features that keep working once real users arrive.
Remote from Argentina · Working in English and Spanish · Overlapping hours with the Americas and Europe
Code stopped being the bottleneck
AI writes code faster than most teams can review it. What stayed scarce is the judgement to decide what to build, in what order, and what will quietly break in six months. That does not get generated. It gets accumulated, usually one production incident at a time.
Most projects do not fail for lack of developers. They fail because nobody with enough scars is holding the shape of the system: which trade-offs are worth taking, which shortcuts become next year's rewrite, and when the boring option is the correct one.
That is the part we bring. We use AI daily and it makes us faster, but it does not decide the architecture, and it does not carry the consequences of getting it wrong. Somebody has to, and that is what you are actually hiring.
Why teams call us
Most engagements start with one of these and grow into the next.
Backend & distributed systems
Event-driven services, REST and gRPC APIs, async workers and queues in Go, Python and TypeScript, with idempotency and retries designed in rather than added after the first duplicate charge.
Read moreHardware & industrial integration
Software that talks to machines: MQTT telemetry, device control, embedded systems and SIP. Equipment that predates the cloud, protocols documented in a PDF nobody scanned, and a test environment that is a running operation.
Read moreAI systems in production
Everyone has an LLM prototype that works on a good day. We build the bridge: retrieval that retrieves, answers grounded in your sources, evaluation before deploy, and cost you can predict.
Read moreAuditable AI systems
Most teams with a model in front of their data cannot say what it saw, why it answered that, or who was allowed to see it. Logging, versioning, permission-aware retrieval and evaluation, built as evidence rather than as a policy document.
Read moreAgent-ready systems
Exposing an API so a model can call it takes an afternoon. Permissions that follow the person, idempotency for a caller that retries, a bounded blast radius and attribution afterwards are the parts that break.
Read moreAI-generated code review
Your team writes code faster than anyone can review it. We read what was generated, exercise the path a real user takes, and leave your engineers with the criteria to judge the next batch themselves.
Read moreTechnical leadership
A senior engineer who decides which of the five possible approaches you are taking, writes down why, and is still there when the consequence arrives. Part time, for teams that need judgement more often than another pair of hands.
Read moreCloud platform & DevOps
AWS and Kubernetes defined in Terraform, pipelines that deploy without a ritual, and permissions that are deliberate instead of inherited from whoever set it up first.
Read moreObservability & reliability
OpenTelemetry tracing, logs and metrics that connect, SLOs based on what users notice, and alerts few enough that people still trust them. Usually the fastest way to cut recovery time.
Read moreWeb & product engineering
React and Next.js products, dashboards and admin panels, built by people who also built the backend behind them. Plus e-commerce builds and migrations.
Read moreMaintenance & modernisation
The system that already runs and nobody wants to touch. Upgrades, security debt, migrations and ongoing support, including for code we did not write. Modernised in reversible steps rather than rewritten.
Read moreArchitecture review
Two weeks, fixed price, one written report: what breaks first, what costs too much, what blocks delivery, and what to do about each. Self-contained, and yours to act on with anyone.
Read moreSolutions we implement
Systems we have already solved once and now adapt per client, so you are not paying us to rediscover the same problems.
Document Q&A with citations
Ask questions of your own documents and get answers that show their sources. Hybrid vector and keyword retrieval, rank fusion, diversity filtering, and an evaluation suite so answer quality is measured instead of assumed.
Read more AI · QualityEvaluation harness for AI features
Know whether a change to a prompt, model or retrieval step made things better or worse, before your users find out. Scored against a fixed question set, with cost and latency tracked per change.
Read more PlatformProduction starter platform
The scaffolding we reuse to reach production quickly without the shortcuts that become next year's rewrite: auth and roles, payments, workers, observability from day one, CI/CD and IaC.
Read morePick the shape that fits
Four contracts that cover nearly every engagement. If none of them fits, say so and we will find one that does.
Architecture review
Two weeks, one written report ranking what breaks first by what it will cost you.
How it worksProject build
A defined piece of work at a defined price: an integration, a service, a migration, a first production system.
Describe your projectEmbedded engineering
We join your team for an agreed number of days a month. Your repo, your standups, your review process.
Check availabilityRescue & stabilise
Something is on fire or a launch is at risk. Stabilise first, find the real cause second.
What that involvesHow an engagement runs
No discovery phase that bills for three weeks and produces a slide deck.
A real conversation
Thirty minutes on what you are building or what is breaking. If we are not the right fit, we say so.
Scoped proposal
What we will do, what we will not, how long it takes and what it costs. In writing, before anything starts.
Ship in slices
Working software in your environment early and often, not one big reveal at the end.
Handover that holds
Docs, runbooks and a walkthrough, so you do not need us on retainer to keep it alive.
The code we leave behind
It has to be able to grow without us. Explicit boundaries between domain and infrastructure, dependencies pointing inward, and tests at the levels that earn their keep. None of that is purism: the point is that the next feature does not cost three times the last one, and that in two years the system can still be changed by someone who was not there when it was written. Where a pattern does not pay for itself, we leave it out and say why.
What we reach for, and why
The interesting part of a stack is not the list. It is knowing when not to use something. These are the defaults we argue for, and the cases where we argue against them. To be clear about what this is: it describes what we recommend, not what we work with. If your team already runs something else and maintains it well, we work in that.
Go for the hot path
When a p99 matters more than developer convenience: latency-sensitive services, high concurrency, long-running workers. Predictable memory behaviour and a deployment story that is a single binary.
Not for a CRUD admin panel. You would be paying in verbosity for performance nobody asked for.
Python where the ecosystem is the reason
AI and data work, where every library you need already exists and reimplementing it elsewhere is a bad trade. FastAPI when it has to be a service rather than a script.
Not for a latency floor measured in single-digit milliseconds under heavy concurrency.
TypeScript to stay close to the team
When your engineers already live in Node, or when front end and back end should share the same types and stop disagreeing about the shape of a response.
Not as a way to have one language everywhere. That argument usually costs more than it saves.
PostgreSQL until proven otherwise
The default, and it stays the default longer than most teams expect. It does JSON, full-text search, queues at modest volume and vector search through pgvector.
Reach elsewhere when the access pattern genuinely demands it, which is rarer than the architecture diagram suggests.
Kubernetes only once it pays for itself
Worth its complexity when you run many services, need fine-grained scaling, and have the operational maturity to support it.
Not for five services. Managed container platforms are cheaper to run and far cheaper to understand, and we would rather say so than sell you a cluster.
OpenTelemetry so the data stays yours
Vendor-neutral instrumentation, so your telemetry can move from Datadog to Grafana to whatever is next without re-instrumenting every service.
Avoid instrumenting with a single vendor's proprietary SDK. That is the decision people regret at renewal time.
Also in regular use: Kafka, RabbitMQ and Amazon SQS · Redis · MySQL and MongoDB · PHP 8, Laravel, Symfony and Django · gRPC and WebSockets · AWS, EKS and GCP · Terraform, Docker and GitHub Actions · Prometheus, Grafana and Datadog · React, Next.js and Tailwind · OpenAI APIs, LangChain and LangGraph · Asterisk, Kamailio and MQTT.
Practices, for those who look for them by name: hexagonal architecture, domain-driven design, CQRS and event sourcing where the domain justifies them, SOLID principles applied with judgement rather than as doctrine, dependency inversion, contract and integration testing, trunk-based development and code review.
We have also delivered production work in Scala and Java. What you are hiring is architecture judgement, not syntax: idempotency, backpressure, transaction boundaries and failure design are the same problem in every language, and the language is the vehicle. If your team runs something we have not listed, ask anyway. If we are not the right people for it, we will say so and point you somewhere better.
Domains where we have already shipped
Useful mostly because it means starting with the vocabulary and the edge cases already known.
Payments & subscriptions
Gateway integrations, recurring billing, reconciliation and payout flows.
E-commerce
Platform implementation and migration across Magento, PrestaShop and WooCommerce.
Media & streaming
Video pipelines, transcoding, on-demand delivery and AI-assisted media generation.
Education
School administration, payments, coursework and management platforms.
Agriculture & livestock
IoT-enabled livestock management and multi-tenant field operations software.
VoIP & telephony
Asterisk and Kamailio work, SIP traffic handling and call-centre systems.
Hardware integration
Applications talking to embedded systems, MQTT telemetry and device control.
Hospitality
Customer, payment and delivery management for restaurants and hotels.
Common questions
What does Devsitia IT actually do?
We build and stabilise backend systems: APIs, event-driven services, async workers and the cloud infrastructure they run on. In practice we get called for one of three reasons. Something needs to be built and it has to survive real traffic. Something already exists and keeps falling over. Or an AI feature works in a demo and nobody knows how to make it production-grade.
Do you work with an existing engineering team, or only greenfield projects?
Both, and most of our work is the first one. We are usually embedded alongside an in-house team, working in their repository, their review process and their deployment pipeline. Our aim is that your engineers can maintain what we leave behind without us.
How do you charge?
Fixed scope and fixed price when the problem is well defined, such as an architecture review or a specific integration. Monthly for ongoing engineering work. We put the number in writing before starting, and we would rather turn down work than quote something we do not believe.
Where are you based, and how does that work across time zones?
Devsitia IT is based in Argentina and works remotely with clients worldwide. Our working day overlaps almost entirely with North America and covers the morning in Europe, so most teams get real-time collaboration rather than overnight handoffs. We work in English and Spanish.
We have an LLM prototype that works sometimes. Can you make it reliable?
That is one of the most common requests we get, and it is rarely a model problem. It is usually retrieval quality, missing evaluation, no guardrails, unbounded cost, or an architecture that assumes the model always answers quickly and correctly. We start by measuring how often it is actually wrong, then fix the parts that cause it.
What size of company do you work with?
Mostly startups and product teams, from pre-launch companies needing a first production system through to established platforms with scaling or reliability problems. We are a small senior team, so we take on a limited number of engagements at a time.
How soon can you start?
An architecture review can usually begin within a week or two. Larger engagements depend on current commitments. The fastest way to find out is to email us with a couple of sentences about the problem.
Tell us what is breaking
You will get a straight answer from an engineer, not a sales script. If it is not something we should take on, we will say so and point you somewhere better.