AI integration services: what to scope before you buy

API call. Your server posts a prompt, gets a completion, returns it to your UI. Fine for classify, summarize, draft. You own auth, rate limits, and logging. The model is a dependency, not a product surface.

Embedded widget. A chat or assist panel inside your app. Still your route. Still your key on the server. The widget is chrome. The product is the route that checks the session and calls the model. I already wrote how I wire that for chatbot work in Next.js.

Agent with tools. The model can call named functions: getOrder, searchDocs, createTicket. Each tool has a schema and an auth check in your code. The model proposes. Your handler runs. This is powerful and expensive when unbounded. Cap the steps. Log every call.

I pick the smallest shape that does the job. An agent is not a badge of seriousness. It is more surface area. If a single API call drafts the email and a human sends it, that is often the right integration.

When a pitch says “generative AI platform” and cannot say which of those three shapes they will leave in your repo, I treat it as a workshop, not a build.

What I refuse in the SOW

This is the part demos skip.

Open proxy key. If the browser holds the model key, or if anyone can hit your chat route without a session, you did not buy an integration. You bought a shared wallet. Key on the server. Auth on the route. Rate limit per user.

Unbounded tools. An agent that can call anything the signed-in user can call, with no step cap and no review, is not a feature. It is an incident waiting for a confused prompt. Read tools first. Write tools only when the blast radius is named.

No auth owner. Someone on your side owns who the model acts as. Session user. Service account. Impersonation rules. If the vendor “handles auth later,” the integration is not scoped.

Vendor owns your data path. If the only way to reach your docs or orders is through their black box, and you cannot export or replace the connector, you are renting a hostage. Prefer your route calling their model API (or yours) with your retrieval. Keep the data boundary in code you can open.

Cost without a cap is the quiet version of the same refuse list. Messages per user per day. Max steps. A cheaper model for routing when the hard model is only needed for the final answer. Put those in the SOW, not in a post-launch surprise.

What I skip

I skip a custom model when retrieval plus tools will do. Most product integrations need your docs, your orders, your tickets. They need clean tools and a prompt that names the job. Fine-tuning is a later problem.

I skip “AI strategy” decks that never name a surface. Strategy without a screen is a workshop invoice.

I skip blending this with Cursor mentoring or a vibe-code pitch. Different offer. Different URL. This post is Build: wiring AI into the product you ship.

I skip promising “human-like” copy as the success metric. Correct, bounded, and fast enough beats charming and wrong.

I skip a second URL for “generative AI integration services.” Same scoping job. Same three names. One post.

What I will take

I will take an existing Next.js (or similar) app with auth already shipping, and a one-page brief that names surface, data, and write path. We pick the smallest shape. We put the key on the server. We ship behind the signed-in wall first when the data is private.

I will take a vendor demo that needs to become a product. Pull the key out of the client. Move the call into your route. Replace stub tools with handlers that check the user. That week is usually worth more than another bake-off.

If that is the ticket on your desk, the door is Hire an AI developer. Send the surface, the data boundary, and what the model is allowed to write. I will tell you what I would scope first.

Surface. Where does the AI show up for a real user? A support panel. An admin helper. A draft button on a form. A background job that never hits the UI. If you cannot point at a screen or a job, you are buying a demo, not an integration.

Data. What can the model read? Product docs. Orders for the signed-in user. Ticket history. A private knowledge base. Name the sources and the auth boundary. “All our data” is not a source. It is how you get a leak and a surprise bill in the same week.

Write path. What can it change? Create a ticket. Update a draft. Trigger an email. Nothing. Read-only is a valid answer. Write tools without a named blast radius are how a helpful bot rewrites production rows because a prompt was fuzzy.

If those three are blank, I push the SOW back. Generative AI integration into an existing product is the same three questions with a longer answer on the write path. The model still needs a surface, a data boundary, and a list of mutations you can defend.

Pick the shape, not the logo

