Comparison
Build vs buy vs forward-deployed engineering
Buy a SaaS product when the workflow is standard and lives mostly in one system; build in-house when you have the engineers to build, run and change it and want to own it. A forward-deployed team fits the case in between: a workflow specific to your documents, rules and systems, with real volume and nobody in house to build and run it.
The options at a glance
| Option | Fits when | Watch for |
|---|---|---|
| Build in-house (your engineers build and run it) | The workflow is core to how you compete, you have engineers with machine learning and integration experience who can stay on it for the long run, and you want to own the code and the roadmap. | Time to production depends on hiring and on competing priorities. Every new document format, model change and system upgrade lands on your team, and the exceptions need an owner after the project team moves on. |
| Buy a SaaS product (a vendor's product, configured by your team) | The workflow is standard, stable and lives mostly in one system, and a product already does it the way your process works. You want a quick start and a predictable budget. | Your process adapts to the product, not the reverse. Documents, rules and systems outside its scope stay manual or need integration work, and the exceptions it cannot handle come back to your team. |
| Forward-deployed team (an outside team builds and runs it inside your environment) | The workflow is specific to your documents, rules and several systems, the volume of documents or exceptions is real, and you do not have the engineers to build and run it yourself. | Changes go through an outside team. Scoping takes time from your people up front. Not justified for a standard workflow a product already covers, or for low volume. |
| Keep it manual | Volume is low, the work is occasional, or the process is still changing too fast to automate. A general-purpose assistant can help the person who does it. | It does not grow with volume, and the knowledge of how the work is done stays with the people who do it. |
Executive Summary
Most decisions about automating an operational workflow with AI are framed as build versus buy. Building gives you a system made for your workflow and owned by your team, if you have the team. Buying gives you a product that works quickly, if your workflow looks like the one it was designed for.
Operational workflows often fit neither. The documents arrive in every format, the rules live in your master data and in people's habits, the work spans a mailbox, an ERP, a TMS or estimating software, and the exceptions are where the time goes. A product does not cover the specific part, and an in-house team may not exist or may be committed elsewhere.
A third option exists for that case: an outside engineering team that builds the system inside your environment, around your workflow, and keeps running it with you. It is called forward-deployed engineering, and it is what Mirage does. It is not the right answer for every workflow, and this page says when it is not.
Key Takeaways
- Buy when the workflow is standard, stable and mostly inside one system, and a product already does it.
- Build when the workflow is core, and you have engineers to build, run and change it for years.
- A forward-deployed team fits a specific, multi-system workflow with real volume and no in-house team to build it.
- The deciding questions are about the workflow, not the technology: how specific it is, how many systems, who owns the exceptions, how often it changes.
- Whichever option you choose, someone has to own the exceptions and the changes after go-live.
- Mirage is not the right choice for a standard single-system workflow, for a team that wants to own the system, or for low-volume work.
Six questions that decide it
How specific is the workflow?
If many companies run it the same way and a product already does it, buy. If it depends on your own document formats, customer rules, rate tables or drawing conventions, a product will cover the common part and leave the specific part to your team. Specific and core to your business points to building; specific and not where you want to spend engineering time points to a forward-deployed team.
How many systems does it touch?
One system, with a product designed around it: buy. Several (a mailbox, an ERP, a TMS, an estimating tool, a shared drive) with writes into more than one, and the integration work becomes the project. Your own engineers can do it if they know those systems; a forward-deployed team does it as part of the deployment. Mirage has connected more than 200 systems so far, writing back into them.
Do you have engineers who can build and run it?
Building needs people who can work with language models, document parsing and integrations, and who stay on the system after launch. If that team exists and has the time, building keeps the knowledge in house. If it does not, building starts with hiring, and the timeline follows the hiring.
Who owns the exceptions?
Every operational workflow has cases that do not fit: an unknown product code, a rate outside the agreement, a quantity that does not match the drawing. With a product, they come back to your team in whatever form the product gives them. In house, your engineers design how they are routed. With a forward-deployed team, the routing is mapped with your team before the build, and a person on your side signs off on each one.
How soon does it need to be in production?
A product configured for a standard workflow is usually the quickest start. An in-house build depends on staffing and priorities. Mirage runs a proof of concept on your own documents one week after the first meeting and puts the first workflow in production in 4 to 6 weeks; workflows that span several systems can take longer and are scoped at the first meeting.
How often will it change?
Formats change when a supplier changes its template, rules change with each contract, and systems get upgraded. A product changes on its vendor's roadmap. An in-house system changes when your team has time. A forward-deployed team changes it as part of running it: at Mirage, the engineers who build a system stay engaged once it is running.
Build and buy: advantages and limits
Build in-house
Advantages
- Built exactly around your workflow and your systems
- You own the code, the data pipeline and the roadmap
- The knowledge of how it works stays in house
- No outside party between you and a change
Limitations
- Needs engineers with language model, document and integration skills, kept on the system after launch
- Time to production depends on hiring and competing priorities
- Maintenance, monitoring and exception handling are permanent work, not a project
- The team that built it has to stay to run it
Buy a SaaS product
Advantages
- The quickest start for a standard workflow
- The vendor maintains the product and improves it for every customer
- A subscription to budget, and no engineering team to staff
- Already in use at other companies with the same process
Limitations
- Your process adapts to the product, not the reverse
- Covers the documents, rules and systems it was designed for; the rest stays manual
- Integration with your other systems may be left to you
- Exceptions outside its scope come back to your team
Five workflows, five answers
A standard workflow inside one system
Example: supplier invoices in a common layout, posted into one accounting system, with a product built for exactly that. Buy it. Neither an in-house build nor a forward-deployed team will do better than a mature product on its own ground.
A pricing or forecasting model that is your edge
Example: a model at the heart of how you compete, with a data and engineering team that already runs production systems. Build it, and keep the knowledge in house.
Customer orders by email into the ERP
Forward-deployed. Biodéal's customers order by email in every format: PDFs, scanned forms, spreadsheets, free text. Mirage's agent applies Biodéal's own business rules and creates each order in SAP Business One, with a median of 48 seconds from the email arriving to the order being ready, and about 7% of orders flagged for a human check.
Takeoff on an engineering group's drawings
Forward-deployed. At John Cockerill, three engineering modules run on one platform (piping, boilermaking, structural steel) with separate MTO and BOM outputs, and piping takeoff takes 80 to 90% less time, with engineers reviewing the output.
Low-volume or occasional work
Keep it manual. A handful of documents a week, or a process still being redesigned, does not justify a build, a product or a deployment. A general-purpose assistant can help the person who does it until the volume or the process settles.
Why a third option exists
Build versus buy assumes the choice is between your engineers and a vendor's product. In operational AI the hard part is often neither the model nor the product, but fitting a system to a workflow that exists only in your documents, your systems and your people's habits, and keeping it fitted as they change.
That work needs engineers on site, which a product vendor does not provide and many operations teams do not employ. A forward-deployed team supplies them, builds inside your environment and stays on the system once it runs.
It is a narrower answer than it sounds. It fits workflows that are specific, span several systems and carry real volume. For the rest, building or buying is the better call.
Forward deployment: advantages and limits
An outside engineering team builds the system inside your environment, around your workflow, and runs it with you once it is live. At Mirage the method has five steps, always in this order. Observe: engineers spend time with the operational team before writing anything. Map: workflows, exceptions, data sources, manual checks and escalation points are mapped with the team. Build: the system is built around the constraints observed on site. Run: it runs in production with human supervision and feedback loops from day one. Expand: once a workflow is trusted, the same team moves to the next one.
- Fitted to the workflow. Built around your documents, rules and systems, including the specific parts a product does not cover.
- No team to staff. The engineers come with the engagement; your people give time to mapping the work and reviewing exceptions, not to building.
- Write-back included. The integration into your ERP, TMS or estimating software is part of the deployment.
- Run, not handed over. The engineers who build the system stay on it in production and change it when formats or systems change.
- A staged commitment. A proof of concept on your own documents one week after the first meeting, then a fixed-price pilot on site that you can stop after, then an annual subscription priced by volume.
- Limit: dependence on an outside team. Changes go through that team. Settle who owns the code, the data and the configuration in the contract before you start.
- Limit: your time up front. Observing and mapping the workflow takes hours from the people who do the work today.
- Limit: not for every workflow. For a standard workflow that a product already covers, a deployment is more than the job needs.
When Mirage is not the right choice
Said plainly, so a first meeting is not spent finding out.
- A standard, stable workflow in one system. If a product already does it the way you work, buy the product.
- A team that wants to own the system. If you have in-house engineers with machine learning and integration experience, and owning the code and the roadmap matters to you, build it. Mirage does not sell self-serve software or a login for your team to configure.
- No document or exception volume. If a few documents a week arrive and exceptions are rare, the work does not justify a deployment.
- A need Mirage does not cover. Mirage does not check drawings against US building codes (IBC, IRC, NEC, IPC), and does not maintain a material catalogue or a labour-unit database: it feeds the client's own.
How a Mirage engagement runs
A first meeting to scope the workflow. A proof of concept on your own documents one week later. A fixed-price pilot on site, which you can stop after. Then an annual subscription priced by volume. There is no public price list.
The first workflow is in production in 4 to 6 weeks. Workflows that span several systems can take longer and are scoped at the first meeting. Mirage has more than 35 deployments in production, for more than 30 clients in six countries.
Further reading
The role behind this model, explained. See what a forward-deployed engineer is
Deployments at Biodéal, OFRET Groupe, John Cockerill, Transwin and others, with their published results. See the case studies
FAQ
Related Comparisons
Why not just use ChatGPT?
What a general-purpose assistant does well, and what a workflow needs around the model: write-back, validation, exception routing, audit.
Read the comparisonAI Agents vs RPA
Why a fixed script breaks on varied documents and exceptions, and where it is still the right tool.
Read the comparisonOCR vs LLM
How character recognition and large language models differ in document automation workflows.
Read the comparisonForward deployment at Mirage
Forward-deployed engineering
Engineers observe how the work is done, map its exceptions with your team, build the system around them and run it in production with you, then move to the next workflow once the first is trusted.
See how forward deployment worksGet a custom automation plan
Tell us where your operations lose time. We send back a written plan: which workflows are worth automating, what a deployment looks like on your systems, and the shortest path to production. No commitment.
Prefer to talk it through? Book a call