Decision matrix
Who should build it: weigh it for your project
We are one of the four options here, so we rated our own model by the same criteria, weak spots included. At these default weights it does not come out on top.
1 · Set what matters to you
2 · Where your weights lean
- In-house teamGood fit
- FreelancerPartial fit
- AI agencyStrong fit
- Founder-led studioGood fit
Close call between AI agency and In-house team. When the matrix is this close, the discovery questions below decide it, not the scores.
3 · The matrix, cell by cell
| Criterion · your weight | In-house team | Freelancer | AI agency | Founder-led studio |
|---|---|---|---|---|
| Long-term ownership after launchWeight: Medium | Strong fit Strongest: the people who built it stay and run it. | Partial fit Ends when the contract ends unless you arrange ongoing support. | Good fit Support contracts keep it running; continuity depends on staff turnover. | Good fit Monthly support from the same builder; continuity rests on one small firm. |
| Speed to a first working versionWeight: Medium | Partial fit Slowest start: hiring for AI roles can take months before any build begins. | Strong fit Can often start within days. | Good fit Starts after contracting and staffing, often a few weeks in. | Good fit Starts once scope is agreed, with no team to assemble. |
| Breadth of skillsWeight: Medium | Good fit Depends on who you hire; a full system needs several distinct skills. | Partial fit One person’s skills; gaps in evaluation, security or integration are common. | Strong fit Strongest: several specialists across retrieval, integration, design and QA. | Good fit Broad engineering in one person; specialist gaps are filled by your team or specialists you bring in. |
| Several workstreams at onceWeight: Low | Good fit Grows with headcount and budget. | Poor fit One pair of hands. | Strong fit Can run several workstreams at once. | Partial fit One workstream at a time, by design. |
| Cost you can predictWeight: Medium | Good fit Salaries are predictable; recruiting, tooling and management time are not. | Partial fit Often hourly or daily rates, so scope creep lands on your budget. | Good fit Fixed bids or time and materials; change requests add up. | Good fit Often a fixed price per phase; check how changes are quoted. |
| Knowledge stays in your organisationWeight: Medium | Strong fit Strongest: decisions and context live in your own team. | Partial fit Lives with the freelancer unless documentation is part of the deal. | Good fit Depends on the documentation and handover written into the contract. | Good fit Kept with you through your own accounts, documentation and a handover session. |
| A second pair of eyes on the workWeight: Medium | Good fit Peer review is natural once there are at least two engineers. | Poor fit No second reviewer unless you provide one. | Strong fit Internal review and QA are usually part of the process. | Partial fit One builder, so review comes from tests, your team and staged sign-off. |
| Resilience if a key person leavesWeight: Medium | Good fit Spread across a team, though a small team still has gaps when someone leaves. | Poor fit Highest risk: illness, a new client or a move ends the work. | Strong fit Lowest risk: the work survives individual departures. | Partial fit A real key-person risk. Your accounts and documentation reduce it but do not remove it. |
| Direct access to the person buildingWeight: Low | Strong fit Your own staff, in your own meetings. | Strong fit Direct, usually. | Partial fit Often through an account or project manager. | Strong fit The founder scopes, builds and supports the work directly. |
Ratings describe typical arrangements in each category, not any named firm or person. Our own model is rated by the same rules; challenge any rating that does not match what you see.
Four ways to get an AI system built
An in-house team means hiring engineers who build the system and then run it. A freelancer is one independent specialist contracted for a defined piece of work. An AI agency is a firm with several people and roles, from project management to quality assurance, that staffs your project from its bench. A founder-led studio is a small firm where the founder scopes, builds and supports each engagement personally.
Disclosure: MiniAI Labs is a founder-led studio, so we are one of the options on this page. We have rated our own model as plainly as the others, including its weak spots: one builder, one workstream at a time and a key-person risk.
The criteria that decide it
Who owns it after launch
An AI system is not finished at launch. Content changes, models are updated or retired, integrations break when another system changes, and someone has to re-run the tests. Decide who will be accountable for that before you decide who builds it. If the answer is your own team, involve them from the first week, whoever does the build.
The skills a production system needs
Model work is the smallest part. A production assistant or automation also needs data preparation, retrieval design, integration with your systems through their APIs, evaluation with a test set, security and privacy design, a usable interface and monitoring after launch. Few individuals are strong at all of these, which is why breadth matters more than any one specialism.
Capacity and review
One person can only run one stream of work at a time, and nobody reviews their own work as well as a colleague does. Agencies and teams have both covered by default. A freelancer or studio covers review through automated tests, staged sign-off with your team and, where it matters, an independent reviewer you appoint.
Key-person risk
If one person holds the knowledge, their absence stalls the system. You cannot contract that risk away, but you can shrink it: keep every account, repository and credential in your organisation’s name, require a runbook and architecture notes, and make sure someone on your side has walked through a change end to end. The NIST AI Risk Management Framework makes the same point at organisational level: document roles and responsibilities, and have contingency processes for failures in third-party systems.
How cost behaves
Hourly and daily billing puts the risk of scope creep on you. Fixed bids put it on the builder, who prices it in. In-house salaries look predictable but carry recruiting, tooling and management time, and the cost continues between projects. Compare the total for the whole life of the system, not the first invoice.
Ownership: get it in writing, whoever you hire
- Model, cloud, telephony and messaging accounts are opened in your organisation’s name from day one, with the builder given scoped access.
- The contract states who owns code, prompts, workflows, configurations and data once you have paid, and when that transfer happens.
- Documentation is a deliverable: architecture notes, a runbook, the test set and how to run it.
- Ending the engagement has a written process, including credential rotation and a handover session.
Do not assume that paying for work transfers its ownership; in many places it does not without a written assignment. Take legal advice on the agreement you sign.
Combinations that work
| Combination | How it works | Fits when |
|---|---|---|
| In-house lead, outside build | Your engineer owns the design and reviews; an outside builder delivers the first version | You want to own the system but need it sooner than you can hire |
| Agency build, in-house run | The agency builds and hands over; your team runs it with a support contract as backup | You have operators but not builders |
| Freelancer for a bounded spike | One specialist answers one question, such as retrieval quality on your documents | The task is small, testable and has a clear end |
| Studio build, in-house run | The studio builds on your accounts and trains your team during handover | One focused system, and you want direct access to the builder |
The questions we ask in discovery
- Who in your organisation will own this system a year from now?
- Is AI part of the product you sell, or a tool that supports the business?
- How many separate systems do you want built, and do they need to progress at the same time?
- Which of the needed skills does your team already have?
- What would happen to your operations if the system stopped for a week?
- Do your procurement rules set any requirements on vendor size, insurance or certification?
- Who on your side can review and sign off each stage?
How to decide
- Describe the system and how long you expect to run it. Long-lived and core points towards a team; focused and supporting points outwards.
- List the skills it needs and mark which you have. The gaps are what you are buying.
- Rule out options on hard constraints: parallel work, procurement rules, key-person tolerance.
- Ask each remaining candidate for a written scope with price, timeline, what you will own and how changes are priced.
- Whoever you choose, keep the accounts in your name and the documentation as a deliverable.
When MiniAI Labs is the wrong choice
If the plan calls for several builds at once, each with its own people, an agency with a bench or a team of your own will move faster than one builder.
If your goal is long-term AI capability inside the company, invest in hiring. Outside help should be a bridge, not the plan; we can build the first system and train the team that takes it over, but we cannot be that team.
If your risk policy cannot accept a single key person for this system, a founder-led studio is the wrong vendor, however carefully the contract is written.
Limits of this comparison
- Ratings describe typical arrangements in each category, not any named firm or person.
- MiniAI Labs is one of the options compared; we rated our own model by the same criteria, and you should test that claim.
- Hiring timelines and rates vary widely by market, so this page gives no numbers for them.
- Ownership law differs by country; nothing here is legal advice.
Sources
- AI RMF Core (NIST AI Risk Management Framework 1.0) (opens in a new tab) · NIST Trustworthy and Responsible AI Resource Center · accessed