Meet the team behind Siblings Software
Most people who land on a team page are not only curious about names and photos. They are deciding whether a software outsourcing company has the judgment, seniority, communication habits, and stability to touch a real product.
Siblings Software was founded in 2018 in Cordoba, Argentina. Our team supports companies in fintech, healthcare, logistics, construction, B2B commerce, and SaaS. Some clients hire one senior engineer to unblock a roadmap. Others ask us to assemble a dedicated product squad with backend, frontend, QA, DevOps, UX, and delivery leadership.
What buyers are really trying to learn
Commercial investigation, not a stock-photo grid.
A visitor may search for a software development team in Argentina, a nearshore development partner, or the people behind Siblings Software. They want to compare the team against freelancers, local hiring, and larger agencies.
The practical questions are sharper than the query: Can this team join our sprint rhythm? Who reviews architecture? Can we start with one role and grow into a squad?
Siblings Software is a fit when the product matters enough that "just send resumes" is not enough. Common scenarios include a US startup with no backend bench, a mid-market company modernizing an internal tool, a SaaS company that needs React and Node engineers for a feature surge, or a regulated business that wants QA and DevOps maturity before launch.
For broader service context, see our dedicated development teams, staff augmentation, and project-based outsourcing pages.
The people behind the work
A real team, not a stock-photo grid.
These are the people who shape hiring, delivery standards, communication habits, and the technical judgment clients experience in daily work.
Javier Uanini
Founder & CEO
Javier started building websites in 1999, studied Software Engineering, and worked in payment processing in New York before returning to Argentina. He stays close to reliability, architecture, and client expectation decisions.
Juan Pablo Licera
Chief Technology Officer
Juan oversees product development, technical direction, and team alignment. Clients meet his influence in code reviews, staffing decisions, and clear technical tradeoff discussions.
Camila Guido Y Spano
Chief People Officer
Camila leads recruiting and onboarding. Her work protects team fit: communication style, ownership, seniority, and whether a person can work cleanly in a client environment.
Jose Obregon
Tech Lead
Jose has been part of Siblings Software since the early projects. His background spans React, Node.js, GraphQL, and Gatsby, with practical leadership for unclear product requirements.
Maximiliano Tomassi
Senior Frontend Developer
Maximiliano brings backend history and frontend depth. That matters because interface work often exposes API gaps, data-shape problems, and product details.
Denisse Peduzzi
Chief Marketing Officer
Denisse brings communications experience across Latin America, Asia, Europe, and Oceania. For clients, that shows up in clearer handoffs and less friction between technical and business teams.
From first call to a working team
Useful team design starts with product context, not random CVs.
We do not start by forwarding random CVs. A useful team design starts with product context: what is blocked, what must not break, who owns decisions, and what the first 30 days should prove.
Our delivery rhythm is compatible with the Scrum Guide, but we are not religious about ceremony. If your team uses Kanban, Shape Up, weekly release trains, or a hybrid process, we adapt the rituals while keeping visibility high.
1. Fit call and context review
We discuss product goals, users, roadmap pressure, codebase health, security needs, timezone overlap, and whether outsourcing is the right move.
2. Team shape and budget range
You get a recommended composition, such as two full-stack engineers plus QA, or a senior backend developer with fractional tech leadership.
3. Profile review and interviews
For staff augmentation, you meet candidates. For dedicated squads, we introduce key leads and explain the delivery setup before kickoff.
4. Onboarding into your environment
We enter your repos, backlog, CI/CD, communication tools, and access controls. Early pairing helps assumptions surface before they become rework.
5. First sprint and calibration
The first sprint is deliberately small. We validate estimation, review standards, release paths, and meeting cadence before increasing throughput.
6. Ongoing governance
Weekly or biweekly reviews cover delivery, blockers, technical debt, team health, and next priorities. Nobody should need to chase status.
What you can hire, and what it means financially
A realistic frame before a sales call.
Exact pricing depends on seniority, duration, stack, and the amount of leadership required. Still, a buyer deserves a realistic frame before a sales call.
Team extension
Best when you already have product management and architecture covered, but need one or more engineers who can work inside your process.
Typical budget: monthly retainer per role, usually planned around seniority and expected hours.
Dedicated squad
Best when you need a stable pod that owns a product area or long-running modernization stream with its own delivery cadence.
Typical budget: often starts in the low five figures per month and scales with team size.
Project-based team
Best when scope, acceptance criteria, and launch window are clear enough to plan a defined delivery with milestones.
Typical budget: phased proposal with discovery, build, QA, launch, and support separated.
A mistake we see often: companies compare a vendor's hourly rate with an employee salary and stop there. The real comparison includes recruiting time, benefits, management load, turnover risk, unused capacity after launch, and the cost of slow delivery.
Nearshore team vs freelancers, in-house, and large agencies
Where each option works, and where it breaks down.
Freelancers
Where it works: short tasks, narrow fixes, prototypes, and isolated expertise.
Where it gets risky: continuity, documentation, backup coverage, and long-term code ownership can be fragile.
What we change: you get a managed team with replacement coverage, shared standards, and delivery oversight.
In-house hiring
Where it works: permanent strategic roles, deep product ownership, and cultural continuity.
Where it gets risky: hiring can take months. A single bad hire is expensive. Specialized roles may sit underused after a project.
What we change: we give you capacity now, while your internal hiring can continue at a healthier pace.
Large agencies
Where it works: broad programs, big procurement requirements, and multi-country account structures.
Where it gets risky: senior people may disappear after sales. Delivery can become process-heavy.
What we change: you work closer to the people making technical and staffing decisions.
Nearshore team
Where it works: roadmap acceleration, product modernization, staff augmentation, and dedicated squads.
Where it gets risky: it fails if onboarding is shallow, communication is vague, or ownership boundaries are unclear.
What we change: we define ownership, rituals, code review expectations, and escalation paths before velocity is promised.
Where our team is usually useful
When business context and engineering quality both matter.
Modernizing a revenue-critical web application
A client has a working platform, but releases are slow and the front end is hard to change. We add React or Angular experience, stabilize API contracts, improve automated tests, and release in increments.
Building integrations around an existing system
Payment gateways, CRMs, ERPs, logistics providers, and analytics systems are rarely clean. We map failure modes, retry logic, security concerns, and observability instead of treating integrations as "just API calls." Our API development team does this often.
Adding QA and release discipline before launch
Founders often wait too long to add QA. We bring test plans, smoke suites, acceptance criteria, and release checklists before production pressure makes quality expensive.
Supporting a CTO with too many priorities
A CTO should not personally unblock every pull request, deployment, and hiring decision. We can add senior delivery capacity while keeping architecture decisions transparent.
A B2B marketplace team that shipped without stopping operations
A short mini case study.
Bari, a wholesale commerce platform, needed more than a brochure site. The project required a web application for distributors and retailers, a REST backend on .NET Core, a React frontend, and GraphQL decisions that reduced endpoint churn while the product was still moving.
Siblings Software assembled a six-person team: three backend developers, two frontend developers, and a project manager. The team released the product in six months, then stayed involved for maintenance with a leaner setup.
Read the Bari case study or browse more software outsourcing case studies.
What made the team effective
- Clear team composition tied to the product, not a generic bench.
- Backend and frontend decisions made together, which reduced rework.
- Project management focused on release progress and unresolved product questions.
- Post-launch support adjusted to the product's real maintenance needs.
What buyers usually underestimate
Outsourcing risk is real, and pretending otherwise is a bad sign.
The answer is not pretending risk does not exist. The answer is designing the relationship so problems surface early.
Risk: unclear ownership
Mitigation: we define who approves architecture, who prioritizes backlog items, who merges code, and who can stop a release. If nobody owns a decision, the project pays for it later.
Risk: weak security habits
Mitigation: access is scoped, repositories stay in the client's environment when needed, and review practices can align with standards such as the OWASP Application Security Verification Standard.
Risk: inaccessible products
Mitigation: for user-facing applications, we discuss accessibility and browser behavior early. We use the WCAG guidance from W3C when the product has public or regulated users.
Risk: vendor dependency
Mitigation: we document meaningful decisions, leave runbooks, and avoid hiding knowledge inside private vendor channels. A good outsourcing relationship should make your team stronger, not trapped.
Questions clients ask before hiring
The decisions that come up before the engagement starts.
Can we interview the engineers?
Yes for staff augmentation and key dedicated roles. For larger squads, you meet leads and review team composition. You should know who is joining your product.
What time zone overlap should we expect?
Our team is based in Argentina, which gives strong overlap with US Eastern and Central time, plus partial overlap with Europe for planning and demos.
What if the first developer is not a fit?
We diagnose skill, communication, or role mismatch quickly and adjust. The advantage of a company over a solo freelancer is that replacement and support are possible.
Do you only provide developers?
No. Many engagements include QA, DevOps, project management, UX, and technical leadership. The right team depends on the bottleneck. Sometimes one senior backend developer is enough. Sometimes it is not.
Can you work with our existing team?
That is the normal case. We join your tools and review process. If pieces are missing, we suggest lightweight fixes instead of forcing a heavyweight methodology.
How do we get started?
Send the product context, target roles, approximate timeline, and any constraints around security, time zone, or budget. We will respond with a practical team recommendation and next steps.
OUR STANDARDS
A team that earns its name only when the work survives the engagement.
Every engagement we lead is anchored by a senior engineer who has shipped real production work under real release pressure. We design teams around the decisions you actually need made, not job titles, and we keep the work visible through demos, written status, ADRs, and risk notes you can read in five minutes.
We document trade-offs in your repository, keep credentials in your accounts, prefer feature flags and staged rollouts over hero launches, and write the runbooks your future hires will rely on. The goal is not heroics. It is releases that stop feeling like events.
Contact Siblings Software Argentina
Tell us what you are trying to build, fix, or accelerate.