The five kinds of AI solution providers

There are five kinds of AI solution provider, and the useful comparison is not which is best — none is — but which failure mode you can survive. Platform vendors license you a product. Systems integrators and consultancies implement somebody else's platform inside your organisation. Staffing firms sell engineering hours against a plan you supply. Custom engineering firms take responsibility for building a specific system and handing it over. In-house teams hire the capability and keep it. Each is the right answer to a question the other four answer badly, and each has a characteristic way of going wrong that is visible before anyone signs anything.

We are the fourth, which makes most of what follows a description of our competitors. The test of whether this is worth reading is therefore whether the section on where our own category is the wrong choice is as specific as the sections on everyone else's. It names three situations in which the honest advice is to buy from one of the other four.

One distinction sorts all five, and the clearest statement of it is in the US Government Accountability Office's guidance on contracting for iterative software. Choosing a contract type, it says, turns on "whether the contract is structured for end items (e.g., products such as the number of features completed) or services (e.g., the work performed by a specified quantity of developers)" (US Government Accountability Office, Agile Assessment Guide, GAO-20-590G, September 2020). Platform vendors and custom engineering firms sell end items. Integrators and staffing firms sell services. An in-house team is neither — it is payroll. Most disappointed buyers bought one and believed they were buying the other, and that confusion is easiest to create in AI work, where a good demo makes a service look like a product.

Platform vendors sell a licence, a roadmap and somebody else's problem. The case for them is stronger than the custom-build industry admits: buy when the capability is not what differentiates you, when you want it running this quarter, and when you would rather someone else absorbed model migrations and provider price changes. If a document-classification step is worth real money to you but no customer would ever choose you because of it, buying is not a compromise, it is the correct answer. The failure mode is the last stretch. The eighty per cent the product does arrives in weeks; the twenty per cent specific to you becomes a roadmap request, and your leverage over that roadmap is the size of your contract relative to their other customers. GAO's caution generalises exactly: a programme "should avoid vendor lock-in by making sure deliverables are properly tested and documented so that a new vendor can continue work already begun if necessary", and "the acquisition of any single program should not commit the government to acquiring any future systems." Ask what leaves with you — the prompts, any tuned model, the evaluation data, the embeddings — and put the answer in the contract. Bespoke or off-the-shelf is that decision in full.

Systems integrators and consultancies implement a platform they partner on, and they are right when the hard part is organisational rather than technical: a rollout across many business units, a change programme, a regulator to satisfy, a vendor relationship you do not want to manage, and a requirement that the same thing work the same way in twelve countries. Coordination at that scale is a genuine skill and a small firm cannot supply it. The failure mode follows from the incentive, which is footprint: revenue grows with how much of the platform ends up inside you, so the answer to every new problem is another module. GAO states the sharper version of the risk in language written for federal agencies but describing the commercial case exactly — an organisation should "carefully delineate the responsibilities of the contractor in the solicitation" so that the contractor's work does not "become so extensive or close to the final product as to effectively preempt the government officials' decision-making process, discretion, or authority." Substitute your own executives for the government officials. Ask which decisions stay yours, and write them down while you still have the leverage to.

Staffing and staff-augmentation firms sell hours into a plan you supply, and the plan is the whole thing. This is the right purchase when you already have engineering leadership, a design you believe in, and a known period of being short of hands — and in those conditions it is the cheapest way to add capacity, because you are not paying anyone to think about scope. The category exists because supply is tight. The US Bureau of Labor Statistics projects employment of software developers, quality assurance analysts and testers to "grow 10 percent from 2025 to 2035, much faster than the average for all occupations", from 1,905,400 jobs in 2025, with "about 106,100 openings for software developers, quality assurance analysts, and testers ... projected each year, on average, over the decade" (US Bureau of Labor Statistics, Software Developers, Quality Assurance Analysts, and Testers, Occupational Outlook Handbook).

The failure mode is in GAO's own phrase: you are buying "the work performed by a specified quantity of developers", so the outcome stays yours. If nobody on your side can decide the architecture, define what a correct answer is, or refuse a feature, hours convert into cost rather than software — and AI work punishes that harder than conventional development, because there is no compiler error for an evaluation suite nobody specified. A second, slower failure is worth knowing about, and it was recorded by GSA's 18F from its own experiment with a pre-qualified vendor pool: pre-establishing pools "with large durations without the ability to onboard or off-board vendors" risks "stagnated competition with vendors only competing for larger buys." A preferred-supplier list nobody can leave stops being a market.

