Important takeaways.
- Buying is fast and shallow. It fits workflows that are genuinely standard across funds, and it costs you configuration work everywhere your process is not the market average.
- Building is deep and slow. It fits workflows that carry real edge, and it fails on staffing rather than on engineering.
- Embedding is a delivery model, not a third technology category. A partner can embed a product, a custom build or a hybrid, but the contract must make operational ownership, change responsibility and exit rights explicit.
- The deciding question is which context is standard and which is fund-specific. A vendor can supply repeatable infrastructure, but the fund's people and records must supply the context that makes a proprietary workflow work.
- Apply the month-nine test. Ask what the system looks like once the champion has moved on, the model has changed and the workflow has shifted. Most routes fail that question before they fail on cost.
Build, buy or embed is usually presented as a three-way choice. It is more useful to separate two decisions. Buy or build describes what the fund deploys. Embed describes how that product or custom system is implemented.
A fund can buy software and embed the vendor's team during implementation. It can build a custom workflow with an embedded partner. It can also combine a repeatable platform with fund-specific agents and integrations. That hybrid is often the practical answer because commodity infrastructure and proprietary workflow context should not be treated as the same thing.
Buying: fast, bounded and right for standard work.
A vendor product is the right answer when the workflow is genuinely standard across funds. General assistants, meeting capture and common document-processing tasks rarely justify rebuilding basic infrastructure.
The cost shape is usually a licence, implementation work and an ongoing support relationship. The more important risks sit elsewhere.
- Configuration debt. Every place the fund's process differs from the product's assumed process becomes a configuration, integration or workaround to maintain.
- Roadmap dependence. The product changes according to the vendor's priorities. That is acceptable for commodity work and less comfortable where the workflow carries the fund's edge.
- Data and exit terms. The fund needs to know where its data sits, what the provider may do with it, what can be exported and what remains available when the relationship ends.
Buy where the work is repeatable across the market and the provider's security, integration and commercial terms fit the fund. A product other funds can buy can still create operational value; it simply should not be mistaken for differentiation by itself.
Building: specific, controllable and easy to under-resource.
Building makes sense when the workflow carries real edge, the context that makes it work is specific to the fund, and no product can represent it without extensive workarounds. A custom system can follow the fund's process, connect its history and evolve on its timetable.
The first version is not the full decision. The fund also takes responsibility for testing, security, monitoring, model changes, source-system changes and user support.
- Single-owner risk. One capable person can produce a useful system that becomes fragile when that person changes role or leaves.
- Maintenance risk. Models, APIs and document formats change. An unmaintained workflow does not remain fixed; its behaviour and dependencies drift.
- Portfolio risk. The first workflow has a champion. A growing set of custom workflows needs shared infrastructure and an explicit operating model, or each becomes its own small system.
Build where the workflow justifies that continuing responsibility. If the fund cannot name who will own the system after launch and fund the maintenance, it has not chosen a complete build model.
Embedding: a delivery model, not a third technology.
An embedded partner works closely with the fund's team and systems to implement, configure or build a workflow. That can shorten the path from institutional context to a working system, but embedding does not automatically transfer source code, intellectual property or the ability to operate everything without the partner. Those are separate commercial and operating decisions.
What to settle before the work starts:
- People and decisions. Name the fund owner, the partner owner and the people who approve workflow changes, access and outputs.
- Data and controls. Specify where data is processed, how permissions work, what is logged and how the fund retrieves or deletes its information.
- Intellectual property and exit rights. State who owns each component, which licences continue after termination, what can be exported and what transition assistance is available.
- Change responsibility. Document who updates prompts, evaluations, integrations and models, and how changes are tested before release.
- Operational documentation. Write for the people who will run and govern the workflow, whether they sit inside the fund or with the partner.
The objective is continuity, not a ritual handover. Some funds will sensibly retain a managed service; others will bring more operation in house. Either can survive if the responsibility and exit position are explicit.
The strongest answer is often hybrid.
The deciding question is: which parts are standard infrastructure, and which parts contain the fund's context?
Identity, permissions, model access, logging and common document handling are repeatable platform concerns. The fund's credit policy, templates, covenant conventions, portfolio history and approval steps are specific. Buying the first set and configuring or building the second avoids maintaining commodity plumbing while preserving the institutional layer that makes the workflow useful.
This is the model Levercon follows. Fund OS provides the shared knowledge and control layer; Custom Agents encode recurring work around the fund's data and process; implementation happens with the team that owns the workflow. The precise operating, intellectual-property and exit arrangements still belong in the engagement terms.
Apply the month-nine test.
Before committing, ask what the system looks like nine months after launch, when the initial champion is focused elsewhere, the underlying model has changed and the workflow has evolved.
- Bought: does the product still fit, can the data and records be exported, and how many workarounds have accumulated?
- Built: who tested the latest changes, who responds when it fails, and is that work funded?
- Embedded: are the responsibilities and commercial rights documented, and is there a clear path for change whether the partner remains involved or not?
- Hybrid: are the boundary and interfaces between the shared platform and fund-specific components clear enough to change either side safely?
The route that answers those questions clearly is usually stronger than the route with the lowest first-year number. AI work at funds often fails after a successful demonstration, when ownership and change become recurring operating work. The build, buy and embed decision should be made for that phase.
Questions this guide answers.
When should a fund buy an off-the-shelf AI product?
When the workflow is genuinely standard across funds and the vendor already serves funds like yours. Document extraction and general assistants are reasonable buys. The further a workflow sits from the market average, the more of the vendor's product you end up working around.
When does building in house make sense?
When the workflow is a real source of edge, when the context that makes it work is specific to your fund, and when you can staff it past the first release. The common failure is not the build. It is that nobody owns it once the person who wrote it moves on.
What does embedding mean in this context?
A partner works closely with the fund's people and systems to implement, configure or build the workflow. It does not automatically mean the fund owns every component or can maintain it alone. The engagement should state who owns the data and intellectual property, who operates and changes the system, what documentation is supplied, and what happens on exit.
What is the month-nine test?
Ask what the system looks like nine months after launch, when the person who championed it has moved on, the model has been updated and a workflow has changed. Whichever route survives that question honestly is usually the right one.
Working with Levercon.
Levercon builds the AI operating system for credit funds: Fund OS connects a fund's own data into a knowledge layer, and Custom Agents run repetitive work across origination and monitoring. To talk to us, email info@levercon.ai.
This guide is general information, not advice. Factual claims that rely on public sources link to those sources in the text. Practical guidance also draws on patterns Levercon observes across Australian credit funds. No client is named and no figure is attributed to one. Written by Levercon, reviewed before publication and revised in place as the facts change.