AI and Machine Learning Development Services

AI development is when engineers build machine learning and language model features into a product and take responsibility for how they behave once real users arrive. CodigoDelSur has been building software from Montevideo, Uruguay since 2007, for companies in the United States and the rest of the world. We have trained computer vision models on our clients' own data and built language model features grounded in their own content.

It is the right model when you have a product and a problem you believe a model can take over, and you need someone who will tell you honestly whether your data supports it. It is the wrong model when what you want is a strategy deck. We tell you which one you are on the first call.

LET’S DISCUSS YOUR BUSINESS NEEDS TODAY

Is an AI project the right thing for you right now?

Yes, if:

You have a product in production and a specific decision or task you want a model to take over.
You already hold data, even messy data: images, video, transcripts, records, a content archive.
You can say what "working" would look like, and you would notice if it stopped working.

No, if:

You want AI in the product because a competitor announced it. That is a positioning problem and we are the wrong supplier for it.
The data does not exist yet and nobody is collecting it. Start there and come back when there is something to train on.
You need the model to be right every time. Nothing built on a model is, and a product that cannot absorb a wrong answer should not have one in it.

How it works, from first call to a model in production

Five steps, and the first two exist to tell you whether there is a project here at all. We do not sell an AI strategy deck: every one of them ends in running software or in a written reason not to keep going.

Intro call, 30 to 45 minutes. We ask four things: what you want the model to decide, what data you already hold, where it lives, and who would notice if the model got it wrong. There is no deck. If your problem is not an AI problem, this is where we say so.

Data and feasibility review, one sprint. We look at volume, labeling, quality and access. You get a written answer on whether the problem is solvable with the data you have today, what would have to change if it is not, and which approach we would take. If the honest answer is that the data is not there yet, you get that in week two rather than in month six.

A narrow working version. The smallest thing that produces a real output on your real data, not a demo on a public dataset. This is where an approach is validated or discarded, and discarding it at this stage costs almost nothing.

Production engineering. The part that is usually underestimated: inference cost at your volume, latency, what the product does when the model is unsure or the API is down, monitoring, and how the feature degrades instead of breaking. Our AI engineers sit inside the same team that maintains the rest of your application, because this is exactly where those two jobs meet.

Iteration against real usage, and handover. Once real users arrive the numbers change, so we keep measuring and retraining or re-prompting against what actually happens rather than what the test set said. Everything we build is yours, including any model we train and the data behind it, and we document it so your team can take it over whenever you want.

How long it actually takes to start

Every nearshore company promises a team "in days". Here is the breakdown behind that promise, so you can compare it to the one you got from someone else.

Stage	Typical time
Intro call to written role brief	1 business day
Role brief to first profiles, if the profile is on our bench	1 business day
Role brief to first profiles, if we have to recruit	5 business days
Interviews	Your calendar, usually within a week
Signed agreement to the engineer's first day	5 business days as standard, or as soon as the next business day if the engineer is on our bench and you are ready
First day to a written feasibility answer	One sprint, two weeks

The number that matters is the second row against the third. Anyone moves fast when the person is already on the bench. What tells you who you are dealing with is whether they admit which of the two you are in, before you have signed anything.

What we build, and what we have used in production

Two kinds of AI systems, and in almost every case the work goes into a product that already exists and already has users, which is a different job from building a demo from nothing. We name the technique rather than the category, because the category is the part anyone can claim.

Capability	What we build	Technique used in production	Where it shipped
Computer vision	Object detection and classification on camera and sensor data, including the labeling and retraining pipeline	YOLO detection models, Roboflow labeling and training pipeline, Python, real-time on-device processing in Swift and MetalKit	Milc Group, Sparrow
Language model features and RAG	Assistants and search grounded in the client's own content archive, and generation constrained to a closed set of inputs	GPT-4, Ollama for local model serving, retrieval-augmented generation over the client's own corpus	Visit Philly, and Cookmate.AI, a product of our own