Custom engineering firms take responsibility for a working system and hand it over. That is our category, so read this paragraph and the next one together. The case for it is narrow and real: the thing is specific to you, it has to write into systems you already own, what counts as a correct answer is a business judgement rather than a vendor default, and you intend to own and operate the result. Cove's platform consolidation is the recognisable shape — content, device provisioning and subscriptions living in three disconnected systems, folded into one operator experience. Nobody sells that as a product, because the shape of it was theirs.

Three situations make our category the wrong choice, and a fourth makes it merely expensive. If the capability is a common shape and a product already does it, a licence beats a build on both cost and time, and you should not have to rely on our willingness to say so — the test is in when you need an AI development partner, which is the case against hiring us, written by us. If what you need is presence in thirty countries, a follow-the-sun operation, or a supplier large enough to clear a procurement policy written around revenue thresholds, a global integrator is the right answer and a boutique is not; that is a structural constraint, not a failure of nerve. And if you know exactly what to build and have the leadership to direct it, you are buying hours, and a staffing firm sells hours more cheaply than anybody sells an outcome. The merely-expensive case is bench depth: a bench has an edge, so ask what happens when the work needs a capability that is not on it. The criteria for choosing a development partner include the one we publicly fail.

In-house teams are the right answer when the system is the product rather than a support function for it, and when it will still be built on in five years. Nothing else matches the iteration speed, and nothing else keeps the knowledge in the room where the decisions get made. The failure modes are lead time and shape. Against 106,100 annual openings across the occupation, a search for a senior engineer with production AI experience is a two-quarter project before onboarding begins, and the hire has to be made before the work is proven rather than after. The shape is the subtler problem: much of this work is intense for one quarter and then thin forever, which makes a poor job description and an expensive retention problem. In-house AI team vs AI development agency works that arithmetic through.

There is a sixth party that never appears on the comparison chart and sits underneath all five: the model providers. Whichever category you buy from, the intelligence is rented from a small number of foundation-model APIs, and what your choice actually settles is who holds that account, who absorbs a price change, and who re-runs the evaluation suite when a version is retired on a published date. It is also worth knowing how early this market is, because providers in all five categories have an interest in implying otherwise. Stack Overflow's 2025 Developer Survey found 14.1% of respondents using AI agents at work daily, and puts it plainly: "AI agents are not yet mainstream. A majority of developers (52%) either don't use agents or stick to simpler AI tools, and a significant portion (38%) have no plans to adopt them" (Stack Overflow, 2025 Developer Survey: AI). Anyone selling a settled answer in this category is ahead of the evidence, and that is true of us as well.

Four questions place you on the map without any vendor's help. Is the capability differentiating? If no customer would ever choose you because of it, buy a product and spend the saved year on something they would. Can somebody on your side define a correct answer and decide scope? If not, you cannot usefully buy hours at any price. Who operates this in two years, and does that person exist yet? The answer determines what has to be handed over, which is why the handover you must receive is worth reading before the contract rather than after. And are you buying an end item or a quantity of developers? Say which out loud before you read a proposal, because a proposal that is ambiguous about it is usually ambiguous on purpose.

GAO's contracting chapter adds one buyer-side condition that applies to all five categories equally: the arrangements that worked had "an active and engaged product owner", and "having defined roles helps to manage expectations of stakeholders and empowers the product owner." No category substitutes for that person. A platform vendor without one sells you modules nobody switches on; an integrator without one quietly acquires the decisions; a staffing firm without one bills accurately for the wrong thing; a custom build without one produces a system that works and is not used; and an in-house team without one becomes a research group. If you cannot name the product owner, that is the first thing to fix, and it is not a purchase.

The category does not predict quality — there are excellent and negligent firms in all five. What it predicts is the shape of the failure when there is one: a platform fails at the edges, an integrator fails by absorbing decisions that should have stayed yours, hours fail in the absence of a plan, a custom build fails at the operate phase, and an in-house team fails on lead time. Choose the failure you can survive, then staff against it. If the answer is the fourth category, our AI development services page maps what that work involves and our first engagement is deliberately a decision rather than a build: a two-week AI readiness assessment whose roadmap is yours whether or not you build with us, sold as a fixed deliverable like everything else on pricing.