Vendors sell logos. I buy a shape.

API call. Your server posts a prompt, gets a completion, returns it to your UI. Fine for classify, summarize, draft. You own auth, rate limits, and logging. The model is a dependency, not a product surface.

Embedded widget. A chat or assist panel inside your app. Still your route. Still your key on the server. The widget is chrome. The product is the route that checks the session and calls the model. I already wrote how I wire that for chatbot work in Next.js.

Agent with tools. The model can call named functions: getOrder, searchDocs, createTicket. Each tool has a schema and an auth check in your code. The model proposes. Your handler runs. This is powerful and expensive when unbounded. Cap the steps. Log every call.

I pick the smallest shape that does the job. An agent is not a badge of seriousness. It is more surface area. If a single API call drafts the email and a human sends it, that is often the right integration.

When a pitch says “generative AI platform” and cannot say which of those three shapes they will leave in your repo, I treat it as a workshop, not a build.

What I refuse in the SOW

This is the part demos skip.

Open proxy key. If the browser holds the model key, or if anyone can hit your chat route without a session, you did not buy an integration. You bought a shared wallet. Key on the server. Auth on the route. Rate limit per user.

Unbounded tools. An agent that can call anything the signed-in user can call, with no step cap and no review, is not a feature. It is an incident waiting for a confused prompt. Read tools first. Write tools only when the blast radius is named.

No auth owner. Someone on your side owns who the model acts as. Session user. Service account. Impersonation rules. If the vendor “handles auth later,” the integration is not scoped.

Vendor owns your data path. If the only way to reach your docs or orders is through their black box, and you cannot export or replace the connector, you are renting a hostage. Prefer your route calling their model API (or yours) with your retrieval. Keep the data boundary in code you can open.

Cost without a cap is the quiet version of the same refuse list. Messages per user per day. Max steps. A cheaper model for routing when the hard model is only needed for the final answer. Put those in the SOW, not in a post-launch surprise.

What I skip

I skip a custom model when retrieval plus tools will do. Most product integrations need your docs, your orders, your tickets. They need clean tools and a prompt that names the job. Fine-tuning is a later problem.

I skip “AI strategy” decks that never name a surface. Strategy without a screen is a workshop invoice.

I skip blending this with Cursor mentoring or a vibe-code pitch. Different offer. Different URL. This post is Build: wiring AI into the product you ship.

I skip promising “human-like” copy as the success metric. Correct, bounded, and fast enough beats charming and wrong.

I skip a second URL for “generative AI integration services.” Same scoping job. Same three names. One post.

What I will take

I will take an existing Next.js (or similar) app with auth already shipping, and a one-page brief that names surface, data, and write path. We pick the smallest shape. We put the key on the server. We ship behind the signed-in wall first when the data is private.

I will take a vendor demo that needs to become a product. Pull the key out of the client. Move the call into your route. Replace stub tools with handlers that check the user. That week is usually worth more than another bake-off.

If that is the ticket on your desk, the door is Hire an AI developer. Send the surface, the data boundary, and what the model is allowed to write. I will tell you what I would scope first.

AI integration services that are worth the invoice start with a scope you can say out loud. Not a model brand. Not a slide that says “AI-powered.” The surface where the model shows up, the data it is allowed to read, and the write path it is allowed to touch.

I have sat on both sides of that SOW. Buyer who wanted “some AI in the product.” Seller who got handed a vague brief and a deadline. The projects that stayed maintainable named those three early. The ones that turned into a science fair did not.

I’m Aris Setiawan. I ship Next.js and AI product work for client builds. I already wrote AI chatbot development that fits a real Next.js app, the API routes I trust, and the cache I set on Vercel. This post is what I ask when someone wants to buy AI integration services into an existing product.

The offer page is Hire an AI developer. This is the scoping guide, not a hire brochure.

Name these three before the kickoff

I do not start with a vendor shortlist. I start with three names on a page.

