You have a web application that needs building, or one that needs work nobody inside the company has the hours to do, and you’ve started looking outside for the people to do it. We read the three pages that rank best for this search while researching this piece, and all three were written by companies that place or sell outsourced developers. Each is a competent version of the same article. One is a six-step hiring process from a staffing firm that spends a full section arguing for Latin American engineers specifically, and another is a design and development agency’s walkthrough of reasons, mistakes, and cost ranges. The third is the most useful of them, a risk-focused piece about trial periods and keeping the repository on your side, published on a talent marketplace and ending at that marketplace’s vetted-talent pitch.

We sell development work too, so we should say that plainly up front. We’re Ecliptic Ideas, a Ruby on Rails consultancy in Coronado, California, founded in 2015, which puts us on the same side of this transaction as the pages we just described. What follows is the part all three of them skip: whether outsourcing is the right structure at all, what the word actually means once you look at the contracts, who ends up holding the code and the accounts, and what the first three months should feel like after somebody signs.

The search phrase assumes the decision is already made, which is fair enough if it is, but it’s worth ten minutes even so, because this is the expensive part to get wrong.

Outsourcing tends to be the right structure when the work has an end you can see from where you’re standing. A first version with a launch date, a framework upgrade that’s two years overdue, an integration with a partner’s API, a prototype that needs to become something real customers can use: all of those have a shape and a finish line. It’s also the right structure when the skill is specialized and you’ll need it rarely. Nobody hires a full-time engineer for the major Rails upgrade that comes around every year or two, and a team that runs those routinely will do yours in a fraction of the time it takes a good generalist learning as they go. Then there’s timing, which people tend to underweight: recruiting a strong senior engineer takes months when it goes well, so if the work needs to start this quarter, hiring isn’t really on the table for it.

Hiring in-house tends to win when the application is the product. In that case the knowledge compounds, because the reasons behind the data model and the scars from the last outage are what make the next decision cheap, and you want that accumulating inside your company. With a project vendor it leaves when the invoices stop, and with a long-running external team it stays with them instead of with you, which is a dependency worth choosing deliberately rather than discovering in year three. In-house also wins when the volume of work is steady and open-ended, because past a certain point employing someone costs less than renting the same hours.

The honest cost on each side is the thing people skip. Outsourcing still leaves you a management job, because somebody on your side has to hold the priorities and answer questions in hours rather than weeks. Hiring carries its own overhead: recruiting and onboarding take real time, the management doesn’t go away, and one engineer can quietly become the only person who understands a critical part of the system. You can also run both, with employees on the parts that are core to the product and an outside team on the parts that are bounded or specialized.

“Outsourcing” covers three structures that look similar in a proposal and behave nothing alike once work starts. The pages competing for this search don’t contrast them: two of them use the vocabulary and move on, and the third never names the shapes at all. Here’s how we’d describe them.

Staff augmentation puts engineers inside your process. They work in your repository and on your ticket board, and their pull requests go through your code review. What you have to supply is work at roughly ticket granularity plus somebody who can size it and review a pull request, and what you get back is capacity for as long as you’re paying for it. It fits when your process already works and you’re short on hands, or when you need one specific skill for a few months. It fails when there’s nobody senior on your side to direct it, because augmented engineers with no lead will do exactly what they were asked and say nothing about the fact that it was the wrong thing to ask for.

A dedicated team is an external team, usually with its own lead, running on your roadmap. You give them priorities at the level of “the billing rework has to land this quarter” and you attend a weekly review, while they run their own standups and their own code review, and what you see is working software on a cadence. It fits when you can describe what matters but can’t manage engineers day to day. Our longest-running engagements have this shape. The Wine Spies runs on a custom Rails e-commerce platform that we build and run for them, so the storefront work, the admin tooling behind it, and the infrastructure that carries their biggest sale days all move through our team against their priorities.

Project or outcome-based work is a scoped deliverable on a fixed price or a milestone schedule. You supply a specification and acceptance criteria, you get the thing, and nearly all of the risk sits in the handoff. It fits when the work can be written down completely in advance and somebody on your side can tell whether what arrived matches what was described. It goes wrong when the specification was really a wish, because everything discovered mid-build becomes a change order, and change orders are where fixed-price engagements turn adversarial.

Which of the three fits you depends on how much management capacity you have to spare. Work that out before you take the first call, because a vendor will happily sell you any of them.

If you’ve read our piece on choosing a Ruby on Rails development company, you’ll notice a different set of three shapes there: project, maintenance retainer, and fractional CTO. That set describes what you’re buying once you’ve already decided to hire a specialist firm, while this one describes the staffing structure before you’ve picked anyone, and it holds whether the work turns out to be Rails, Python, or an iOS app. The two stack cleanly, so a project engagement in that framing is project-based work in this one, and a maintenance retainer is usually a small dedicated team. Once you know you want a specialist, that piece carries the questions worth putting to one, including how to press on upgrade history, test coverage, and who holds production access.

Of the three pages ranking for this search, one mentions IP-assignment clauses briefly, one recommends keeping the repository on the client side, and one doesn’t raise ownership at all. It deserves a list rather than a sentence, because this rarely arrives as a dramatic dispute. It shows up in month fourteen, when you need something and find it sitting in an account you don’t control.

