The short version
I studied software engineering at UTN Córdoba, moved to New York to work in payment processing, and came back to Argentina to start a company with my sister. That was 2018. Today Siblings Software has about 30 engineers, a US legal entity in Florida, and clients spread across fintech, healthcare, and logistics. I still review architecture for new projects, still write code when something is on fire, and I am still based in Córdoba.
If you are here because you are evaluating us as a potential vendor, this page is meant to give you the full picture: my background, how the company actually works, and what kind of projects we are built for. No pitch deck language, just the details.
Background: from dial-up experiments to payment systems
My first website went live in 1999. I was twelve, working with Microsoft FrontPage on a Windows 98 machine connected through Arcor dial-up. The site was terrible by any standard, but it loaded on a browser and other people could see it. That was enough to hook me. Through high school I kept building small things: Visual Basic programs, HTML pages full of inline styles and table layouts, the kind of code that would horrify anyone today but taught me how things actually worked under the hood.
I enrolled in Software Engineering at Universidad Tecnológica Nacional (UTN) in Córdoba. The degree was rigorous and practical. More importantly, it was where I met Maximiliano Tomassi and José Obregón, two people who would eventually become co-founders. University gave me the theory. It also gave me a network of engineers I trusted enough to start a company with years later.
After graduating I moved to New York City and spent several years working in payment processing. This was a formative period. Financial software operates under constraints that most web applications never face: PCI-DSS compliance audits every year, transaction APIs that must be idempotent under all conditions, settlement engines processing millions in daily volume, and a cultural expectation of zero unplanned downtime. I learned to think about software not as features but as systems with real financial consequences when something breaks.
That mindset — treat every deployment as if money is on the line — is what I brought back to Córdoba. It shapes how we run projects at Siblings Software even when the domain is not financial. Healthcare systems and logistics platforms have different compliance requirements, but the underlying principle is the same: reliability is not a nice-to-have.
Each phase changed how I think about building software — and what I expect from the teams I lead.
How Siblings Software started and grew
In 2018 my sister Constanza and I registered the company. The name was literal — a business started by siblings. Maximiliano and José joined immediately, and the four of us took on our first contracts out of a small office near downtown Córdoba. No accelerator, no outside funding, no pitch deck. We got clients by delivering working software and letting the results speak.
The early work was unglamorous: inventory systems for Argentine small businesses, internal dashboards for local companies, payment integrations that nobody outside the client's office would ever see. But every project built process. We developed our own sprint cadence, our own code review discipline, our own approach to estimating that accounts for the things engineers always underestimate (integration testing, deployment configuration, the third-party API that behaves nothing like its documentation says).
By 2020 we were ten people, all remote across Córdoba. The pandemic forced companies worldwide to accept distributed teams overnight, and US startups that had never considered offshore development suddenly needed it. Our timezone overlap with the East Coast (Córdoba is UTC−3, just one hour ahead of New York for most of the year) and the team's fluency in English made us a natural fit. Growth was steady but deliberate. We hired ahead of demand only once, learned why that was a mistake, and never did it again.
In March 2021 we incorporated an LLC in Florida. The engineering team stayed in Córdoba, but having a US entity simplified contracting, invoicing, and SOW execution for American clients. Today we operate as a dual-presence company: legally American where it matters for procurement, operationally Argentine where it matters for talent and cost structure.
We are currently around 30 engineers. I have no interest in growing to 200 for the sake of a number. The goal is a team size where I can personally know every engineer's strengths, where we can staff projects thoughtfully instead of by headcount, and where the person who signs off on architecture is reachable on Slack — not behind three layers of account management.
Industries and technical work
I am most useful to clients when the project sits at the intersection of complex business rules and non-trivial engineering. Three domains come up repeatedly.
Fintech and payment systems
This is where my background runs deepest. We have built payment gateways, digital wallet backends, KYC verification flows, and transaction reconciliation pipelines for clients in the US and Latin America. PCI-DSS compliance is not something we bolt on at the end — it is baked into the architecture from the first pull request. The SUR Technology Holdings project is a good example of what fintech delivery looks like at this scale.
Healthcare platforms
We have built clinical data platforms, scheduling systems, and remote patient monitoring applications. Healthcare software is unforgiving — a patient-facing app cannot go down during a consultation, and data privacy violations carry real legal consequences. I personally lead the security architecture review on these projects because the risk profile demands it. Role-based access control, audit trails, and encrypted data at rest are table stakes, not extras.
Construction and logistics
Field reporting apps, project management dashboards, and inventory tracking systems that connect office workflows with jobsite reality. Our work with Bari on a distributor web portal reduced manual data entry by over 60% and streamlined their order processing pipeline.
The stack we reach for
For web products, the default combination is React with Next.js on the frontend and Node.js with TypeScript on the backend, typically deployed to Vercel. We choose this stack not because it is trendy but because it delivers fast iteration, solid SEO through server-side rendering, and a deployment workflow that eliminates most DevOps overhead. For mobile we work with React Native, Swift, or Kotlin depending on the project constraints. Backend services usually include PostgreSQL and Redis.
A real project: stabilizing a payment gateway under load
In late 2022, a US-based fintech client came to us with a payment gateway that was dropping transactions during Argentine retail traffic spikes — specifically Friday afternoons when card-present and e-commerce volumes overlap. The system had been patched by multiple contractors over time. Retries were not idempotent, and the settlement queue could reorder under sustained load.
We started by reproducing the exact failure in a staging environment wired to the processor's sandbox. That step alone took a week, but without it we would have been guessing. The fix was not a ground-up rewrite. We isolated the hot path, added idempotency keys to every retry, moved settlement processing to a BullMQ-backed queue with Redis, and configured database connection pooling with back-pressure so traffic spikes could not exhaust connections.
Observability was part of the definition of done — latency dashboards, error budget tracking, and structured audit logs that the client's compliance team could actually use. After go-live, failure rates during peak windows dropped sharply. Disputed charges fell as a share of total transaction volume. The next PCI audit passed without blocking findings. The client retained a three-person squad from our team for ongoing changes, which is a typical pattern when Argentina-based engineers own the integration layer between Latin American merchants and US card networks.
More projects: browse our case studies.
How a client engagement actually works
Every engagement starts with a short discovery phase. I want to understand three things before we write a line of code: what business outcome the client needs, what compliance or regulatory constraints exist, and what "done" looks like in production — not in a staging demo. When the project involves payment flows or sensitive data, I join that initial conversation personally.
Most clients see working software within the first two weeks — not a prototype, actual deployable code.
Delivery runs in two-week sprint cycles with visible increments. We use the client's tools whenever possible — their GitHub org, their Slack workspace, their Jira board. The goal is to feel like an extension of the internal team rather than an external vendor you have to manage separately. Daily code reviews, async standups, and a shared definition of done keep everyone aligned without meeting overload.
We offer three engagement models depending on the project: project-based delivery with a fixed scope, staff augmentation where individual engineers join your existing team, or dedicated teams that function as a self-contained unit. Most fintech clients end up with a retained squad after the initial build because ongoing compliance and feature work makes continuity valuable.
I personally review the first sprint plan for every new project. My view: the first two weeks reveal more about a project's real constraints than any amount of pre-sales conversation. Getting that right early is cheaper than course-correcting at sprint eight.
Why we are based in Córdoba, Argentina
I chose Córdoba for practical reasons, not sentimental ones. The city has over 330 technology startups and has climbed from 318th to 226th in global ecosystem rankings over four years. Fourteen universities feed a steady pipeline of engineering graduates. The UTN campus alone produces Information Systems engineers who are competitive in backend, frontend, and mobile roles from day one.
Seven-plus hours of daily overlap with the US East Coast. Same Slack threads, same afternoon standups.
The timezone overlap is the biggest operational advantage. Córdoba is UTC−3 — one hour ahead of New York, two hours ahead of Chicago. That means seven or more hours of shared working time every day. Standups happen in real time. Code reviews don't wait 12 hours for feedback. When a production issue surfaces at 2 PM Eastern, our team is still at their desks.
Cost of living in Córdoba is substantially lower than Buenos Aires or any major US city, which lets us pay engineers well above the local market average while still offering clients rates that are competitive against US domestic hiring. That combination — fair compensation and strong retention — is what makes nearshore delivery work long-term. The cheapest option on paper always costs more in practice when you account for turnover, ramp-up time, and knowledge loss.
What most companies get wrong when hiring a nearshore team
After running hundreds of client conversations over seven years, certain patterns repeat. These are the mistakes I see most often, and honestly, some of them are not obvious until you have been burned.
Optimizing purely for hourly rate. The difference between a $35/hr developer and a $55/hr developer is not $20. It is the gap between someone who needs hand-holding on every ticket and someone who identifies edge cases before you do. I have seen companies spend six months with a cheaper team, throw away the output, and start over with a more experienced one. The total cost always ends up higher.
Treating the nearshore team as a separate entity. If your outsourced developers are not in your Slack, not in your GitHub org, not attending your sprint ceremonies — you do not have a team, you have a ticketing system with people attached. Integration matters more than location.
Skipping the architecture conversation. I have inherited projects where the previous vendor built the first three months of features on an architecture that could not scale past 1,000 concurrent users. A one-hour architecture review at the start would have prevented six months of rework later. We do that review for every new engagement, and it has saved more money than any other single practice.
Not defining "done" in production terms. A feature is not done when the demo works. It is done when it runs in production with monitoring, error handling, and documentation that another engineer can maintain six months from now. If you and your vendor do not share that definition, expect friction at every release.
Frequently asked questions
How big is the engineering team?
Around 30 engineers as of early 2026. We grow in response to signed contracts, not speculative hiring. Most engineers have been with the company for two or more years, which is significantly above the Argentine tech industry average for retention.
What does a typical engagement cost?
Rates depend on seniority and engagement model. A senior full-stack engineer on a staff augmentation contract runs between $45 and $65 per hour. Dedicated team and project-based pricing varies by scope. We do not publish fixed pricing because the right answer genuinely depends on the project — but we are transparent about rates during the first conversation and there are no hidden fees.
Can I start with one developer and scale later?
Yes, and many clients do exactly that. A common pattern is starting with a single senior engineer on staff augmentation, validating the working relationship over two or three months, then expanding to a small dedicated squad. This reduces risk on both sides.
How do you handle intellectual property?
All code produced under contract belongs to the client, full stop. Our standard agreement includes IP assignment clauses and we are happy to sign the client's own NDA or MNDA. The US LLC structure makes this straightforward from a legal perspective.
What if the project does not work out?
We typically operate with 30-day notice periods on staff augmentation and monthly billing milestones on project work. If something is not working after the first month, either side can exit without a long-term lock-in. The code, documentation, and access credentials are transferred to the client in every scenario.
Where to find me online
Get in touch
Have a project in mind or want to discuss your engineering needs? Reach out directly.