Nearshore VR development team in Mexico
They kept their team. They added a second track.
Medverse builds 3D training software in Munich and has its own extended reality team. Fyware works in parallel with it, in US Central Time, when their pipeline grows faster than their hours. They report delivering 10 to 20% faster.
- Industry
- Medical training software
- Use case
- Nearshore team extension
Medverse GmbH develops 3D training software for the health sector from Munich, Germany, and it has its own extended reality team. Fyware is not that team and does not replace it: we are the second track that runs in parallel when their project pipeline grows faster than the hours they have. We work in US Central Time, inside their process and against their specification. The product, the intellectual property, the clinical content and the client relationships are theirs, which is the condition that makes the arrangement work at all.
Where each number comes from, and this matters more than the numbers: they are Medverse's figures, which we did not measure, and the baseline is their own team working alone. Their CEO reports delivering projects 10 to 20% faster, a 20% gain in efficiency with no loss of quality, the same 20% in likelihood of delivering on time and on quality, and around 10% lower cost that lands directly on their margin. He also made the priority clear: extending the team without replacing anyone to save money.
If what you need is medical training software, Medverse are the experts and you should talk to them. What this page is about is the other question: how a team gets extended without losing control of the product.
How it works
The bottleneck was development hours
The situation
A company with its own team and a pipeline growing faster than its capacity has three bad options: hire for a peak that may not last, say no to projects, or stretch the team until quality slips. All three cost more than they look.
What Medverse keeps
The product, the roadmap, the clinical criteria, the intellectual property and the client relationships. They decide what correct means, because it is their field and their business. Nothing about that moved.
What we add
A development track that runs at the same time as theirs, in an overlapping time zone, inside their repository and their review cycle. It owns its part of the delivery, with no people to manage.
What the work looks like
Three moments from simulations built inside this arrangement. The scenarios, the protocols and the teaching decisions are Medverse's; what we brought is the development capacity that put them on screen.
What makes it work
Six decisions worth repeating
- In parallel with their team. The gain shows up as speed precisely because nobody was removed from the equation.
- The domain expert is the client. They own what correct means. We are not medical experts and the page says so.
- Overlapping hours beat a lower rate. US Central Time means the question, the review and the fix fit inside one working day.
- One set of tools for both teams. Continuous communication on Slack, tickets and sprints tracked in Jira, and Scrum ceremonies shared with the client's own team. The overlap only pays off if there is somewhere to use it.
- The specification is the deliverable of the client. Their CEO frames the risk correctly: the question to ask is whether the partner was given enough to deliver quality.
- The intellectual property stays put. They own it, and that is why they can publish their own scientific results and why this page cites only what those institutions have published themselves.
This is what we offer as Team as a Service. For the training side of what we do, see Immersive Training.
What this case does not claim, and it is worth saying. Every percentage on this page is Medverse's own figure, reported by their CEO, which Fyware did not measure, and the baseline is their team working without us. We publish them attributed because that is how Simon Nuber asked for them to be used. The learning results cited further down are the researchers', published by them and not measured by Fyware: what this case is about is delivery speed and cost inside a development partnership, and the clinical results of their products belong to them and to the institutions that study them.
Public evidence
What that pipeline produced, published by others
Two projects medverse delivered in this period now have public, third-party documentation. Fyware's share was development capacity to medverse's specification; the clinical content, the study designs and the results belong to medverse and to the researchers. We cite them because they say something a client quote cannot: what was built stands up to academic evaluation.
Interprofessional wound care in VR, at LMU Klinikum
med.ia-versum, a program of the Institute for Medical Education at LMU University Hospital in Munich, trains medicine, nursing and pharmacy students together in two immersive VR scenarios: the complete care process for a grade 2 pressure ulcer, from handover to aftercare, and a structured wound history with an AI-based virtual patient. More than 100 students have worked through it in interprofessional teams of three. medverse is the technology partner named by the project, whose learning design was presented at the GMA annual conference 2025 and is documented on Transferkiosk.
A radiology simulation evaluated with 50 trainees
A study under review at JMIR Medical Education, available as a preprint since April 2026, evaluated an interactive simulation of a contrast-injection procedure with 50 medical technical assistant trainees in Germany. Trainees improved significantly at putting the 12 steps of the procedure in the correct order from pretest to posttest (p < .001), and those who saw the simulation as more useful for their own work gained the most. At medverse's request this page names no product or brand; the preprint carries the study details.
A preprint is an author manuscript that has not completed peer review. The DOI 10.2196/preprints.97489 resolves to the current version.
Nearshoring and offshoring: we run both, and the choice is about how much the work changes
The hourly rate is the easiest number to compare and the least useful one. Extended reality development changes weekly: a scene gets rebuilt, an interaction turns out to feel wrong, a client asks for one more step in the procedure. In that kind of work, what costs the most is the day you lose waiting for an answer. Twelve hours of time difference turn one clarification into two lost days.
That is the whole argument for nearshoring, and it is why the gain in this case shows up as speed. The saving exists, around 10%, and it lands on their margin. But the reason the arrangement is still running is that a question asked in the morning is answered in the morning.
The second reason is less obvious and it is the client's own insight. Extending a team is, above all, an information problem: the partner delivers the quality you enabled them to deliver. Providers who promise results without asking for a specification are promising to guess, and guessing is what makes cheap expensive. The checks that surface that in a first call are in our guide on how to hire a nearshore VR development team.
We are not an outsourcing vendor, and the difference shows on the bad days
Outsourcing is a transaction: you hand over a scope, someone executes it far away, and if the scope was wrong you find out at delivery. We work the other way. We get involved as part of the team, which means we give opinions on how to improve and optimize what we are building, we say when we think an approach will cost more than it should, and we raise the problem while there is still time to fix it. A partner who only executes is easy to manage and useless when the plan is wrong.
It also means being flexible when the client’s own client moves. In this business the surprise almost always comes from outside the code: from an end customer who changes a requirement, a date that moves, a scene that has to exist for a demo next week. Our job in those moments is to absorb the change with you without billing every adjustment as an extra.
The goal is that it feels like we are in the same office, because that is when the work actually gets better: shared tools, continuous conversation, and people who care whether the product wins. Simon Nuber put it in one line when he called Fyware a valued member of our development team. That is the standard we try to meet with every client.
Project details
- Client
- Medverse GmbH · 3D training software for the health sector · Munich, Germany
- Arrangement
- Team extension in parallel with their own extended reality team
- Time zone
- US Central Time
- Fyware's scope
- Development capacity: scenes, interactions and simulation logic, built to their specification
- Clinical content
- Medverse's. Fyware is not a medical expert
- Intellectual property
- Owned by medverse, including visual rights
- Client relationships
- Medverse's. This page cites only what is already public
- Reported effect
- 10 to 20% faster delivery · 20% more efficiency · around 10% lower cost
“I really look forward to every meeting that I have with your team. I believe that you (Fyware) adapt and elevate the quality standard of the partners around you.”
On the risk buyers actually worry about, in Simon Nuber’s words: “It is never a problem of can they deliver the quality. What we ask ourselves is: do we have enough information to enable you to deliver the quality that we are expecting. And that is what a real partnership is about.” His verified review on Clutch covers the relationship as a whole.
Frequently asked questions about nearshoring
Nearshoring or offshoring: which one fits my project?
We run both and we have the methodology in place for both, so the honest answer is that it depends on how much your work changes. Offshoring works well when the scope is stable and well specified: the handover is written once and the team executes. Nearshoring works better when the work changes weekly, as extended reality development usually does, because the review, the question and the fix fit inside the same working day. From Mexico we cover US Central Time for nearshore engagements and run offshore engagements on a written handover cadence. In both models the work runs on the client's own tools: continuous communication on Slack, tickets and sprints in Jira, and shared Scrum ceremonies. What decides the model is how often the work changes.
Is a nearshore team cheaper, or is it about speed?
In this case it was about speed, and the client says so himself. Medverse reports delivering projects 10 to 20% faster after extending their team with Fyware, and about 10% cheaper. Simon Nuber, their CEO, was clear about the priority: extending their team without replacing anyone to save money. Being affordable was a condition; what he was after was speed. If the only thing you need is a lower rate, a marketplace will serve you better than a partner.
How do I know an external team will not lower my quality?
By asking the question the other way around, which is what this client does, in the words of their CEO: it is never a problem of can they deliver the quality, what we ask ourselves is whether we have given them enough information to deliver the quality we expect. Quality in an extended team depends on the specification you hand over, whatever passport the person coding holds. The providers who avoid that conversation are the ones to worry about.
Team extension or staff augmentation: what is the actual difference?
Staff augmentation hands you people to manage. Team extension hands you a team that owns an outcome and plugs into your process, your repository and your review cycle. In this project Fyware worked in parallel with Medverse's own developers, on their product, under their specification, which is why the gain shows up as speed, with no extra people to manage.
What time zone does a Mexican nearshore team work in?
US Central Time. That is the practical reason nearshoring beats offshoring for work that changes: the review, the question and the fix happen inside the same working day.
What do I have to provide so an external team can actually deliver?
The specification, the domain criteria and someone who can answer. In this project the product, the clinical content and the client relationships stayed with medverse, and that is exactly why it worked: they own what is correct, we build to it. A partner who claims not to need any of that is telling you they will guess.
Can a nearshore team work in parallel with my own developers instead of replacing them?
That is the arrangement in this case, and the reason for the numbers. Medverse has its own extended reality team; Fyware is used when the pipeline grows faster than their available hours. Nobody was replaced, and the delivery got faster because two tracks ran at once.
How do I protect my intellectual property and my client relationships?
By contract and by scope, and it is worth being explicit. In this project medverse owns all the intellectual property created, owns the visual rights, and holds the client relationships; Fyware builds to their specification. It is why they can publish their own scientific results and why this page cites only what those institutions have published themselves.
Tom KlukowskiFyware Partner · Valcre Marketing
Want a result like this in your operation?
Fyware has delivered 750+ XR projects for clients like Gerdau Corsa, Cummins and Medverse, from Mexico in US Central Time. Tell us your case and we will tell you what is feasible, how long it takes and what it costs.
We put in the extended reality development team you are missing, in your time zone, on your product and to your specification. Your intellectual property and your clients stay yours.
See Team as a Service See Immersive Training