Everything below should be in your company’s name before the first line of code gets written:

• The repository, in your GitHub or GitLab organization, with the vendor invited into it.
• The hosting account. Render, Heroku, AWS, whatever it is, opened under your company and billed to your card, with the vendor holding a team seat.
• The domain and DNS, including the registrar login, which is the most annoying thing on this list to recover once a relationship has lapsed.
• CI and deployment. The pipeline runs in your account, and the deploy credentials are yours to grant and revoke.
• Third-party accounts: payment processor, transactional email, error monitoring, analytics, object storage. Ask for these to be created under your accounts from day one, because migrating a payment processor later is a project of its own.
• Written assignment of the code, covering everyone who touches it, including any subcontractor the vendor brings in. Ask specifically about subcontractors if you’re hiring through an intermediary.
• The operating knowledge: how to bring the app up on a clean laptop, how a deploy happens, where backups go, and whether a restore has ever actually been tested.

How hard any of that is to get depends on which shape you picked. Staff augmentation hands you most of it by construction, since the work happens in your systems, and the one thing left to verify is the assignment language, especially where the engineers are employed by an agency instead of by you. A dedicated team is a negotiation at signing, and you should expect friendly resistance, because a team that has worked together for years has defaults that are cheaper for them and worse for you. Project-based work is the hardest of the three, and the fix is to make the handoff a milestone with a real acceptance test: a named engineer on your side clones the repository, brings the application up locally, and deploys to production from your own account, all before the final payment clears. If a vendor can’t describe how that day would go, it probably hasn’t happened on their previous projects.

Only one of the three pages we read raises AI at all, and only to tell you to ask a vendor how they incorporate AI-assisted development tools. It has changed more than that about what you’re buying.

The old pitch for outsourcing was arithmetic: the same engineer-hour costs less somewhere else, so buy more hours for the same money. Once a model is writing a large share of the code under a developer’s direction, hours purchased becomes a weak proxy for work delivered, and a proposal built on headcount is describing an input you’ve stopped caring about. What you’re paying for is the judgment around the code, meaning who decides what gets built, who reads what the model produced before it merges, what the tests assert, and whether anyone will still understand the system a year from now.

We can only speak for our own shop, so treat this as one data point. AI writes the code here, and senior engineers direct and review every change. We hold client projects at 80 to 90 percent test coverage, because coverage is what shows whether the review process is real.

That changes three things about how you evaluate a vendor. Ask who reviews the code and get a human’s name, and keep pressing if the answer stays vague. Ask for a coverage figure, then ask to see it in CI on an actual pull request, because a number nobody measures is guesswork. And if you run a paid trial before committing, which the risk-focused guide on this search recommends and which we’d second, judge it on the review discipline and the test suite; code volume is cheap to produce now, so it will tell you the least about how the engagement is going to go.

All three pages we read stop at the contract, and the contract is roughly the halfway point. Here’s what the working relationship should look like from your chair.

Ask for a weekly cadence, and ask that the thing you review each week be working software you can click instead of a status deck. Any team can produce a green dashboard, while a URL that does the new thing takes a working team, so if the third weekly review in a row is a slide about progress, start asking harder questions.

Know who you’ll be talking to. Ask before signing which engineer or team lead will be in that weekly call, and whether the same person will still be there in month four. An account manager in the middle is fine as long as they aren’t the only channel, because questions that pass through a translator lose the detail that makes them answerable.

Take read access to the repository on day one, and get something into a staging environment inside the first two weeks even if it’s trivially small. The first deploy is where the unglamorous problems live, in secrets and migrations and build config, and running into them in week two is much easier than running into them in week ten. After that, watch for the ordinary warning signs: demos that are slides, “almost done” repeated across sprints, work you can’t see in a repository, a test suite that never runs.

The last piece is on your side of the table. An outsourced team, in any of the three shapes, still needs one person at your company who holds the priorities and can answer a question or make a call the same day. If the honest answer to who that is turns out to be nobody, that’s a real gap worth naming, and we’ve written about the signs your company needs a fractional CTO for exactly that situation. Part of what a fractional CTO engagement covers is directing the developers, contractors, or agency already in place, including reviewing the quality of what an outside vendor delivers and evaluating the quotes that come in. And if your plan is a single senior contractor instead of a team, understand that availability becomes a single-person question, which we’ve covered in what to check before hiring a Rails consultant.

There are three things worth settling first, and none of them require talking to a vendor.

Write down whether this knowledge needs to live inside your company in three years. If the application is the business, plan for the knowledge to end up in-house eventually, even if an outside team builds the first version. Then decide which of the three shapes you can support, based honestly on who on your side has hours to spend directing engineers. And take the ownership list above into the process as written requirements instead of questions you’ll ask on a call, so any vendor who has a problem with them surfaces early.

If you already know you want a specialist firm for a Rails application, how to choose a Ruby on Rails development company is the next read, and it covers the vetting conversation in detail. If you’re earlier than that and still working out whether custom software is the right answer at all, start with what to know before commissioning a custom web application. Our Ruby on Rails page describes how we run production Rails work, and existing products is the relevant one if there’s already an application that needs taking over. When you want to talk through which shape fits your situation, you can book an intro call.