Two capabilities and not eight. We list what we have shipped, which is why the list is short.

What it costs and how billing works

The minimum project size is $10,000, roughly one engineer for one month, and the minimum term is two weeks, one sprint. There is no recruiting fee, and the assigned project manager is included at no additional cost. Billing is per sprint, Net 14, monthly if your finance team prefers, with volume discounts of 5% from five people and 10% from seven.

We do not quote an AI project without a real scope, because an estimate given before anyone has looked at the data is a guess with a currency symbol in front of it. That is what the feasibility sprint is for: it is small, it is priced like any other sprint, and it ends with a written answer you can take elsewhere. What an engineer costs depends on role, seniority and technology, and it comes in writing together with the scope.

The projects behind this page

Every project named here is one where our own engineers built or integrated the AI. Projects where the client owned the model and we built the application around it are left out, even when the product is known for its AI, because claiming a client's capability as your own is the one claim a buyer can check in a single phone call. A project appears only if our engineers wrote, trained or integrated the model or the pipeline, the work reached production or a deliverable the client accepted, and it is verifiable from outside.

Three client projects meet that: Milc Group, Sparrow and Visit Philly. Ten projects our own record had tagged as AI did not survive the review, most of them because the AI belonged to the client. We publish the exclusions because the number means more once you know what it excludes.

Milc Group is a dairy management platform. We built MIRA, its AI assistant, with YOLO for the detection models and Roboflow for the labeling and training pipeline. The hard part was never the model: MIRA had to fit a platform that dairy operations run on every day, so the retraining loop, the behavior when the model is unsure and the cost of inference at the volume of a working farm were all designed before anything shipped. It is our largest engagement.

Sparrow analyzes a golf swing as it happens. Latency is the whole product: the analysis runs on the phone itself, in Swift and SwiftUI with MetalKit handling the frames, because a swing coach that answers thirty seconds later is not a swing coach.

Visit Philly is the destination marketing organization for Philadelphia, with a large published archive. We built a language model layer over it using GPT-4, Ollama for local model serving, and a retrieval-augmented generation pipeline that controls which of their content an answer may draw from. A model that invents a restaurant is worse than one that says it does not know, so the work was retrieval design and grounding, not prompt writing.

And one of our own. Cookmate.AI is ours, shipped to the App Store with CodigoDelSur as the seller. It generates recipes from the ingredients you actually have and the diet you follow. We count it separately from the three above, and we mention it because everything else here is something we are describing to you, while this one you can download and judge in a minute.

Staff augmentation, dedicated team or full-cycle product development

Three different products get sold under the same word, "outsourcing". They are not interchangeable and picking the wrong one is the most expensive mistake in this category. AI work can be delivered through any of the three.

	Staff augmentation	Dedicated team	Full-cycle product development
Who owns the roadmap	You	You	Shared, we run discovery
Who manages day to day	Your engineering manager	You, with a CodigoDelSur project manager coordinating on our side at no extra cost	Our project manager
What you get	Individual engineers inside your team	A team shaped around your product, staffed and coordinated by us	A product, from discovery to store release
You need to have	Technical leadership with spare capacity	A product owner and a clear roadmap	A budget and a problem worth solving
Who owns the model and the data	You, always	You, always	You, always
Typical size	1 to 4 people	4 to 12 people	Scoped per project
Minimum commitment	Two weeks, one sprint	Two weeks, one sprint	Quoted per project
Best when	The work is defined and you are short on hands	You own a product area and want it staffed and coordinated as one team	You need the thing to exist and you do not have an engineering org

When this page is not your answer

Do not start an AI project if the data is not there, or if nobody on your side can say what a good answer looks like. The expensive version of the first mistake is a six month build ending in a model that performs slightly worse than a rule someone could have written by hand, and it is usually visible in week two if anyone looks. The second is worse, because a model has to be measured against something: if no one can define what "right" means for your case, no amount of engineering fixes it. That is why the feasibility sprint exists, and why we would rather lose a project there than in month six.

