Build, buy, or hire: three ways to get an AI assistant working for youBuild, buy, or hire: three ways to get an AI assistant working for you

Once the job is clear, three routes cover most decisions. Buy a configurable product that serves a common workflow. Commission an integration around your existing systems and rules. Build and operate the capability with an internal technical team. Hybrid arrangements are normal: an in-house owner can commission an initial build, or a specialist product can sit inside a custom workflow.

The fourth option is to do less. An ordinary form, search page, automation rule, checklist or process change can remove the same friction without adding probabilistic output and model governance. OpenAI and Anthropic both advise starting with simpler designs before adding agent complexity.^[2][1] Ask whether AI is solving the problem or merely making the interface more conversational.

No route removes work; it moves work to different owners. Buying moves more product engineering to a vendor but leaves configuration and adoption with you. Commissioning adds a delivery partner but still needs a business owner. Building maximises control and concentrates long-term technical responsibility inside the organisation.

Start with an established product for standard scheduling, meeting support, general drafting, conventional pipeline follow-up, help-centre answers or work already contained in Microsoft 365 or Google Workspace. Shared engineering and an existing interface can make this route faster and less expensive than integration.

The trade-off is product shape. Your team may need to adopt the vendor’s fields, permissions, handover and reporting. Evaluate the actual account and workflow rather than the feature page. Configure the sources, identity and ownership properly; otherwise the characteristic failure is a subscription that nobody trusts because its facts were never maintained.

A time-boxed trial should include normal and difficult cases, staff effort and an exit decision. Do not let a trial become permanent shadow infrastructure with unclear data and no owner.

Commissioning becomes sensible when useful work spans existing systems, depends on organisation-specific sources or approval rules, or needs governance an off-the-shelf product cannot express. Examples include a WhatsApp enquiry that must use a controlled catalogue, enter a lead queue, schedule an approved follow-up and remain visible to several staff roles.

The setup quote should separate workflow mapping, source preparation, connectors, identity and permissions, evaluation, migration and launch. Monthly care should state monitoring, source or connector maintenance, support, correction review and the boundary between routine care and new scope. Third-party usage should be included, capped or clearly passed through.

The characteristic failure is commissioning an aspiration. If the process has not run consistently, each discovered exception becomes a redesign. Observe the work first, and accept that a good discovery can conclude that a product or process change is sufficient.

In-house development fits when the assistant is close to the organisation’s differentiating capability, deep control is essential, requirements evolve continuously or the scale justifies a dedicated team. Modern model APIs make prototypes accessible; reliable operation remains a multidisciplinary product and platform responsibility.

The continuing cost includes evaluation sets, model and dependency changes, observability, incident response, vendor management, access control, security review, documentation, user support and recovery. NIST’s lifecycle framing and IMDA’s agentic AI guidance both reinforce that deployment is the beginning of governance, not its end.^[4][3]

The characteristic failure is a useful prototype becoming load-bearing without ownership. When the original builder leaves, nobody understands the prompts, permissions or failure modes. Internal build should come with service ownership, documentation, code review, deployment discipline and a succession plan.

Build a twelve-month view using the same cost categories for every route. Include the internal hours needed to configure, review, correct, maintain sources and handle exceptions. Include integration work, vendor usage, infrastructure, security and exit. Do not count every saved minute as cash; use observed bottlenecks and service outcomes.

Buying does not outsource the organisation’s responsibility for personal data; commissioning does not make the supplier the business owner; building does not remove dependence on model, hosting and messaging providers. In Singapore, map the purpose, notification, consent where required, access, protection, retention, transfer and breach processes for the chosen route.^[5]

Ask who owns the account, code, configuration, source set, workflow state, logs and derived data. Define how permissions are revoked and what the organisation receives at exit. A low-friction signup can create high-friction departure if those questions are delayed.

Write a short decision brief before contacting vendors: the outcome, current process, arrivals, systems, volume, sensitive data, actions, human boundaries and success measure. Then test the lowest-complexity credible option. Use what the trial reveals to accept the product, revise the process or specify the gap for a commissioned or internal build.

1. Step 01

   Observe the workflow

   Collect real cases, exceptions, delays and workarounds for at least one representative cycle.

2. Step 02

   Define the outcome

   Name completion, the current baseline, risk boundary and human owner.

3. Step 03

   Test a product

   Use a time-boxed trial on approved data with explicit acceptance criteria.

4. Step 04

   Specify the gap

   Separate missing configuration from true integration or product requirements.

5. Step 05

   Choose the owner

   Select the route whose ongoing operating model the organisation can sustain.

6. Step 06

   Preserve an exit

   Record exports, credentials, documentation, retention and replacement before launch.

Buy if the workflow is common and adapting to a product is acceptable. Commission if value depends on connecting your existing channels, sources and rules and you want an accountable delivery and care relationship. Build if the capability is strategically important and the organisation is prepared to operate a software system indefinitely. Use an ordinary tool if it solves the job more predictably.

Our Assistant Finder produces a starting recommendation across those paths. The pricing page shows our integration package shapes so they can be compared with products and internal ownership rather than treated as the default answer.