Remote software developer jobs with real product responsibility
If you searched for remote software developer jobs in Argentina, you are probably doing more than browsing titles. You want to know whether the company has serious projects, whether the interview process is honest, whether compensation is discussed before you lose two weeks, and whether remote work here means actual trust or just a laptop at home with constant interruptions.
Siblings Software is a software development company founded in 2018 in Cordoba. Our engineers work with clients in fintech, healthcare, logistics, eCommerce, construction, and SaaS. Some roles are long-term staff augmentation inside a client team. Others are part of dedicated squads that include backend, frontend, QA, DevOps, UX, and technical leadership. This page explains how careers here work before you send a CV.
What this page is meant to answer
More than "we are hiring."
The intent behind this page is transactional with a strong commercial-investigation layer. A candidate may be ready to apply, but only after comparing Siblings Software with freelance work, direct employment, local agencies, and global remote platforms.
A good candidate wants details: role types, project reality, compensation model, hiring steps, technology stack, English expectations, and how much client exposure to expect. We will not pretend every project is glamorous. Some work is greenfield. Some work is modernization. Some work is careful maintenance of systems that already have users and revenue attached to them. The common thread is that the work is real and somebody depends on it.
Current and future paths at Siblings Software
Roles we hire for, and the pipeline behind them.
Openings change with client demand, but the talent pipeline is broader than the roles posted in a given week. If your background fits one of these areas, it is worth applying even when the exact title is not listed.
Backend and platform engineers
Java, Go, Python, Node.js, .NET, PostgreSQL, APIs, distributed jobs, integrations, and cloud services. We value people who can reason about data models, failure modes, and production support, not only framework syntax.
Frontend and full-stack developers
React, Next.js, Angular, Vue, TypeScript, design systems, dashboards, customer portals, and performance-sensitive web applications. Strong frontend candidates understand API contracts and product behavior.
Mobile engineers
React Native, Flutter, Kotlin, Swift, offline behavior, app store releases, push notifications, and device-specific QA. Mobile work often sits close to product design and release coordination.
QA automation and release engineers
Playwright, Cypress, API testing, CI pipelines, smoke suites, regression strategy, and test plans that fit the risk of the product. Good QA here is part of engineering, not a last-minute gate.
AI, data, and automation roles
AI engineers, data engineers, prompt and evaluation specialists, MLOps support, internal workflow automation, and developers who can connect LLM features to production systems responsibly.
Security, DevOps, and emerging specialists
Cloud security, AI security review, application security, DevOps, observability, blockchain developers, and smart contract reviewers when client work needs that depth. We prefer specific experience over fashionable titles.
If you want to understand the company behind these roles, read about our engineering team and the services clients hire us for, including staff augmentation, dedicated teams, and project-based outsourcing.
The work is closer to production than portfolio
No bench theater.
Many candidates ask whether Siblings Software is an outsourcing company, a staff augmentation company, or a product studio. The honest answer is that client needs decide the shape. One engineer may join a US client's sprint team. A squad may own a modernization track for a marketplace. A QA specialist may enter late in a release cycle to give the team a safer launch path.
What we try to avoid is bench theater: people sitting around while a sales team looks for something plausible. If we speak with you about a role, there should be a real project context or a realistic pipeline. We will tell you when a role is urgent, when it is exploratory, and when English or client-facing communication is non-negotiable.
Stacks vary. You may see React development, Node.js projects, Java, Go, Python, .NET, cloud platforms, data pipelines, or mobile frameworks. We also keep an eye on newer work around AI-assisted products, but we do not call a project "AI" because somebody added a chat box.
How we decide whether there is a match
An interview process that respects your time.
The interview process should respect your time. We are not trying to run a university exam or collect free consulting. The goal is to understand how you think, what kind of work you have actually done, and whether the project in front of us is fair for your level.
For engineering fundamentals, we care about production judgment: how you debug, how you communicate risk, what you test, and when you ask for help. Official docs still matter. Candidates who read resources like the TypeScript documentation, the Go documentation, or the OWASP Top Ten tend to bring better habits than people who only memorize interview answers.
1. CV and role fit review
We look for relevant production experience, stack fit, communication level, timezone overlap, and signs that the role would be a healthy next step.
2. Short screening call
We discuss availability, compensation expectations, English requirements, remote setup, and whether you prefer client-facing or quieter delivery work.
3. Technical conversation
You talk through real work: architecture choices, bugs you fixed, tradeoffs, tests, deployment issues, and where you still want to grow.
4. Practical exercise, when useful
Some roles include a small challenge or code discussion. We keep it narrow and related to the work, not an unpaid weekend project.
5. Project matching
We explain the client context, expected stack, team shape, communication cadence, likely duration, and risk areas before asking for commitment.
6. Offer and onboarding
If there is a match, we confirm compensation, start date, access steps, first-week expectations, and the people you will work with.
How money and the working model are discussed
Compensation expectations come up early, not late.
Career pages often dodge compensation because rates change by seniority, role, client, language requirements, and contract shape. We will not publish a fake universal salary band that becomes wrong in two months. What we can say is simpler: compensation expectations are discussed early, before a long technical process.
Most roles are long-term remote engagements. Some are full-time dedicated positions, some are project-based, and a smaller number may be part-time or fractional specialist roles. Senior engineers with strong English and client ownership usually sit in a different range than developers who are strong technically but still growing into direct communication.
Candidate mistake we see often
Optimizing only for the highest monthly number and ignoring project quality, stability, technical support, and whether the role will still help your career six months later. Money matters. So does the work attached to it.
Dedicated long-term role
Best for developers who want stability, deep context, and a team rhythm that grows over time.
Project-based work
Best when scope is clear and the client needs delivery capacity for a defined milestone.
Specialist support
Useful for DevOps, security, AI evaluation, performance, or architecture reviews.
Future pipeline
A good fit when your profile is strong but the exact role is not open today.
Siblings vs freelance, in-house, and large agency work
A direct comparison of the trade-offs.
Freelance platforms
What can be good: direct control, varied clients, and sometimes high short-term rates.
Where it can hurt: unpaid sales work, unstable pipeline, thin product context, and little backup when projects go sideways.
How Siblings is different: you get project support, recruiting context, client alignment, and people who can help when a technical or communication issue appears.
In-house role
What can be good: deep product ownership, benefits, and strong identity with one company.
Where it can hurt: growth can slow if the stack is narrow or the product is mature. Some teams become political.
How Siblings is different: you see different domains over time while still working in serious production environments.
Large agency
What can be good: large accounts, formal processes, and recognizable client logos.
Where it can hurt: you may be far from decision-makers, moved between projects without context, or buried in process.
How Siblings is different: our team is smaller. Leadership, recruiting, and delivery stay closer to the people doing the work.
Siblings Software
What can be good: remote work, long-term clients, varied stacks, and a human-sized engineering culture.
Where it can hurt: client work requires adaptability. You may need to learn a domain quickly and communicate uncertainty clearly.
How Siblings is different: we try to be direct about the project, risks, compensation model, and what the role will actually ask from you.
Where candidates tend to do well here
The best fit is not always the flashiest resume.
People succeed here when they can balance autonomy with communication, and when they understand that client work still needs engineering judgment.
A backend developer joins a logistics platform midstream
The first month is not about rewriting everything. It is reading domain rules, stabilizing queries, learning how warehouse events flow, and shipping a small change without breaking reporting.
A QA engineer adds release confidence before a healthcare launch
The valuable work is not only writing tests. It is deciding what should be tested first, where manual checks still matter, and how to make the CI signal useful instead of noisy.
A frontend developer inherits a messy dashboard
The job is partly React or Angular, but also product thinking: empty states, permissions, slow endpoints, and explaining why a design detail becomes expensive in code.
An AI engineer connects model output to business workflow
The useful candidate worries about evaluation, data privacy, user review, failure cases, and cost. The weak candidate only demos a prompt that works once.
What a real engagement can feel like from inside the team
A short mini case study.
One useful example is Bari, a B2B commerce platform connecting wholesalers and retailers. Siblings Software assembled a team with backend, frontend, and project management. The stack included .NET Core, React, and GraphQL. The work was not a toy marketplace; it had distributors, retailers, orders, and business operations that could not pause while the software evolved.
For a developer, the interesting part was the shape of the tradeoffs. GraphQL reduced endpoint churn while the frontend was still moving. Backend work had to respect real commerce rules. The team shipped the product in months, then continued with maintenance and product evolution. That kind of engagement rewards engineers who can work with ambiguity, ask precise questions, and leave code understandable for the next person.
You can read more in the Bari case study. It is a good example of the kind of client work behind many roles on this page.
What the engineer learns
- How to build features around real purchasing workflows.
- How to coordinate frontend and backend decisions without waiting for perfect specs.
- How to maintain a system after launch, when users start revealing the edge cases.
- How a small team communicates risk to a client without drama.
What we would tell a candidate upfront
This type of project is not for someone who only wants isolated tickets. It asks for ownership, patience with domain details, and enough humility to change course when users or data prove an assumption wrong.
What can go wrong in remote client work, and how we reduce it
Risks named in plain language.
Unclear ownership
We define who reviews code, who answers product questions, and who escalates blockers. Ambiguity is normal at first; silence is the problem.
Communication overload
Remote work should not mean meetings all day. We encourage concise written updates, useful standups, and async documentation when it saves focus time.
Wrong seniority match
A junior-friendly role and a senior ownership role are different jobs. We try to match people to the level of ambiguity they can handle.
Client context changes
Priorities change. When they do, we discuss the impact on scope, team health, and expectations instead of pretending nothing moved.
Technology mismatch
We will not sell you as an expert in a stack you barely know. Learning is welcome, but the project has to tolerate that ramp-up.
Burnout dressed as urgency
Production work has pressure. Still, a healthy team distinguishes a real incident from poor planning repeated every week.
How we work day to day
A human-sized engineering culture.
Siblings Software is a human-sized team. The company was founded by Javier Uanini, a software engineer who started building websites in 1999 and later worked in payment processing before returning to Argentina. That matters because technical decisions are not treated as a black box owned by sales. You can learn more about Javier and the team on our team page.
Day to day, you can expect Git-based workflows, pull requests, ticket tracking, standups or async updates depending on the client, and direct communication when the role requires it. Some clients are highly structured. Others need help becoming more structured. A good Siblings engineer can work in both settings without becoming cynical.
Our values are simple enough to test in daily work: honesty, professionalism, organization, curiosity, and care for the people around the product. We do not always get everything right. When something is off, we prefer a direct conversation early over a polite surprise later.
Frequently Asked Questions
It depends on the role. Client-facing roles usually need advanced English because you may join planning calls, discuss tradeoffs, or explain blockers. Some internal or lower-client-contact roles can work with intermediate English, but communication still matters.
Most roles are built around Argentina time and remote work from Latin America, especially Argentina and Uruguay. The exact location requirement depends on contract details, client overlap, and legal constraints for that engagement.
Sometimes, but not for every client project. Many roles require people who can contribute in production quickly. Strong juniors with clear fundamentals, Git discipline, and good communication should still apply for future opportunities.
Often, yes. Some roles include direct client calls and planning. Others work through a tech lead or delivery manager. We clarify this during matching because not every strong developer wants the same level of client exposure.
Send a CV, LinkedIn profile, GitHub or portfolio if relevant, your main stack, English level, location, availability, and compensation expectations. A short note about the kind of work you want helps more than a generic cover letter.
Yes, when the project and your fundamentals support it. We have seen QA engineers grow into frontend ownership and backend developers move into cloud or data-heavy work. The transition has to be honest about ramp-up time.
Send a focused application
Specificity saves everyone time.
If one of these roles sounds close to your background, send your CV to camila@siblingssoftware.com. Mention the role or stack you are targeting, where you are located, your availability, English level, and the type of project you want to avoid as well as the type you want to join.
A developer who says "I want backend work with strong data modeling, not pixel-perfect frontend" is easier to match than one who says "anything." A QA engineer who prefers release strategy over repetitive manual scripts tells us something important.
Quick application checklist
- CV or LinkedIn profile with recent production work.
- Main stack, secondary stack, and what you want to learn next.
- English level and whether you are comfortable on client calls.
- Location, timezone, and earliest realistic start date.
- Compensation expectations or range, if you are comfortable sharing it.
- GitHub, portfolio, case notes, or writing if it helps show your work.
OUR STANDARDS
A careers process that earns the application, not the other way around.
We discuss compensation expectations early, name the project context behind a role before the technical conversation, and explain what is uncertain instead of pretending every engagement is identical. A candidate's time should buy clarity, not vague pipelines.
Engineers are matched to projects where the bottleneck actually fits their experience, with a real owner on the client side and a senior reviewer on ours. Roles are remote, communication is honest, and feedback after a process is concrete enough to act on.
Talk to Siblings Software Argentina
Hiring partners and candidates can both write here.