Where "taking over an existing project" and "short-term work" fit

Neither of those is a fourth model. They are situations, handled inside the models above. If you already have an application with an AI feature and want to switch providers, we review the existing codebase and the existing model and work on top of them, either with engineers embedded in your team or with a dedicated team taking the product over. If the work is short, the two week minimum means you can run a feasibility sprint as a single engagement and stop there.

Frequently asked questions

Do you build models from scratch or integrate existing ones?

Both, and the choice is a cost decision rather than an ideological one. For Milc Group we trained computer vision detection models with YOLO and Roboflow because no off-the-shelf model could read that specific dairy operation. For Visit Philly we integrated an existing foundation model and put the engineering into retrieval and grounding, because training from scratch would have cost more and answered worse. We start from the cheapest approach that solves the problem.

Can you add AI to a product we already have in production?

Yes, and that is most of what we do. Milc Group and Visit Philly were both existing products when the AI work started, and Milc had operations depending on it daily. The hard part is never the model, it is fitting the feature into a system that cannot go down: the retraining loop, what happens when the model is unsure, the cost of inference at real volume, and how the product behaves when the AI is unavailable. That is why our AI engineers sit inside the same team that maintains the rest of the application instead of handing over a model and leaving.

How many AI projects have you actually delivered?

Three client projects that meet our own criteria: Milc Group, Sparrow and Visit Philly. We reviewed every project in our delivery record since 2007 and counted only those where our engineers built or integrated the AI themselves and the work reached production or an accepted deliverable. Ten projects our record had tagged as AI did not survive that review, either because the AI belonged to the client or because the label was wrong in our own record. We also ship AI in products of our own, counted separately: Cookmate.AI is on the App Store with CodigoDelSur as the seller, so it is the one you can download and judge without taking our word for anything.

What time zone do your engineers work in, and how much overlap will I get?

Our engineers work 10:00 to 19:00 Uruguay time, which is UTC minus 3. That covers the entire US East Coast working day, five to six hours of live overlap with the West Coast, and three to four hours with the United Kingdom, in their afternoon. The schedule is set that way deliberately: shifting the day an hour later widens the Pacific overlap without asking anyone to work nights, and it is the reason this arrangement is still working in month twelve rather than quietly falling apart in month three.

How fast can you actually start?

Five business days from signed agreement to first day is the standard, and if the engineer is already on our bench and your side is ready, they can start as soon as the next business day. What varies is finding the right person, not starting them: if the profile is on our bench you get CVs one business day after you sign off the role brief, and if the role has to be recruited, first CVs take about five business days. We tell you which of the two you are in on the first call.

What happens if the engineer is not working out?

You tell your account manager and we replace the person at our cost. There is no charge for the search and no penalty for asking. The outgoing and incoming engineers overlap for ten business days, and we do not bill those days, so that context, access and work in progress transfer between them instead of landing on your team.

Who owns the model, the weights and the training data?

You do, in every engagement model, including models we train on your data. We retain no rights to anything we build for you and we do not reuse one client's data or models on another client's project. Ask every supplier this in writing: it is the question where the answers differ most.

Do you work alongside our data science team or replace it?

Either. When there is an in-house data science team, our engineers usually take the production engineering that data scientists tend not to want: inference cost, latency, failure behavior when the model is wrong, monitoring and deployment. When there is no team we run the whole thing, and the most senior developer makes the technical calls. We do not bill a separate tech lead unless you ask for the role.

Tell us what you want the model to do

Tell us what you want the model to decide and what data you already hold. In one sprint you get a written answer on whether it is solvable with what you have and what we would build, and you can take that answer elsewhere if you want to. CodigoDelSur has been building software since 2007, from Montevideo, Uruguay, for companies in the United States and the rest of the world.

FIND OUT MORE ABOUT DEDICATED TEAMS