Surface. Where does the AI show up for a real user? A support panel. An admin helper. A draft button on a form. A background job that never hits the UI. If you cannot point at a screen or a job, you are buying a demo, not an integration.

Data. What can the model read? Product docs. Orders for the signed-in user. Ticket history. A private knowledge base. Name the sources and the auth boundary. “All our data” is not a source. It is how you get a leak and a surprise bill in the same week.

Write path. What can it change? Create a ticket. Update a draft. Trigger an email. Nothing. Read-only is a valid answer. Write tools without a named blast radius are how a helpful bot rewrites production rows because a prompt was fuzzy.

If those three are blank, I push the SOW back. Generative AI integration into an existing product is the same three questions with a longer answer on the write path. The model still needs a surface, a data boundary, and a list of mutations you can defend.

Pick the shape, not the logo

Vendors sell logos. I buy a shape.

API call. Your server posts a prompt, gets a completion, returns it to your UI. Fine for classify, summarize, draft. You own auth, rate limits, and logging. The model is a dependency, not a product surface.

Embedded widget. A chat or assist panel inside your app. Still your route. Still your key on the server. The widget is chrome. The product is the route that checks the session and calls the model. I already wrote how I wire that for chatbot work in Next.js.

Agent with tools. The model can call named functions: getOrder, searchDocs, createTicket. Each tool has a schema and an auth check in your code. The model proposes. Your handler runs. This is powerful and expensive when unbounded. Cap the steps. Log every call.

I pick the smallest shape that does the job. An agent is not a badge of seriousness. It is more surface area. If a single API call drafts the email and a human sends it, that is often the right integration.

When a pitch says “generative AI platform” and cannot say which of those three shapes they will leave in your repo, I treat it as a workshop, not a build.

What I refuse in the SOW

This is the part demos skip.

Open proxy key. If the browser holds the model key, or if anyone can hit your chat route without a session, you did not buy an integration. You bought a shared wallet. Key on the server. Auth on the route. Rate limit per user.

Unbounded tools. An agent that can call anything the signed-in user can call, with no step cap and no review, is not a feature. It is an incident waiting for a confused prompt. Read tools first. Write tools only when the blast radius is named.

No auth owner. Someone on your side owns who the model acts as. Session user. Service account. Impersonation rules. If the vendor “handles auth later,” the integration is not scoped.

Vendor owns your data path. If the only way to reach your docs or orders is through their black box, and you cannot export or replace the connector, you are renting a hostage. Prefer your route calling their model API (or yours) with your retrieval. Keep the data boundary in code you can open.

Cost without a cap is the quiet version of the same refuse list. Messages per user per day. Max steps. A cheaper model for routing when the hard model is only needed for the final answer. Put those in the SOW, not in a post-launch surprise.

What I skip

I skip a custom model when retrieval plus tools will do. Most product integrations need your docs, your orders, your tickets. They need clean tools and a prompt that names the job. Fine-tuning is a later problem.

I skip “AI strategy” decks that never name a surface. Strategy without a screen is a workshop invoice.

I skip blending this with Cursor mentoring or a vibe-code pitch. Different offer. Different URL. This post is Build: wiring AI into the product you ship.

I skip promising “human-like” copy as the success metric. Correct, bounded, and fast enough beats charming and wrong.

I skip a second URL for “generative AI integration services.” Same scoping job. Same three names. One post.

What I will take

I will take an existing Next.js (or similar) app with auth already shipping, and a one-page brief that names surface, data, and write path. We pick the smallest shape. We put the key on the server. We ship behind the signed-in wall first when the data is private.

I will take a vendor demo that needs to become a product. Pull the key out of the client. Move the call into your route. Replace stub tools with handlers that check the user. That week is usually worth more than another bake-off.

If that is the ticket on your desk, the door is Hire an AI developer. Send the surface, the data boundary, and what the model is allowed to write. I will tell you what I would scope first.