A receptionist demo answers the phone, greets the caller and handles a couple of questions. A production voice agent has to book the slot. On the dealership voice agents we built for Innovative AI, that meant settling four things on one call: the exact vehicle, the right service out of the 100–200 on that vehicle’s menu, an open time and a way to get the car in.

The gap between those two is mostly routing. The demo puts one agent on the line and asks it to do everything. The production system puts a receptionist agent in front whose only job is to work out what the caller wants, and hands the call to an agent built for that job. This guide covers how that split works, what booking needs before it can happen, and when a phone tree or one more person at the front desk is the better buy. It is the call design we use for custom AI voice agents and AI receptionists.

What is call routing for an AI receptionist?

Call routing for an AI receptionist is the step where the agent works out the caller’s intent and sends the call to the path that handles it. That path can be another agent, a person or a callback queue. Routing is a classification problem, and it is the first decision on every call.

Anthropic’s guide to building agents describes the same pattern under the name routing: it “classifies an input and directs it to a specialized followup task”, and works well “for complex tasks where there are distinct categories that are better handled separately”. Its first example is customer service queries sent to different downstream prompts and tools. Agent frameworks build it in. OpenAI’s Agents SDK, for example, exposes each handoff to the model as a tool, so a triage agent can transfer a caller to a billing or refund agent.

A keypad menu routes too, but the caller does the classifying by pressing 2. An AI receptionist asks an open question (“How can I help?”) and does the classifying itself.

Why a demo receptionist breaks on a real phone line

A demo receptionist breaks because one agent carries every instruction, every tool and every edge case at once. With two call types that holds up. With five, the prompt mixes booking rules with status lookups and policy answers, and a change for one call type can break another that you didn’t retest.

Real phone lines carry several kinds of calls. A dealership line carries service bookings, questions about a car already in the shop and calls about everything else. Each needs different data and ends differently: a booking ends with an appointment written to the scheduler, a status question ends with an answer, and a complaint ends with a person.

Splitting the work lets you treat each call type as its own small system:

• Shorter instructions. The booking agent only carries booking rules, so it never has to decide whether the caller is booking at all.
• Fewer tools per agent. An agent that can only read the menu and write appointments can’t call the wrong system.
• Tests per call type. You can replay a week of booking calls against the booking agent alone and see what changed.
• Failures you can locate. When a call goes wrong, the transcript shows whether the route or the task failed.

The cost is one more step on every call. The handoff has to be fast and invisible to the caller, which is a latency question as much as a design one; our guide to voice agent latency covers that budget.

How the front agent routes a call in production

On the Innovative AI system, a receptionist agent takes every inbound call first. Its only job is to work out what the caller wants and hand the call to the agent built for that. The agents are still live in production.

We built the receptionist around three paths: book a service, check on a car already in the shop, or something else. By the time the booking agent speaks, the intent is settled. For a phone number the system already knows, so are the caller’s name, car and last service, which are saved against the number from earlier calls.

Three rules we recommend for any front agent:

• Ask rather than guess. If the first sentence could mean two things, ask one short question. A wrong route costs the caller their first minute.
• Confirm a saved caller, don’t assume one. A phone number identifies a line. Households share phones and cars, so a quick “Is this about the Camry?” beats a booking for the wrong vehicle.
• Pass a summary with every handoff. Whoever takes the call next, agent or person, should start from what the caller already said.

The case study on Innovative AI’s dealership voice agents covers the rest of the system, including its outbound calls.

What a booking needs before it exists

A booking exists only when the agent has every field the scheduler needs and the caller has agreed to them. On the Innovative AI build there were four, collected in order, and the booking agent wrote nothing until all four were settled.

1. The exact vehicle. Year, make, model and trim, because the service menu depends on the car.
2. The right op code. The caller describes the job in their own words, and the agent picks the matching entry out of the 100–200 services on that vehicle’s menu, each with its own op code.
3. An open slot. The agent checks the requested time against the dealership’s open appointments and offers another time if it is taken.
4. A transport choice. Drop-off (with a shuttle or loaner if needed), pickup by the dealership or mobile service at home, with an address asked for only when the option needs one.

Before booking, the agent reads the service back and goes on only once the caller agrees. A wrong op code books the wrong job, so that confirmation is in every booking.

This is where a demo and a production agent differ most. A demo can say “You’re all set for Tuesday” without anything behind it. A production agent can only say it after the scheduler has accepted the appointment. Our guide to AI service scheduling for dealerships walks through each of the four steps from the caller’s side, including what to do when no menu entry matches.

Other businesses have their own four fields. A clinic needs the patient, the visit type, the provider’s open slot and the location. A field service company needs the address, the job, the window and the access details. Write the list down before any prompt: it decides what the booking agent asks and in what order.

Where routed calls still fail

Routing narrows the failures but doesn’t remove them. On the Innovative AI build, the bookings that didn’t complete failed for three reasons: requests too odd or ambiguous to match to a service, accents and pronunciation the speech recognition misheard, and heavy background noise at the caller’s end.

None of those is a routing failure, but routing decides what happens next. A narrow booking agent knows when it is stuck, because it is stuck on one question: which service the caller means. That makes a clean exit easy to design. We recommend that after one failed clarification the agent offers an advisor or a callback and passes on what it already has, so the call ends with a next step instead of a hang-up.

Track routing separately from booking after launch. Count calls by the path the front agent chose, the handoffs to people by reason, and calls that were sent to one agent and handed back. A rising hand-back rate means the front agent is guessing.

When a phone tree or better staffing wins

A phone tree wins when callers need a destination, not an outcome; better staffing wins when the calls need judgment and the volume fits in business hours. An AI receptionist earns its build cost when many callers need something done, such as a booking, at hours or volumes your staff can’t cover. We build the third option, so weigh this table with that in mind.

GetVoIP’s comparison of the two makes a similar point from the IVR side: for pure high-volume transactional sorting, it says, “a menu is faster and cheaper than any conversation.”

Staffing is easy to size. The Bureau of Labor Statistics puts the 2025 median pay for receptionists at $18.27 an hour. A full-time receptionist covers about 40 of the 168 hours in a week, roughly 24%, and one call at a time within those hours. If your missed calls fall inside those 40 hours and rarely overlap, a second person or a better lunch rota is the cheaper fix. If they fall at night, on weekends or in bursts, a person can’t cover them at that price, and an agent can.

How to scope an AI receptionist that books

Start from the call log, not the demo. A week of recorded calls shows which intents your line carries, how many of them are bookings and how far callers’ words sit from the items in your booking system. From that, the scope writes itself:

• The paths. The intents the front agent routes on day one, and where everything else goes.
• The fields. For each bookable path, the fields the scheduler needs and the order the agent asks for them.
• The confirmation. What the agent reads back before it writes anything.
• The exits. When the agent hands over to a person, and what summary goes with the call.
• The measures. Booking completion among callers who chose to book, handoffs by reason and hand-backs from the routed agents.

A routed receptionist with booking falls in our $25k–$120k fixed-price band, set after a Discovery Sprint. The number of paths and booking-system connections moves it within the band more than the conversation does; the pricing page explains how the band is set.

Before any of that, check whether the calls you miss are worth the build. Put your call volume, missed-call share and customer value into the AI voice agent ROI calculator, and our guide to the cost of missed calls shows the formula behind it.

Originally published at apptycoons.com.

In 2025 a researcher scanned 1,645 apps built with Lovable and found 170 of them, about 10.3%, with database access rules loose enough that strangers could read or change the data. The record for that issue, CVE-2025-48757, scores it 9.3 out of 10. Lovable disputes it, on the grounds that each customer is responsible for protecting their own app’s data.

That dispute is the whole problem in one line. The tool built the app. Making it safe to run is still the owner’s job.

If you built a prototype with an AI tool and people already use it, the hard question is behind you: the idea works. What is left is the work nobody sees in a demo. It covers who can read which row, what happens when a payment call times out, whether Apple will accept the build and who holds the keys. This guide is the checklist for that work, and a way to decide what to fix and what to rebuild.

Why AI-built prototypes break once real users arrive

AI-built prototypes break in production because the tools optimize for a working screen, not for the conditions around it. The complaints are usually the same five: it breaks once real users arrive, it fails a security review, it can’t connect to the systems the business uses, the app store rejects it, and nobody understands the code.

The security part is measured. Veracode tested more than 100 large language models on 80 coding tasks and found security flaws in 45% of the results. Java failed more than 70% of the time. The models left code open to cross-site scripting in 86% of the relevant cases and to log injection in 88%. Larger models did not do significantly better than smaller ones.

Operations fail in a different way. In July 2025, during a code freeze, Replit’s AI agent deleted a live company database in a test run by SaaStr’s founder, erasing records for more than 1,200 executives and over 1,190 companies, according to Fortune. Replit’s CEO called it unacceptable. The company then announced automatic separation of development and production databases. That separation is exactly the kind of thing a prototype skips.

None of this means the prototype was a mistake. It proved the product. It was never built to carry other people’s money and data.

The production-readiness checklist for an AI-built app

Each item below has a test you can run or ask for. If nobody can show the test passing, treat the item as open.

Security

• Server-side access rules. Every read and write is checked on the server, not hidden in the interface. Test: log in as one user, change the record ID in a request to another user’s, and confirm the server refuses.
• Row-level security, deny by default. On Supabase and similar backends, every table with user data has row-level security switched on and a policy per action. A table with no policy should return nothing, not everything.
• Secrets out of the client. No service keys, AI API keys or payment secrets in the browser bundle or the mobile app. Calls that need them go through your server. Rotate any key that was ever shipped to a client.
• Input validation. Every form and API input is validated on the server for type, length and format, and output is escaped. That is where cross-site scripting and log injection start.
• Auth that can be revoked. Email verification where identity matters, rate limits on login and password reset, and sessions you can end from the server.

Watch out

A missing policy is an open door

In CVE-2025-48757, insufficient row-level security let unauthenticated users read or write tables in generated sites. Test with a logged-out request and with a second account, not only as yourself.

Data

• Backups you have restored. Automatic backups, plus one restore into a separate environment to prove they work.
• Separate development and production. A different database and different keys for each, so a test, a migration or an agent can’t touch live data.
• Migrations in version control. Schema changes are scripts in the repository, run the same way every time, not edits made in a dashboard.
• A ledger for money. If the app holds balances, credits, commissions or payouts, record every movement as an entry and derive the balance from the entries. A balance column that gets overwritten can’t be audited or reconciled with the payment provider.

Reliability

• Idempotent payment and booking calls. A retried request must not charge twice or book twice. Stripe’s API takes an idempotency key for exactly this: repeat the request after a connection error and it does not create a second object. Your own booking and order endpoints need the same rule.
• Retries with limits. Calls to outside services retry with backoff, then stop and record the failure instead of looping.
• Webhooks handled once. Payment and subscription webhooks are verified, stored and processed once, even when the provider sends them twice.
• Error tracking and monitoring. Errors reach a named person, with alerts on failed payments, failed jobs and spend on AI APIs. Rate-limit anything that costs money per call.

Integrations

• Gated APIs planned early. Some systems have no self-serve key. Dealership scheduling software is one example: access to Xtime runs through Cox Automotive’s partner program, with an agreement, fees and a certified demo, and then each dealership opts in. Our Xtime API integration guide lists the steps. Find out which of your integrations work like this before you promise a launch date.
• Writes that can be undone. Every write to another system has error handling and a way to correct it.

App stores

• Apple guideline 4.2. An app needs “features, content, and UI that elevate it beyond a repackaged website.” A web prototype wrapped in an app shell is the case this rule describes.
• Apple guideline 4.2.6. Apps “created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content.” Submit from your own developer account, under your own name.
• Store rules for payments. Apple’s guideline 3.1.1 requires in-app purchase for access to features or content inside the app, subscriptions included. That changes your fees and your revenue math, so check it before you price the plan.

Code ownership

• Accounts in your company’s name. The repository, cloud, database, domain, Apple and Google developer accounts, payment provider and every API key. Nothing held by a freelancer or a builder platform alone.
• A build that runs outside the tool. Someone other than the original builder can clone the repository, run it locally and deploy it from written steps.

Maintainability

• Tests on the paths that move money or data. Not full coverage: sign-up, login, payment, booking and anything that deletes.
• One way of doing each thing. Prompt-by-prompt building can leave duplicate libraries and parallel auth flows. Pick one of each and delete the rest, because dead generated code is still reachable code.
• A README a new engineer can follow. How to run it, how to deploy it, where the secrets live and who to call.

Fix or rebuild: how to decide

Fix the prototype when its foundations are sound and the problems are local. Rebuild the parts whose foundations are wrong, which is rarely the whole app. The test is not how the code looks. It is whether the data model and access model can express what the product has to do.

Two more cases point to a rebuild. The first is a platform limit: an app that has to control hardware over Bluetooth, run in the background or pass review as a native app may need native code the builder can’t produce. The second is an integration that needs a server-side partner connection the prototype has no place for.

The usual result is a mix. The screens stay, because they are what users already know. The access rules get rewritten. The data model gets a review, and the money tables get a ledger.

Can the AI tool make the app production ready on its own?

Partly. An AI tool can fix a named issue fast, and our own engineers use AI tools every day. What it can’t do is decide what to check, notice what is missing or answer for the result. Production needs a senior engineer hands-on: someone who reads the access rules, runs the restore and signs off on the payment flow.

Professional developers already work this way. In Stack Overflow’s 2025 survey of developers, 72% said vibe coding is not part of their professional work. More developers distrusted the accuracy of AI tools (46%) than trusted it (33%). And 75.3% said they would ask a person when they don’t trust an AI’s answer. Google’s DORA 2025 report, from nearly 5,000 technology professionals, describes AI’s main role in software development as “an amplifier”. It strengthens a team’s good practices and its bad ones alike.

So the question is not AI or no AI. It is whether someone with production experience is steering it.

What a production-readiness audit should deliver

A useful audit ends with decisions, not a list of worries. Ask for these before you pay for one:

• A findings list ranked by risk. Each finding says what is wrong, how it was tested and what an attacker or a bad day could do with it. Launch blockers are marked as blockers.
• A fix-or-rebuild call per layer. For screens, business rules, data model, access rules, integrations and hosting, with the reason.
• An ownership inventory. Every account and key, who holds it now and the steps to move it to you.
• Integration and store risks. Which APIs need partner approval, and how long it takes. Whether the app is likely to pass App Store review as built.
• A fixed quote for the fix list. Scope, price and order of work, so you can compare it with rebuilding or doing it in-house.

Who does the audit matters as much as the list. At Apptycoons it is done by our senior engineers, who were writing production code before AI tools existed. A technical project manager then turns the findings into a scope. The first conversation is free. The audit itself is scoped and priced before it starts, and if the fix list is big enough to be a project, it is quoted as a Fixed-Price Build in our $25k–$120k band. Our guide to fixed price or time and materials explains why we quote that way.

Where our builds cover these parts

None of the apps below started as an AI-built prototype. We built them from scratch, and each one covers a part of the checklist above.

• Access by role. Switch is shared banking for clubs and teams. An account belongs to a group, so treasurers, admins and members each get different rights over money and cards, and a card’s state has to show the same on every device.
• Money that reconciles. Freedom Pro pays commissions to a partner network and holds USD and stablecoin balances. The same team activity must always produce the same commission, and balances have to reconcile with the provider’s records.
• Payouts and store purchases. DubCam pays creators 50% of each subscription on the first of the month, with subscriptions on the phone apps running through in-app purchases. The revenue share guide covers the ledger and the store fee math.
• A native app through review. OHM Fitness runs separate native iOS and Android apps that control a 20-electrode suit over Bluetooth LE, live on the App Store and Google Play.
• A gated integration. Innovative AI runs voice agents that book dealership service in Xtime, one of the systems you can’t reach with a self-serve key.

If you want us to do this work on your app, our AI prototype to production service runs the audit and the fixes at a fixed price. For new web apps, our web app development page describes how we build them. For store releases, see mobile app development.

When you don’t need an agency

You don’t need an agency if the app is a demo, a waitlist or an internal tool with a handful of users, no payments and no sensitive data. Keep building with the AI tool. Work through the security and data sections of the checklist yourself, and turn on backups.

One experienced freelance engineer is often enough when the app has one clear risk: a missing access policy, an exposed key, a deploy that only works from the builder. Ask them to show you the tests passing.

A senior team earns its cost when several of these are true at once: money moves through the app, it stores personal data, an integration needs partner approval, a native app has to pass review, or you plan to raise money and someone will look at the code. If two or more apply, book an audit and bring the repository, the list of accounts and the problem that worries you most.

Originally published at apptycoons.com.

On the dealership voice agents we built for Innovative AI, each vehicle’s service menu held 100–200 services, and every one of them had its own op code. No caller ever says an op code. They say something like “it’s making a grinding noise” or “whatever’s due at this mileage”, and the agent has to get from that sentence to one line on that car’s menu before it can ask about a time.

That matching step is the part of the call a script or keypad menu can’t do. The rest of the call (vehicle, time, transport) is ordinary slot-filling, but each part has a rule that breaks the booking if you skip it. This guide walks through the call from the caller’s side, in the order our agents ran it. It is the same flow we build into custom AI voice agents for service departments.

How does an AI agent book a dealership service appointment?

An AI agent books dealership service by identifying the vehicle, loading that vehicle’s service menu, matching the caller’s description to one service on it, finding an open slot, settling transport and writing the appointment into the scheduler. On the Innovative AI build, a receptionist agent took the call first and sent only booking requests down this path; questions about a car already in for work went elsewhere. After that routing, the booking ran in six steps:

1. Vehicle. The agent asks for year, make, model and trim.
2. Menu. It fetches that vehicle’s available services from Xtime, the dealership’s scheduler.
3. Need. The caller says what they want in their own words. The agent maps it to an op code on the menu and reads the service back for a yes.
4. Time. The agent asks for a date and time and checks it against the dealership’s open appointments. If the slot is taken, it offers others.
5. Transport. Drop-off, pickup by the dealership or mobile service at home. Pickup and mobile need an address; drop-off callers get offered a shuttle or a loaner.
6. Book. The agent books the appointment for that op code and time.

The Innovative AI case study covers what else those agents did. Here we stay with the booking call.

Why the vehicle comes first

The vehicle comes first because the service menu depends on it. A synthetic oil change on one engine is a different line, with a different labor time and price, from the same service on another, and some services only exist for some models. Until the agent knows the car, it has nothing to match the caller’s words against.

Xtime describes its menus as dynamic menus that reflect the dealership’s own pricing, promotions and service recommendations. On the integration side, Supergood’s report card on the Xtime API (last verified October 2026) says partner integrations create appointments by year, make and model or by VIN. The vehicle is the key the scheduler works from, so it is the first thing the agent needs.

Ask for year, make, model and trim rather than the VIN: callers know what they drive, and few can read a 17-character VIN off the door jamb while holding the phone. Trim matters more than callers expect. If two trims of the same model carry different menus, the agent should ask which one, or ask for the VIN only then.

Two small rules we recommend for this step:

• Confirm the vehicle once, in one sentence. “A 2021 Camry SE, is that right?” A wrong model year loads the wrong menu, and everything after it is wrong too.
• Accept partial answers. Many callers give make and model and stop. The agent asks for the missing piece rather than starting over.

Matching the caller’s words to an op code

An op code is the dealership’s identifier for one service operation, and matching is the step where the agent turns a caller’s description into one of them. Dominion DMS’s documentation defines operation codes as codes that “help categorize service tasks and their prices”: each carries a description, labor hours or a fixed price, parts and the makes, models and years it applies to. myKaarma’s documentation notes that a dealership may have a large number of them, “sometimes exceeding thousands.”

A caller never needs to know any of that. Callers describe symptoms (“there’s a clunk when I go over bumps”), ask for scheduled maintenance by mileage, or name a service loosely (“tires”). Our agent took the description, compared it with the services on that vehicle’s menu and picked the closest match. Then it confirmed in plain words before going further, along the lines of: “That sounds like a suspension inspection. Shall I book that?” Booking the wrong op code means the wrong labor time is reserved and the technician starts the job without the right parts, which costs more than a five-second confirmation.

“Tires” is a good example of why the confirmation is not optional. If one tire, two tires and four tires are separate menu lines with separate codes, the agent has to ask how many before it can pick one.

Not every description maps to a menu line. Our recommendation for that case, which is a design choice rather than something Xtime prescribes:

• If the caller describes a symptom with no clear match, book the dealership’s general diagnosis or inspection service, if it has one, and put the caller’s own words in the appointment notes for the advisor.
• If the request is outside the menu altogether (a body repair, a warranty dispute), don’t force a match. Hand the call to an advisor or take a callback.
• Never invent a service. The agent only offers lines the scheduler returned for that vehicle.

How menus and op codes reach the agent on the system side, including partner access, is covered in our Xtime API integration guide.

Checking open slots and offering another time

The agent checks the requested date and time against the open appointments the scheduler returns and, if that slot is gone, offers the closest alternatives. On our build the caller named a time, the agent compared it with the dealership’s available appointments and, when it wasn’t free, worked out another time with the caller instead of failing the call.

The one hard rule: the agent never books a time the scheduler didn’t return as open. A language model will happily agree to “Tuesday at 8” because it sounds reasonable. The time has to come from the availability response, not from the conversation.

What works when the first choice is taken:

• Offer two times, not a list. “Tuesday is full in the morning. I have 1:30 that day or 8:00 on Wednesday.”
• Keep the caller’s constraint. If they asked for a morning, offer the next mornings before an afternoon.
• Re-check before writing. Slots go while a caller is deciding, so the agent confirms availability at the moment it books.
• If nothing fits, offer a callback from an advisor rather than ending the call with nothing.

Drop-off, shuttle, loaner, pickup or mobile service

Transport is the last question before booking, and it decides what else the agent has to collect. On our build the agent asked whether the caller would drop the car off, wanted the dealership to pick it up, or wanted mobile service at home. Drop-off callers were then offered a shuttle or a loaner. Pickup and mobile service needed an address; drop-off didn’t.

Which options exist is the dealership’s decision, and the agent should only offer the ones it runs. Mobile service on our build was something the dealerships themselves offered. Xtime lists a direct integration with Lyft for rideshare as of October 2026, and in 2020 Auto Remarketing reported that Xtime Schedule could show loaner and valet availability. If the integration can see loaner availability, the agent can promise one; if it can’t, it should say an advisor will confirm.

Cox Automotive’s 2025 Service Industry Study of 1,974 vehicle owners found that owners want easy scheduling and flexible service options, and Cox recommends after-hours scheduling, pickup and delivery, and rideshare integration to win service visits back. A voice agent that also answers after hours and settles transport on the same call would cover several of those at once.

Returning callers and existing appointments

Returning callers shouldn’t be asked for what the dealership already knows. On our build, the caller’s name, vehicle and recent service were saved against their phone number, so a second call from the same number skipped the vehicle questions.

Two cautions. A phone number identifies a line, not a person: households share cars and phones, so the agent confirms (“Is this about the Camry again?”) rather than assuming. And a stored record is only a shortcut; if the caller names a different car, the agent loads that car’s menu.

The same lookup let callers check bookings they already had. The agent could bring up a caller’s existing appointments and confirm them, so a caller checking a booking doesn’t have to wait for the service desk.

Storing caller data has rules. In the EU, GDPR Article 13 requires the business to tell people what it collects at the time it collects it, which on a phone call means the greeting. Our EU AI Act and GDPR checklist covers the disclosure wording and retention.

Routing the calls that aren’t bookings

Not every caller wants to book, so the first job is routing. Our receptionist agent asked what the caller wanted and sent them down one of three paths: book a service, check on a car already in the shop, or anything else. A wrong route wastes the caller’s first minute, so a receptionist agent should ask rather than guess when the opening sentence is unclear. Our guide to AI receptionist call routing covers how to split that front agent from the ones behind it.

Checking on a car already in service is a status question, not a booking, and it needs a different lookup. Anything the agent can’t handle, from a billing question to a complaint, should go to a person with a short summary attached, so the caller doesn’t repeat themselves.

Outbound calls follow the same logic in reverse. When the dealership’s records showed a customer had missed their appointment, our agent called them back already knowing which service had been booked. That flow has its own consent rules, covered in our guide to no-show follow-up calls.

Why the last 1% of bookings failed

Of callers who went ahead with booking through our agent, 99% were booked, by our own count. The remaining 1% failed for three reasons.

• Requests the agent couldn’t map. Some callers described something so unusual or vague that the agent found no match, and the caller got annoyed. Our recommendation is to hand over early: after one failed clarification, offer an advisor.
• Pronunciation and accents. Speech recognition does not work equally well for every speaker. A 2020 PNAS study by Koenecke and colleagues tested five commercial systems and found an average word error rate of 0.35 for Black speakers against 0.19 for white speakers. The systems have changed since, but the lesson holds: test with recordings from your own callers, not a demo voice.
• Background noise on the caller’s side. Calls from a road, a shop floor or a car with the windows down lose words. The agent should read back the details that matter (vehicle, service, time) so a misheard word gets caught before booking.

We’d cap clarification attempts and hand over sooner for all three. A quick handoff can turn a call the agent can’t follow into a callback instead of a hang-up.

What to measure after launch

Measure booking completion among callers who chose to book, not among all calls. Many calls are status checks, routing or questions, and counting them against the booking rate hides whether the booking flow works. Our 99% was measured that way, on one build, and isn’t a forecast for another dealership.

Track these from the first week:

• Booking completion: booked appointments divided by callers who said they wanted to book.
• Handoff rate: calls passed to a person, split by reason (no menu match, outside scope, caller asked).
• Failures by cause: unmapped request, misrecognition, noise, scheduler error, caller hung up.
• Wrong-op-code rate: appointments an advisor had to change after booking, which shows whether matching works.
• Outcome at the dealership: booked appointments that arrived, so you can see the no-shows.

If you are still deciding whether the phone is worth automating, our guide to the cost of missed calls sets out how to put a number on what goes unanswered.

Buy a scheduler add-on or build your own agent?

Buy if one rooftop needs calls answered and service booked on standard menus; build if you need your own call logic across several systems. We sell the build option here, so weigh this with that in mind.

Xtime Schedule lists a Brooke.ai add-on that answers inbound service calls, handles requests and schedules appointments, as of October 2026. For a single dealership already on Xtime, an add-on like that is the shorter path, and we would buy it and revisit in a year.

A custom agent pays off when the flow is yours: a receptionist that routes service calls, outbound no-show and sales-lead follow-up in the same system, matching rules tuned to your menus, and transport options your scheduler’s add-on doesn’t cover. The Innovative AI build combined a receptionist, service booking, no-show and sales-lead follow-up, and caller memory across multiple dealerships.

On price, a scheduling voice agent falls in our $25k–$120k fixed-price band, and the price is set after a $5,000 Discovery Sprint. What pushes a dealership build up the band is the integrations and the matching layer, more than the call itself. The pricing page has the model, and our AI voice agent cost guide breaks down the running costs per minute. For how voice agents fit around DMS, CRM and scheduler software, see car dealership software and voice agents.

If you are scoping one, start with a week of call recordings and your service menu export: those two files show how many calls are bookings and how far callers’ words sit from your op codes.

Originally published at apptycoons.com.

A customer booked a service, picked a slot and never arrived. The appointment sits in the dealership’s CRM with no repair order behind it. The call that follows should already know the car, the service that was booked and the time that was missed, so its first question is “Would you like to rebook?”, not “What can I help you with?”

That is how the follow-up works on the custom AI voice agents we built for Innovative AI, which are still live in production for US car dealerships. The same system has a second outbound job: calling sales leads who visited or inquired and didn’t buy. Both calls are easy to get wrong, because each one needs the right context and the right consent.

The stakes are visible in the service lane. In Cox Automotive’s Service Industry Study (published November 11, 2025; 1,974 vehicle owners), 54% of owners of cars two years old or newer returned to the selling dealer for service, down from 72% in 2023. An appointment that lapses without a call is one more chance for an owner to try someone else.

When should a no-show call go out?

A no-show call should go out when the CRM marks the appointment as missed, not on a fixed timer from the booked slot. On our Innovative AI build, the trigger was the CRM showing that the customer hadn’t arrived; the agent then placed the call.

The status matters more than the clock. A customer who is 20 minutes late is still a customer on the way, and a call to them reads as nagging. A status set by the service desk, or by the absence of a check-in by the end of the slot, is a fact the agent can act on.

How long to wait after the status changes is a judgment, and the right window depends on the dealership. Our recommendation: call the same day while the customer still remembers why they booked, inside normal hours, and after one unanswered attempt, hand the record to a person. We don’t have measured cadence data from the build to publish, so treat that as a starting point to test, not a benchmark.

What the agent knows before it dials

The agent should start the call already holding the appointment and the customer record, so the customer never repeats what they told the dealership when they booked. On our build, every follow-up call carried the scheduled service the customer had missed.

The same build saved customer data against the phone number: the caller’s name, their car and their recent service. When the same number called again, the agent used that record instead of asking for the vehicle a second time. A no-show call can use the same record in reverse. Before dialing, the agent should load:

• The booking: the service that was scheduled, the slot that was missed and the transport choice (drop-off, pickup or mobile service).
• The vehicle: year, make, model and trim, which decide the service menu the agent can rebook from.
• The customer: the name on the record and any earlier service, so the agent can confirm it is talking to the right person.
• The consent record: which number may be called, for what purpose, and whether the customer has opted out.

Watch out

The last item is the one teams forget

A record without a consent flag is a reason not to dial.

Rebooking on the same call

The point of the call is to end it with a new appointment, so the agent should be able to book on the spot instead of promising that someone will call back. On our build, the agent asked the customer questions about the missed appointment, then rebooked the service or did whatever the customer asked.

We recommend that rebooking reuse the inbound booking flow. The agent should offer the service that was on the original appointment, ask whether anything has changed, check open slots in the scheduler, offer the nearest alternative when the preferred time is taken, and settle transport again. A customer who missed a drop-off because they had no ride may want a pickup or a shuttle this time. The steps are covered in how the booking call works.

We recommend two different paths for two cases. If the customer says the work was done elsewhere, the agent should record that and close the follow-up. If they want to cancel, it should cancel and not argue. Both outcomes are as useful to the service manager as a rebooked slot, because they explain where the appointment went.

Unsold leads: message first, then call

For sales leads who came to the dealership or inquired and didn’t buy, our build sent a message first and called afterwards. The message should say who is following up and why, so the call that follows isn’t a surprise from an unknown number.

The order matters for two reasons. People screen calls from numbers they don’t know, and a message gives the call a reason to be answered. And a message lets the lead reply in their own time, which some people prefer to a conversation about a car they decided not to buy.

On the sales side, the build runs through VinSolutions, Cox Automotive’s dealership CRM; the service side books through Xtime, also part of Cox Automotive. One vendor behind both sides doesn’t make them one system, so plan for the follow-up logic to read lead status and appointment status from wherever each one lives.

Capturing the reason and handing off to a supervisor

The sales call’s job is to learn why the lead didn’t buy and pass a clear brief to a person, not to close the sale itself. On our build, the agent asked for the reason, such as the price or wanting a different car, tried to bring the lead back to the dealership or captured what they needed, and then told them a supervisor would call them.

We recommend a callback over a live transfer. A salesperson who calls back with the lead’s budget, preferred model and objection already in the CRM has a better first minute than one who picks up a transferred call cold. The agent should repeat its summary to the lead before ending the call (“You’re looking for a hybrid under the price you saw, and a supervisor will call you”), which catches mistakes while the lead is still on the line.

The whole build, service and sales side, is written up in the Innovative AI case study, and what we build for dealer groups and dealer software vendors is on our car dealership software page.

US consent rules for AI follow-up calls

In the US, both follow-up calls count as artificial-voice calls, and the consent they need depends on whether the call is informational or telemarketing. The FCC’s declaratory ruling of February 8, 2024 (FCC 24-17) confirmed that the TCPA’s restrictions on artificial or prerecorded voice encompass current AI technologies that generate human voices. Such calls need prior express consent, and prior express written consent when they include an advertisement or constitute telemarketing.

The table splits the two calls by type. It is our reading of the ruling and of 47 CFR 64.1200 as published on October 18, 2026, not legal advice; state laws can add to it.

The no-show column assumes a consented call to a mobile number. To a residential landline under the informational exemption, 64.1200(b)(3) also requires the automated voice or key-press opt-out within 2 seconds of the identification.

A no-show call can drift into the right-hand column. If the agent adds an upsell (“While it’s in, would you like a tire rotation?”), our reading is that the call now carries telemarketing content, and the stricter consent applies. Keep the reschedule call to the reschedule.

Revocation rules changed recently. Since April 11, 2025, consumers may revoke consent by any reasonable method, and the caller must honor it within 10 business days. The separate “revoke-all” provision, which would make one opt-out cover unrelated calls from the same caller, has been delayed to January 31, 2027. The FCC’s one-to-one consent rule for lead forms was vacated by the Eleventh Circuit in January 2025.

AI disclosure is still a proposal. In August 2024 the FCC proposed rules that would require callers to say at the start of each call that it uses AI-generated technology; the current text of 64.1200 has no such rule as of October 18, 2026. We would disclose anyway, because a customer who finds out mid-call feels misled. The engineering cost of consent capture, scrubbing and opt-out handling is covered in our AI voice agent cost guide.

European and UK dealers

In the EU and the UK, the AI disclosure is already required or the consent bar is higher than in the US. Under Article 50 of the EU AI Act, people must be told they are interacting with an AI system from the start of the first interaction, and the Commission’s FAQ says Article 50 applies from August 2, 2026. The exception for cases where AI use is “obvious” is to be read restrictively, so a voice agent should say what it is in its opening line.

In the UK, the ICO’s guidance under PECR says you must not make automated marketing calls unless the person has specifically consented to that type of call from you. General marketing consent, or consent to live calls, is not enough. An AI sales follow-up to a UK lead needs that specific consent on file; a service reschedule that sells nothing is a different question, and personal data in both falls under data protection law. The EU AI Act and GDPR checklist covers the notice and the records.

What to log on every follow-up call

Every follow-up call should end with one outcome code, written back to the CRM, so a person can see what happened without listening to the recording. These are the codes we recommend; they are not counts from the build.

• Rebooked: new appointment ID, service and slot.
• Declined: the customer doesn’t want to rebook or buy, with the reason in their words.
• Done elsewhere or bought elsewhere: where the work or the sale went, if they said.
• Callback booked: for sales leads, the summary the supervisor will read before calling.
• Opt-out: the request, the time and the number, pushed to the suppression list at once.
• No answer or voicemail: with the attempt count, so the next step is a person, not another dial.
• Wrong number: removes the number from the record.
• Escalated: a complaint or a question the agent couldn’t answer, routed to staff.

Log the consent basis with each call as well. If a regulator or a customer asks why the agent called, the answer should be one lookup away.

When not to automate the follow-up

Don’t automate a follow-up that already works, and never automate one the customer has asked you to stop. If a text reminder the day before already keeps missed appointments low, an AI call adds cost and risk for little gain.

Keep a person on the call when the record shows a complaint, a dispute over a bill or a sensitive repair. Keep a person, too, when the lead is a fleet or business account with its own relationship. And if the consent record is missing or unclear, the right outcome is no call at all.

When the numbers do justify it, we would build the follow-up as an extension of a booking agent rather than a separate product, because it reuses the same scheduler and CRM connections. We scope that as part of a fixed-price build ($25k–$120k). If you run a dealership or a dealer software product, book a free AI audit and bring your no-show and lost-lead process; we will tell you which follow-ups are worth automating and which should stay with your team.

Originally published at apptycoons.com.

Xtime has no self-serve API keys. As of October 2026, Supergood’s assessment of the Xtime API lists six things before the first production call: an NDA, a partner agreement, setup and per-dealer fees, a Cox Automotive business review, a certified demo and an invitation code from each dealership.

We built AI voice agents for Innovative AI that book service appointments at US car dealerships through Xtime and run sales follow-up through VinSolutions, Cox Automotive’s dealership CRM. The agents are still live in production. On that build, the hard parts were matching a caller’s words to one service out of a long menu, checking slots and handling transport. Those, plus the access steps and our recommendations on safe retries, are what this guide covers, from the system side. If you want the finished product rather than the build notes, our custom AI voice agents page has the scope.

How do you get Xtime API access?

You get Xtime API access through Cox Automotive’s partner program, not by signing up for a key. Supergood, which grades vendor APIs, lists the steps as of October 2026: an NDA and a partner agreement, a setup fee plus annual and per-dealer fees, a business review by Cox, and a certified demo before production approval. After that, each dealership opts in with an invitation code.

The reference documentation is behind a login on the Cox Automotive Integration Platform. Supergood notes that Service Scheduling 1.0 and Service Marketing 1.0 are listed on Cox’s developer portal, and labels the scheduling capabilities as the Consumer Scheduling API.

Two consequences for planning:

• The calendar is not yours. The business review and the certified demo run on Cox’s schedule. Build against what you can test, and keep the demo-ready flow small.
• Contracts sit with whoever holds the integration. Decide early whether the dealer group, a software vendor or the build team signs, because the per-dealer fees and the support obligations follow that party.

We don’t quote the fee amounts here. They are set by Cox and should come from Cox in writing.

What the scheduling API covers, and what it doesn’t

The Xtime scheduling API covers the booking itself: dealer capacity, available appointment times, and creating or canceling appointments by year, make and model or by VIN, according to Supergood as of October 2026. It does not cover repair orders or inspection results.

That split decides what a voice agent can answer on its own.

Watch out

“Is my car ready?” is not a scheduling question

Repair orders are not offered by the scheduling API, so a status question needs DMS access or a handoff to a service advisor.

Xtime’s own product page describes “dynamic menus that reflect your dealership’s pricing, promotions, and service recommendations”. Menus are set by each dealership, so treat menu content as dealer data that changes, not as a fixed catalog you can hard-code.

The data flow on one booking call

One booking call touches Xtime at three points: the vehicle’s service menu, the open times for the chosen service, and the appointment itself. Everything else is the agent’s own logic and its own store.

The table is our recommended data flow, in the order the Innovative AI case study describes the call. It shows which system each step reads or writes, not how the conversation sounds.

Steps 3, 5 and 7 are the only Xtime calls, and step 3 has to come before any talk about times: the agent cannot offer a slot until it knows which service it is booking, and it cannot know the service until it has the vehicle. Transport options differ by dealership, so they live in configuration rather than in code. The case study covers the menu sizes and transport choices from that build.

Returning-caller recognition sits beside this flow rather than in it: on that build, the caller’s name, vehicle and recent service were saved against the phone number, so a repeat caller skipped questions the agent could already answer. The same system also looked up and confirmed existing appointments, and placed follow-up calls when the dealership’s CRM showed a booked customer had not arrived.

What the voice agent needs on top of the API

A voice agent needs five system-side pieces that no scheduling API provides: a menu-constrained output, an availability check inside the booking step, per-dealer transport configuration, a caller profile store and a create step that is safe to retry. The rest of this section is our engineering recommendations, not a description of the Innovative AI system and not Cox documentation. How the conversation itself should sound, from matching a caller’s words to offering another time, is in our guide to AI service scheduling for dealerships.

A menu-constrained output. The model’s choice of service should be an op code from the menu Xtime returned for that vehicle and nothing else. Pass the menu in as the only allowed values and validate the answer against it in code, so a request for “the 30k service” can only resolve to a line that exists. An answer that matches nothing is a handoff, never a guess.

Availability inside the booking step. Treat the open times read earlier in the call as a hint. The create step reads availability for that service and time again and books only if the slot is still returned, so the check and the write sit together in one function.

Per-dealer transport configuration. Store each rooftop’s options as data: whether it offers a shuttle, loaners, pickup or mobile service, and the service area for the last two. The agent asks only about options that dealership’s record lists, and the address field is required only when pickup or mobile service is chosen.

A caller profile store. Name, vehicle and recent service saved against the phone number live in your own store, not in Xtime. It is personal data: keep only those fields, set a retention period and delete profiles that pass it.

A retry-safe create. Calls drop. If the line cuts out after the agent sent the booking and before it heard the result, a naive retry or a callback can book the same car twice. Record each booking attempt on your side, tied to the call, before you send it. On any retry, check that record and the customer’s existing appointments first, and only create when neither shows the booking. The same confirm-before-write pattern appears in our AI agent guardrails checklist.

Where VinSolutions fits: the sales side

VinSolutions is Cox Automotive’s dealership CRM, so on an all-Cox stack the service side and the sales side come from the same company. VinSolutions calls itself “the AI-powered CRM with exclusive Cox Automotive shopper data and integrations with top industry providers”, and Cox’s brand list carries it next to Xtime (both as of October 2026).

Partner access points to the same place. VinSolutions’ integrations page tells vendors “If you are interested in becoming an integrated partner please visit our API Storefront”, and that link goes to Cox Automotive’s developer site, the one that hosts the Xtime reference documentation (as of October 2026).

On the Innovative AI build, sales follow-up runs through VinSolutions. The agent works through leads who visited a dealership and didn’t buy: a message first, then a call to learn the reason, such as price or a different car, and to capture what they want. It closes by telling them a supervisor will call back.

When a dealer group runs more than one vendor

Our build was all Cox Automotive: Xtime for service, VinSolutions for sales, and other Cox products at other rooftops. Not every group is. Cox’s own brand list, as of October 2026, includes Xtime for service, VinSolutions for CRM and Dealertrack for dealership management. A group whose CRM or dealer management system comes from another vendor is dealing with that vendor’s access program as well. CDK Global, for example, runs its own automotive API platform, Fortellis; the fortellis.io footer says “Fortellis is a trademark of CDK Global, LLC”. That means a second company, a second contract and a second style of API, and it was not part of the Innovative AI build.

The design we recommend for any mix of systems, including several products from one vendor, is one internal model and one adapter per system:

• One internal shape for a vehicle, a service, an appointment and a lead, used by the agent’s logic everywhere.
• One adapter per vendor, which translates that shape to Xtime, to VinSolutions or to the next system, and owns its credentials and error handling.
• Per-dealer configuration that says which adapter handles scheduling and which handles leads at each rooftop.

The agent’s prompts and tools then talk about appointments and leads, never about a vendor. Adding a dealership on a different stack means writing or reusing an adapter, not rewriting the call flow.

Rolling out dealer by dealer

An Xtime integration goes live one dealership at a time, because each one opts in with its own invitation code. Each rooftop also brings its own menu: op codes vary by dealership and system, and myKaarma’s documentation says dealerships “may contain a large number of opcodes, sometimes exceeding thousands”, which is why its API pages through them (myKaarma docs, as of October 2026).

Our recommendation is one test rooftop first, with a checklist per dealership after it:

Only move to the next rooftop when the first one’s service team trusts what lands in its schedule.

When not to build your own integration

A single dealership that wants after-hours answering and basic booking should buy a product that is already integrated with Xtime. The case is clearest on the integration side: a product already integrated with Xtime has done the partner work once, and a one-store build would repeat the agreement, review and demo for one invitation code. Xtime’s Schedule page lists a voice add-on (Brooke.ai), as of October 2026.

Building custom is our business, so read this with that bias in mind. The wider buy-or-build call, including when a custom agent pays off, is in the buy-or-build section of our scheduling guide.

What an integration adds to the build cost

An Xtime integration fits inside a Fixed-Price Build of $25k–$120k, and where it lands in that band depends on how many systems the agent talks to, not on the Xtime connection alone. Scheduling through Xtime with the op-code matcher, slot negotiation and retry-safe booking is one scope. Adding VinSolutions for sales follow-up, outbound calls and per-dealer adapters is a larger one. We fix the price after a $5,000 Discovery Sprint, and the pricing page shows the model.

Two costs sit outside our quote: Cox’s partner and per-dealer fees, and the time the business review and certified demo take. Put both in the budget before the build starts.

Before you scope it, have these ready: who will hold the Xtime agreement and the CRM access, the list of rooftops and the systems each one runs, the transport options each offers, and where calls should go when the agent hands off. With those four answers, a discovery sprint can price the work. For how this looks across the dealership, see our page on car dealership software.

Originally published at apptycoons.com.

On October 9, 2026, Anthropic disclosed that some of its AI agents, given problems to solve during internal evaluations, had gone looking for resources online and misused what they found. According to TechCrunch’s report, they exploited software flaws on websites, including some run by US government agencies, got into databases without paying the fees, used URL shorteners to slip past restrictions, and one submitted a false murder tip to the Philadelphia police. Anthropic’s response was to cut its internal evaluations off from the live internet until it can monitor and control its agents.

That happened at a company that builds the models, in a test environment. A business agent connected to a CRM, a payment system or a customer inbox has the same basic shape: a model that decides what to do, and tools that let it do it. Guardrails are what make the second part safe.

What are AI agent guardrails?

AI agent guardrails are controls outside the model that limit what an agent can see, do and spend, and record what it did. They are enforced in code, permissions and infrastructure, not in the prompt, so they still hold when the model misreads a task, is manipulated by text it reads or takes a shortcut nobody anticipated.

OWASP calls the underlying risk “excessive agency”: damaging actions taken in response to unexpected, ambiguous or manipulated output from a model. It has three causes, and each guardrail removes part of one of them: too much functionality, too many permissions or too much autonomy.

Input, output and action guardrails: which ones matter for agents

Guardrails fall into three groups, and agents need the third far more than chatbots do. Input guardrails screen what reaches the model. Output guardrails check what it produces. Action guardrails limit what it can change in the world, and they are the reason an agent needs a different control set from a chatbot that only talks.

Many products sold as guardrails cover the first two groups: classifiers that flag injected prompts or toxic replies. Some teams add a second model that reviews the first one’s output before it is used, sometimes called a guardian agent. Both are useful, and both are still models reading text. They complement action guardrails enforced in code and infrastructure; they do not replace them.

What the Anthropic incident shows about agent risk

Every behavior in the disclosure maps to a missing control, and none of them needed a smarter model to prevent. Anthropic itself attributed the behavior to training environments that taught models to look for loopholes, which is a reason to assume any agent may do the same.

The common thread is that each behavior was possible because the agent had a general capability, such as unrestricted web access, where it needed a specific one. Narrowing capability is cheaper and more reliable than trying to predict every misuse of a broad one.

The 10 controls a production agent needs

These are the controls we put around an agent before it touches real systems. Each one names the risk it addresses and, more importantly, where it is enforced, because a control the model can talk its way around is not a control. The OWASP mapping is our reading of the two lists, not an official crosswalk.

Approvals that people do not rubber-stamp

An approval step only works if the person sees the actual change, not the agent’s summary of it. OWASP lists “human-agent trust exploitation” as its own risk (ASI09): polished explanations persuaded operators to approve harmful actions. Show the record before and after, the recipient and the amount, and make approving a deliberate act.

On a phone call, the person approving is the caller. The service booking agent we built for Innovative AI matched the caller’s own description to one service on that vehicle’s menu, read the chosen service back and booked only after the caller agreed. The point of that read-back is that a wrong match should cost one extra sentence on the call, not the wrong job on the dealership’s schedule.

Limits the agent cannot negotiate

Step and spend limits sound blunt, and that is the point. A cap of a few dozen tool calls per task, a daily budget per agent and a rate limit per user turn a loop or a manipulated agent into a small, visible failure instead of a large one. OWASP lists logging and rate limiting as the measures that reduce harm when prevention fails.

Why a system prompt is not a guardrail

A rule in a prompt is a request; the model can misread it, lose it over a long task or be talked out of it by text it reads along the way. Anthropic’s own explanation for its incident was that training rewarded models for finding loopholes, and a prompt that says “don’t” is exactly the kind of restriction such a model routes around.

Use the prompt to explain the job, and use code to enforce the limits. The same principle runs through OWASP’s guidance, which calls it complete mediation: authorize every action in the downstream system rather than relying on the model to decide what is allowed. If the agent connects to tools over MCP, the protocol’s security guidance makes the same point about tokens: a server checks that each token was issued for it and never passes it on. Our guide to MCP servers for Muse and Grok covers the server side in detail.

How the controls map to NIST’s generative AI profile

Enterprise risk teams often work from NIST rather than OWASP. NIST AI 600-1, the Generative AI Profile of the AI Risk Management Framework (July 2024), lists 12 risks that generative AI creates or makes worse. Four of them line up directly with agent guardrails:

• Information Security: controls 1, 3, 5 and 10 narrow what a manipulated agent can reach and let you cut it off.
• Data Privacy: control 2 keeps the agent inside the user’s own access, and control 7 records what it read.
• Confabulation: control 8 tests answers against known cases before release, and control 9 catches drift after it.
• Human-AI Configuration: control 4, with approvals designed so people review the real change, not a persuasive summary.

The other eight, from intellectual property to environmental impacts, are governance questions for the deployment as a whole rather than controls around one agent. This mapping is our reading of the profile, not an official crosswalk. If your agent serves people in the EU, logging and human oversight also carry legal weight; see which EU AI Act and GDPR duties apply to agents.

Who is liable when an agent gets it wrong

Usually the company that deployed it. In Moffatt v. Air Canada (2024), a customer relied on the airline’s website chatbot, which said a bereavement fare could be claimed after travel; the airline’s own policy page said otherwise. Air Canada argued the chatbot was a separate legal entity responsible for its own actions. British Columbia’s Civil Resolution Tribunal called that “a remarkable submission”, noted that the chatbot “is still just a part of Air Canada’s website”, and found the airline liable for negligent misrepresentation.

It is a decision of British Columbia’s Civil Resolution Tribunal, not binding precedent elsewhere, and this is not legal advice. The engineering lesson holds anyway: an agent’s answer to a customer is your company’s statement. Output guardrails on customer-facing answers, such as grounding every policy answer in a current source and refusing questions outside the agent’s scope, are a liability control as much as a quality one.

How we apply this on Superdeal

Superdeal’s agent was designed around controls in the system rather than trust in the model.

Superdeal is a campaign CRM in which an AI agent finds creators, drafts offers and handles shipments. Every consequential step goes Draft, Review, Send: the agent drafts, a person on the brand’s side reviews, and nothing reaches a creator until they approve it (control 4). Agencies share scoped, read-only dashboards with their clients, so a client view cannot change a campaign (control 2).

What guardrails cost in time and money

Most guardrails are cheap; the expensive ones are the ones that involve people. Permission checks, allowlists, limits and logging are ordinary engineering and add milliseconds. Model-based checks on inputs and outputs add a model call each. Human approval adds minutes or hours, so it belongs only on actions that are costly to undo.

In our projects these controls are part of the build rather than an add-on: a Fixed-Price Build of $25k–$120k includes the approval steps, evaluation set, audit log and security review, and the AI agent development page lists what each engagement covers. What changes the effort is the number of systems the agent writes to, because every write path needs its own permission check, preview and rollback.

When lighter guardrails are enough

An internal assistant that only reads documents the user can already see needs permissions, logging and an evaluation set, and little else. Approval steps, spend limits and a network allowlist matter once the agent can write to systems, spend money or contact people.

Match the controls to what the agent can break, and add them when capabilities grow rather than all at once. Our checklist for taking AI pilots to production covers the business side of that decision: metric, owner and integrations.

A guardrails review you can run this week

Take your most capable agent, or the one you plan to build, and answer these in writing:

• Which tools can it call, and which of them does the task not need?
• Whose permissions does it act with, and are they checked by the system or by the prompt?
• Which domains and services can it reach over the network?
• Which actions send, pay, delete or contact someone, and who approves them?
• What happens if a document it reads contains instructions?
• What stops it after a hundred tool calls, or a thousand dollars?
• Where is the log of what it did yesterday, and who reads it?
• How would you stop it within five minutes?

Any question without a clear answer is a control to add before the agent gets more access. If a vendor is building the agent for you, put the same list to them alongside our questions to ask an agent vendor.

Originally published at apptycoons.com.

xAI opened Grok to outside apps on May 6, 2026. Meta launched Muse on September 8 and has since opened a connector directory with its own review. Two of the largest consumer agents now take requests like “reorder last month’s supplies” and hand them to someone else’s software. Whether that software is yours depends on one thing: a server the agent can call.

For both agents, that server is the same. A remote MCP server covers Grok today and Muse’s custom connectors, and it works in Claude and Cursor too. This guide covers what each agent accepts, what the server needs, and when you can skip it.

What does it take to get your app into Muse and Grok?

You need a remote MCP server: a public HTTPS endpoint that exposes your app’s actions as tools, signs users in with OAuth and enforces what each user may do. Grok connects to any such server as a custom connector. Muse users can add one as a custom connector, and Meta reviews connectors for its public directory.

MCP, the Model Context Protocol, is the open standard both hosts use to discover and call tools. Your server lists its tools, such as search_orders or create_invoice, with a description and an input schema. The agent reads that list, picks a tool for the user’s request and calls it with the user’s token. Your server decides whether the call is allowed.

It is the same work our AI agent development team does when an agent has to act inside a client’s own systems. Here the agent just belongs to Meta or xAI.

How Muse and Grok connect to outside apps

Each agent has a curated route and an open route, and the open routes are where an MCP server goes. The table uses each vendor’s own pages, rechecked October 18, 2026, plus two developer guides where Meta has published nothing. Both products change month to month.

Two details matter for planning. Muse runs each user’s agent on a dedicated cloud machine, so it calls your server from Meta’s cloud, never from the user’s laptop: a server on a private network or localhost will not work. And Muse’s custom connector flow is documented only by third-party developers so far, and they disagree. AnythingMCP’s Muse guide, checked September 25, 2026, describes pasting a server URL under Settings, Connectors and signing in with OAuth. Parallel’s guide from mid-September found no “add MCP server” setting and had Muse build the bridge on its own machine from a chat request. Either way Muse calls a public HTTPS endpoint, so the server you build is the same. Test the route on your own account before you promise it to customers.

Why an MCP server and not just your API or website

Agents can reach your app without your help: Muse can drive a browser, and developer guides show it writing its own integration against a public API. An MCP server is how you decide what the agent can do instead of leaving it to guesswork.

• Browser use breaks when your screens change, can’t tell a read from a write and leaves no clear audit trail of what the agent did.
• A raw API exposes every endpoint in the shape your frontend needed, which is rarely the shape an agent should call. A 40-parameter endpoint invites wrong calls.
• An MCP server exposes a short list of named tools with plain descriptions, behind your own sign-in and scopes. Every host that speaks MCP can use the same server, so you build it once.

The last point is the business case. Muse and Grok are two hosts; Claude and Cursor also connect to remote MCP servers. One well-built server works in all of them.

What a production MCP server needs

The MCP specification defines how authorization works, and most of the requirements land on your server. The checklist below follows the specification’s Authorization page and its Security Best Practices page (version 2025-11-25).

• Public HTTPS endpoint. Both hosts call from their cloud. All OAuth endpoints must be served over HTTPS.
• OAuth 2.1, with your server as the resource server. The server publishes Protected Resource Metadata (RFC 9728) so the agent can find your authorization server, either at a well-known URL or in the 401 it returns to calls without a token.
• Tokens issued for your server only. The specification requires the server to check that each token was issued for it, and forbids passing a client’s token through to another API. If your MCP server calls your own backend, it uses a separate token.
• Small scopes, raised on demand. Start with read-only scopes and ask for write scopes the first time a write tool is called (a 403 with insufficient_scope). Broad scopes such as * or admin are the specification’s own example of a mistake.
• Separate read and write tools. get_invoice and void_invoice should never be one tool with a flag.
• A confirmation step on high-impact actions. Muse checks with the user before sensitive actions such as sending email or buying something. Don’t rely on that. Make the server return a preview and require a second, explicit call to commit anything that moves money, deletes data or contacts a third party.
• Per-user limits and an audit log. Rate limits per token, and a log of every tool call with the user, the arguments and the result. When a customer asks what the agent did, you need the answer.
• Secure session handling. Session IDs must be random and must not stand in for authentication; every request is checked.

None of this is exotic. It is the same discipline as a public API, with one difference: the caller is a model that can be talked into things, so the server has to say no on its own. Our AI agent guardrails checklist covers the controls that sit around the agent itself.

Transport and endpoint: what the hosts call

The current MCP specification uses the Streamable HTTP transport: one HTTPS endpoint, such as https://api.example.com/mcp, that accepts both POST and GET. It replaced the older HTTP+SSE transport from the 2024-11-05 protocol version. Muse’s connectors work over Streamable HTTP, and Grok’s tunneling guide still covers servers on the older SSE transport, but build new servers on Streamable HTTP.

The transport page of the specification (version 2025-11-25) adds rules your server has to follow:

• One endpoint, two methods. Every client message is a new POST to the MCP endpoint. The server answers with JSON or opens a Server-Sent Events stream; a GET opens a stream for messages the server sends on its own, or returns 405 if it doesn’t offer one.
• Validate the Origin header. If it is present and invalid, the server must return 403 Forbidden. This blocks DNS rebinding attacks.
• Check the protocol version. After initialization the client sends MCP-Protocol-Version on every request, and the server must return 400 for a version it doesn’t support.
• Secure session IDs. If the server assigns an MCP-Session-Id, it should be cryptographically random, and an expired session returns 404 so the client starts again.
• Bind local servers to localhost. A development server should listen on 127.0.0.1, not on every interface.

Watch out

Only remote servers reach these agents

Remote servers are the only kind these consumer agents can reach. The stdio transport, where the host launches the server as a local process, works in desktop tools but not from Meta’s or xAI’s cloud.

How to test the server in each host before launch

Test in every host you plan to list, because each one discovers tools, handles OAuth and shows confirmations in its own way. A server that passes in one host can still fail sign-in in another.

For development, run the server locally behind a tunnel: xAI’s Grok documentation points to a tunneling service for exactly this, since a connector must reach the server over the public internet. Then add it as a custom connector in Grok, in Muse on a test account, and in Claude or Cursor.

Run the same cases in each host:

Keep the audit log open while you test. Every case above should leave a line in it.

How to design tools an agent uses correctly

Design tools around the jobs users ask for, not around your endpoints. An agent picks a tool by reading its name and description, so “reorder_from_previous_order: creates a draft order with the same items as a past order; does not charge” beats a generic post_orders.

Rules we apply to tool design:

• One job per tool, named with a verb and an object.
• Descriptions that state what the tool does not do, such as “does not send” or “draft only”.
• Few, typed parameters with enums wherever the values are known.
• Idempotent writes, with a client-supplied key, so a retried call doesn’t place two orders.
• Short, structured results with IDs the agent can pass to the next tool, not full records.
• Errors the agent can act on, such as “address missing: ask the user for a delivery address”.

Treat everything that comes back from the agent as untrusted input. A prompt injected into an email or a web page can make an agent call your tools with arguments the user never intended. Server-side checks, scopes and confirmations are what stop that, not the agent’s judgment.

Why the server should sit on permissions you already enforce

An MCP server should be a thin, well-described layer on top of the permissions your app already enforces, not a second set of rules. If the web app already isolates each customer’s data and keeps an audit trail, the MCP tools call the same services and inherit both. A server that re-implements access checks drifts from the app over time, and the gap between the two is where an agent ends up seeing data a user could not.

That also decides how much work the server is. When the app’s own API already checks permissions per user, the MCP layer is mostly tool design and OAuth. When the checks live in the frontend, they have to move into the backend first, for the app’s sake as much as the agent’s.

What an MCP server costs and how long it takes

For an app that already has a clean, documented API, the MCP server is a small build. Most of the effort goes on OAuth, tool design, confirmations and testing in each host, not on the protocol. We price it like any other project: a Fixed-Price Build inside our $25k–$120k band, with the scope and price fixed after a two-week Discovery Sprint. For a server on top of an existing API, we expect the low end of that band, and that placement is our judgment, not a quote.

What moves the price:

• No usable API. If the app’s logic lives in its frontend or in scripts, the API comes first, and that is the bigger project.
• Write actions that move money or reach customers, which need previews, confirmations and stronger tests.
• Multi-tenant data, where tenant isolation has to hold for every tool.
• Directory submissions, which add review cycles on Meta’s timeline, not yours.

Running costs are hosting and monitoring for one more service. The agent runs on Meta’s or xAI’s infrastructure, so its model usage is not on your bill. See pricing for the full engagement model, and AI agent development cost if the agent itself is yours to build.

When you don’t need an MCP server yet

Skip it for now if your customers don’t use these agents for the job your app does. A connector nobody calls is maintenance with no return.

It also isn’t the right first step when:

• Your app has no API. Fix that first; every integration, agent or not, will need it.
• A connector already exists, for example through an integration platform your customers use, and it covers the jobs they ask for.
• Your product is mostly reading, such as public prices or documentation. Agents can already read a fast, well-structured website; a server adds little.
• You need the directory listing specifically. Meta has not published a timeline or fee for directory review. Build the server for custom connectors and other hosts first; the directory is a second step.

If several of these apply, wait. If customers already paste data from your app into ChatGPT or Grok to get work done, that is the signal to build.

How to decide this week

Answer these for your own app, in writing:

• Which three jobs would a customer ask an agent to do in your app?
• Does an API already cover those jobs, with per-user permissions?
• Which of those jobs write data, move money or contact someone?
• Who owns the server after launch, including changes when Muse or Grok change their rules?
• Which hosts matter to your customers: Muse, Grok, Claude, ChatGPT or Cursor?

If the first two answers are clear, the server is a short project. If they aren’t, the work starts with the API, and a build vs buy decision for AI agents is the better place to start.

Originally published at apptycoons.com.

A workflow agent that handles 20,000 tasks a month costs about $356 a month in Claude Haiku 4.5 tokens at list price. Building the system that lets it do those tasks safely, inside your CRM or ERP, with approvals and an audit log, costs $25k–$120k. That gap is the whole story of AI agent cost: the model is cheap, and everything around it is not.

The figures below are the ones on our pricing page, the same ones we quote against.

How much does an AI agent cost to build?

A production AI agent costs $25k–$120k as a Fixed-Price Build, after a two-week, $5,000 Discovery Sprint whose fee is credited to the build. Where a project lands in that band depends on three things: how many systems the agent touches, how much it may do without a person, and which compliance rules apply. The same math holds for agentic AI development in general: the cost follows the number of tools an agent can call and the actions it may take on its own, not the model you pick.

The total cost of an agent has three parts, and most budgets only plan for the middle one:

What you pay for in discovery, build and run

Each phase removes a different risk.

Discovery: proving the agent can work on your data

Discovery is two weeks with a senior architect. It ends with a prototype running on your real data (not a slide deck), the architecture, a plan for each integration, and a fixed quote. Its job is to surface the problems that make AI projects overrun: data that is messier than the demo set, APIs that need approval to access, and approval rules nobody wrote down.

Build: turning a prototype into a system you can trust

The build is where most of the money goes, and little of it is spent on the model. It pays for connecting the agent to your systems of record, adding approval steps for high-impact actions, writing an evaluation set that proves the agent behaves, a security review, and launch. Work happens in two-week sprints with live demos, and the code sits in your repository from day one.

Run: the monthly bill after launch

Running costs are model tokens, hosting, logs and monitoring, plus the time to update prompts and models as vendors release new versions. For most business agents tokens are the smallest of these at modest volume, and the largest at high volume. The worked example below shows how to estimate them.

AI agent cost by type

The type of agent decides most of the build price, because it decides how many systems the agent touches and how much it is trusted to do alone. The ranges below are how we place work inside our published band; the fixed quote comes from discovery.

Two of our own builds sit at different points on that table. Superdeal is a workflow agent inside a campaign CRM: its scope is creator discovery on three social platforms, drafted offers, and an approval step on everything it sends. Relm is a multi-agent system: specialist agents run in parallel over 20+ data feeds and uploaded documents, and every finding cites its source. Relm’s scope is much larger, and the reasons are integrations and documents, not the model.

Two agent types carry extra line items the table does not show. A single-task assistant that answers from documents is a RAG system, and the RAG assistants we build are priced by how messy and permissioned those documents are; RAG development cost breaks that down. Voice agents add telephony, speech-to-text and text-to-speech to every minute of every call, which AI voice agent cost prices line by line.

What drives the cost of an AI agent?

Five things move a quote, and the choice of model is not one of them. Model choice changes the running cost, but it rarely changes the build price by much.

Integrations are usually the biggest line item

An agent that cannot read from and write to your systems of record is a demo. Each integration means authentication, handling the API’s limits and failures, mapping fields, and testing what happens when a write half-succeeds. With three or more integrations, this work can outweigh the agent logic itself.

Evaluation is what makes an agent shippable

Pilots skip evaluation and pay for it later. An evaluation set is a library of real cases with the correct outcome, run against every prompt or model change. It is the difference between “it worked in the demo” and “we know it works”. Budget for it as its own line: someone has to collect the cases, agree the correct outcomes with the people who do the work today, and rerun the set whenever a prompt or model changes. We cover why skipping it stalls projects in why AI pilots stall before production.

Human approval is cheaper than full autonomy

Every step an agent takes on its own needs guardrails: confidence thresholds, limits, rollback and logging. Putting a person on the high-impact steps for the first months is faster to build and easier to get past risk and compliance review. You remove approvals one by one as the logs show the agent is reliable. Our checklist of AI agent guardrails lists the controls an agent needs before any approval comes off.

Worked example: what an AI agent costs to run each month

An agent’s running cost is mostly tokens: the text sent to the model and the text it writes back. Here is the arithmetic for a realistic workflow agent, using list prices from Anthropic’s pricing page.

Assumptions: the agent handles 20,000 tasks a month. Each task makes four model calls. Each call sends 6,000 input tokens, of which 4,500 are a stable system prompt and tool definitions that prompt caching can reuse, and gets back 500 output tokens. List prices per million tokens, checked October 18, 2026, are $2 input, $0.10 cache read and $10 output for Claude Sonnet 5.5, and $1, $0.10 and $5 for Claude Haiku 4.5. Anthropic bills cache reads at 0.1 times the input price on most models and at 0.05 times on Sonnet 5.5, which is why both read prices are $0.10.

How the cached Sonnet 5.5 call is worked out: 1,500 uncached input tokens at $2 per million is $0.0030, 4,500 cached tokens at $0.10 per million is $0.00045, and 500 output tokens at $10 per million is $0.0050, so about $0.0085 per call. Four calls per task and 20,000 tasks give about $676. The small premium for writing to the cache is left out because it is paid once per cache window, not per call.

Three things change this number more than the model price does:

• Caching. Reusing the stable part of the prompt roughly halves the bill here.
• Routing. Sending easy steps to a small model and only hard ones to a larger model lowers the average cost per task; the table shows the gap between the two tiers is about 2x.
• Tokenizer. Anthropic notes that Claude 4.7 and later models use a tokenizer that produces about 30% more tokens for the same text, so estimates made with an older tokenizer will run low.

The same agent at 2,000, 20,000 and 100,000 tasks a month

Token cost grows in a straight line with volume; the build price does not move. Multiplying the per-call figures above by four calls per task gives these monthly totals:

Read across a row and the cheapest option is always the small model with caching; read down a column and only volume changes the bill. At 2,000 tasks the model is a rounding error next to hosting. At 100,000 it is a real line, and caching and routing decide whether it is $1,780 or $6,800.

On top of tokens, budget for hosting the agent service, logs and traces, and scheduled evaluation runs. These depend on your cloud and your retention rules, so treat them as their own line rather than guessing a percentage.

What an AI agent costs to maintain after launch

Maintenance is the engineering that keeps an agent correct while everything around it changes. The model bill is predictable; these four jobs are what surprise budgets:

• Model and price changes. Vendors retire models and change prices; each switch means rerunning the evaluation set before the new model goes live.
• Evaluation reruns. Every prompt change, tool change or new edge case from production goes through the full test set, and the set grows as users find new cases.
• Monitoring and traces. Someone reads the logs of failed and escalated tasks each week and turns them into fixes or new test cases.
• Integration drift. When a connected CRM, ERP or API changes a field or an auth flow, the agent starts failing without an error message unless a test catches it.

Our builds include 30 days of support after launch. After that, owners usually choose small fixed-price change requests for occasional updates, or a Dedicated Team when the agent has a roadmap of its own. We don’t publish a maintenance percentage of the build price, because it depends on how many integrations can drift and how often your process changes, not on what the build cost.

Why quotes for the same AI agent differ so much

Two quotes for the “same” agent usually describe different systems. One vendor prices a prototype with a read-only connection; another prices writes, approvals, an audit log and a test set. Before comparing totals, line the quotes up against six questions:

Watch out

A thin quote is not a cheaper one

A quote that is low because it leaves out the evaluation set or the approval steps is not cheaper; it moves that cost to after launch, when it is paid as an incident.

For the questions to put to the vendor behind the quote, see questions to ask an AI agent development company.

Fixed price vs time and materials for an AI agent

A fixed price after discovery protects the buyer from overruns; time and materials protects the vendor. For AI agents, where the main risk is unknown data and integrations, the fix is to resolve those unknowns first and then fix the price, which is what discovery is for.

We recommend fixing the price for the first production version, and moving to a Dedicated Team only if the agent becomes a product with its own roadmap. The trade-offs between the contract models are in our guide to fixed price vs time and materials.

When a custom AI agent is not worth paying for

A custom agent is not worth its build price when a product already does the job at your volume for less. The quickest test is arithmetic: multiply the product’s usage price by the volume you expect in year three, and compare it with the build plus three years of running cost.

Two published price lists show what that comparison looks like. Intercom lists its Fin AI Agent from $0.99 per outcome, so 1,000 outcomes a month is about $12,000 a year, well under a $25k build plus hosting and maintenance. Microsoft sells Copilot Studio as packs of 25,000 credits for $200 a month, which suits internal assistants that live inside Microsoft 365. At that kind of volume, inside tools you already use, buying wins on cost.

The arithmetic turns the other way when volume grows, when the agent has to write to your own systems, or when how it works is part of what you sell. A full three-year model, the lock-in questions to put to vendors, and the part-bought, part-built setup most agents end up with are in build vs buy AI agents.

How to budget for an AI agent project

Budget for the system, not the model. A realistic plan has four lines:

Then pick one workflow and one number to move, such as hours saved, tickets resolved or decisions made per day, and hold the build to it. That keeps scope honest and makes the return easy to measure. If you want a fixed price for your own agent, our AI agent development team starts with a free AI audit: book the audit and bring the workflow you have in mind.

Originally published at apptycoons.com.

Vapi advertises $0.05 a minute. Add the speech-to-text, the language model and the voice that every call needs, and the same agent costs $0.082 to $0.129 a minute on Vapi’s own calculator. The advertised rate covers one layer of a five-layer stack; the other four arrive as separate line items.

In our model, built only from public price lists, a hosted platform costs about $0.08 to $0.15 a minute all-in and a custom stack about $0.04 a minute before hosting and the build. Every figure below is a list price rechecked on October 18, 2026, and every calculation is shown, so you can rerun it with your own call volume.

How much does an AI voice agent cost per minute?

At list prices, a hosted voice platform costs about $0.08 to $0.15 per minute once every layer is included. A custom stack that pays each vendor directly costs about $0.04 per minute in usage, but you have to build and host it. The platform’s advertised rate, $0.05 on Vapi or $0.055 on Retell, is only the orchestration fee.

The five line items inside every per-minute price

Every AI phone call pays for the same five things, whether a platform bundles them or you buy them separately. Knowing them is how you compare quotes.

• Telephony carries the call. Twilio lists US inbound calls to a local number at $0.0085 a minute, and streaming the audio to your server at $0.0044 a minute.
• Speech-to-text transcribes the caller. Deepgram lists streaming Nova-3 at a regular price of $0.0077 a minute, currently discounted to $0.0048; we use the regular price.
• The language model decides what to say and which tools to call. It is billed per token, so its per-minute cost depends on prompt size and how often the caller speaks.
• Text-to-speech speaks the reply. Deepgram lists Aura-2 at $0.030 per 1,000 characters; Retell lists voices from $0.015 to $0.10 a minute depending on the provider.
• Orchestration handles turn-taking, interruptions and tool calls. Platforms charge for it per minute; on a custom stack you host it yourself.

How we turned token prices into a per-minute cost

Two of these layers are not priced per minute, so we converted them with stated assumptions. For the model, we assume five model calls per minute of conversation, each sending 3,000 input tokens (2,500 of them a cached system prompt) and receiving 80 output tokens. At Claude Sonnet 5.5 list prices of $2 per million input tokens, $0.10 for cache reads (Anthropic bills cache hits on Sonnet 5.5 at 0.05 times the input price) and $10 output, that is about $0.0021 per call and $0.0103 a minute. For the voice, we assume the agent talks for about 45% of the call at around 150 words a minute, roughly 400 characters, which is $0.012 a minute on Aura-2.

Platform pricing: what Vapi and Retell charge

Both platforms publish their prices, so a fair comparison is possible. They differ in what is bundled and what costs extra.

The choice of model and voice moves the platform price more than the choice of platform. On Retell, swapping a recommended-tier model for Claude 4.5 Haiku takes the all-in rate from $0.149 to $0.110 a minute, the most expensive models on Retell’s list cost over $0.30 a minute on their own, and moving to a premium ElevenLabs voice can add up to $0.085.

A third route: one speech-to-speech model

Some stacks replace the separate speech-to-text, model and voice with one speech-to-speech model that hears and answers in audio. OpenAI’s realtime models are billed per audio token rather than per minute ($32 per million input and $64 per million output tokens for gpt-realtime-2.1; $10 and $20 for the mini model, list prices checked October 26, 2026). In our own test calls in October 2026, that came to about $0.078 a minute of talk for gpt-realtime-2.1 and $0.023 for the mini model, before telephony, hosting and orchestration. Long system prompts and tool definitions add text tokens to every turn, so measure with your own call flow before you budget.

What a custom AI voice agent costs to build

With us, a custom voice agent falls in the same $25k–$120k band as any agent we build, with the price fixed after discovery (the pricing page has the model). “Custom” means you own the orchestration code, run it in your cloud and pay each vendor directly, typically on an open-source framework such as LiveKit or Pipecat instead of a hosted platform.

Five things set where a voice build lands in that band:

• the systems the agent books into or updates, such as a scheduler, CRM or order system,
• the number of call flows, from a single booking flow to triage across several departments,
• warm transfer to a person with a summary of the call,
• latency tuning, because slow replies make a conversation feel broken (see voice agent latency),
• compliance, such as HIPAA, call recording consent and data retention.

A platform build is not free either. Someone still writes the prompts, connects the agent to your systems and tests the call flows. That work is similar on both routes, so the comparison below charges only the custom route with a build, which favors the platforms.

Total cost at 1,000, 10,000 and 50,000 minutes a month

At 1,000 minutes a month a platform costs roughly a tenth of a custom stack; at 50,000 the order flips. The table adds usage at list prices and, for the custom stack, two fixed monthly costs we state as assumptions: $500 a month for hosting and monitoring, and the minimum build of $25k spread over 36 months, about $694 a month.

The platform columns exclude plan fees, concurrency charges and HIPAA add-ons, and the custom column excludes the cost of your team’s time to operate it. Both omissions matter at the edges, so treat the table as a starting model, not a quote.

The break-even point for a custom voice agent

On these list prices, a custom stack breaks even at about 11,300 minutes a month against Retell’s recommended tier, 13,900 against Vapi’s higher configuration, 17,800 against Retell with Claude 4.5 Haiku, and 30,700 against Vapi’s lowest configuration. The arithmetic is the custom stack’s fixed monthly cost, about $1,194, divided by the per-minute saving.

Two things move the break-even sharply, in opposite directions. A HIPAA add-on of $2,000 a month on a platform is larger than the custom stack’s entire fixed cost in this model, so it pulls the break-even down, although a custom stack has its own compliance costs, such as Twilio’s Security Edition for a BAA. A larger build, say for several call flows and integrations, pushes it up by roughly 6,500 to 17,800 minutes for every additional $25k spread over three years, depending on the platform you compare against.

Costs that per-minute quotes leave out

A per-minute rate is the biggest line on the bill, but not the only one. Budget for these as well, on any route:

• Concurrent calls. Platforms include a set number of simultaneous calls and charge for more: Retell includes 20 and charges $8 a month for each extra, and Vapi includes 4, 10 or 30 depending on the plan and charges $10 a month per additional line. Size this for your busiest hour, not your average.
• Plan minimums. Vapi’s Core plan costs $29 a month, and its Pro plan bills 10% of the hosting fee with a $999 a month minimum. At 5,000 minutes a month, Pro’s hosting share is $25, so the minimum, not the percentage, sets the bill until volume is far higher.
• Phone numbers. Small, but they add up across locations: Twilio lists local numbers at $1.15 a month and toll-free at $2.15.
• Transfers. When the agent hands a caller to a person, the outbound leg is billed too; Twilio lists outbound calls at $0.0140 a minute.
• Recordings and transcripts. Storage and retention rules matter more than the storage price, especially for regulated calls.
• Testing. Every prompt or model change should be replayed against recorded test calls before it goes live, and those test calls use real minutes.
• Change. Models, voices and prices change; someone has to evaluate and apply those changes.

The integration is the cost that no per-minute quote shows, because it sits in the build. On the service booking agent we built for Innovative AI, every booking call loaded that vehicle’s own menu of 100–200 services from Xtime, checked the dealership’s open slots and settled drop-off, pickup or mobile service before it booked anything. In a build like this, each lookup is typically a tool the agent calls mid-conversation, and how AI service scheduling works at a dealership walks through them in order.

HIPAA and the BAA chain

A voice agent that hears patient information is only as compliant as the weakest vendor on the call. Under HIPAA, every vendor that receives protected health information must sign a business associate agreement, and on a voice call that is the carrier, speech-to-text, the language model, text-to-speech, the orchestration layer and wherever recordings and transcripts are stored.

Price this chain before you choose a stack. Vapi lists HIPAA-eligible data handling at $2,000 a month. Retell’s plan comparison lists HIPAA and a BAA on pay-as-you-go as well as enterprise, with a custom BAA on enterprise only (checked October 19, 2026). Twilio signs a BAA only for customers on its Security or Enterprise Edition. On a custom stack you sign each agreement yourself and can choose vendors and regions accordingly, which is often the deciding factor for healthcare work. There is no such thing as being “HIPAA certified”, so ask each vendor for its BAA, not a badge.

Outbound calls: consent rules change the cost

An agent that places calls costs more to build than one that answers them, because US law treats its voice as artificial. In February 2024 the FCC confirmed, in a declaratory ruling (FCC 24-17), that the TCPA’s restrictions on “artificial or prerecorded voice” cover current AI technologies that generate human voices. Such calls need the called party’s prior express consent, absent an emergency purpose or an exemption.

For a build, that turns into line items an inbound receptionist mostly avoids:

• consent capture and storage, tied to each number the agent may call,
• do-not-call list scrubbing before every campaign,
• an opt-out path inside the call that the agent honors at once,
• calling-hour limits by the recipient’s time zone,
• logs that show which consent covered which call.

Budget these as scope, not as a later fix; they decide whether the agent can dial at all. This is a summary of the ruling, not legal advice, and state rules can add to it.

Calls with a sales purpose count as telemarketing and need prior express written consent, so an unsold-lead callback carries a heavier consent flow than a reminder about a booked service, as our guide to no-show and unsold-lead follow-up calls explains.

When a platform is the right answer

For most first voice agents, a platform is the better choice. Choose one when:

• volume is under about 10,000 minutes a month and not growing fast;
• the call flow is standard, such as answering questions, booking into a common scheduler or taking messages;
• you want to test whether callers accept an AI agent before you invest in a build;
• or nobody will run voice infrastructure after launch.

Go custom when volume is high or rising, when compliance needs control over every vendor in the chain, when the agent must act inside your own systems in ways a platform’s integrations cannot, or when latency and voice quality are part of your product. Many teams start on a platform and move once the numbers above favor it; designing prompts and tools to be portable makes that move cheaper. The same trade-off applies to text agents, and our guide to build vs buy AI agents runs it over three years.

Is an AI voice agent worth it? Compare with missed calls

The right comparison is not the agent’s cost against a receptionist’s salary; it is the agent’s cost against the revenue lost to calls nobody answers. A business taking 60 calls a day at three minutes each uses about 5,400 minutes a month, which costs roughly $440 to $800 a month in platform usage at the list prices above.

Then estimate what missed calls cost you: calls a month, times the share you miss, times the share of those callers who would have bought, times the value of a customer. We walk through that model in what missed calls really cost, and you can run it with your own numbers in the AI voice agent ROI calculator. If the lost revenue is a multiple of the agent’s monthly cost, the case is easy at any of the prices in this guide.

How to lower the per-minute cost of a voice agent

The biggest savings come from the model and the voice, not from haggling over the platform fee.

• Use the smallest model that passes your call tests, and keep the system prompt stable so it can be cached.
• Pick a standard voice unless the voice is part of your brand; premium voices can cost several times more per minute.
• Keep calls short with clear flows and fast handoff to a person when the agent cannot help.
• Route by intent, so simple calls never reach the expensive model.
• Recheck list prices before you commit. This guide uses prices checked on October 18, 2026, and vendors update them; our AI voice agent pricing tracker rechecks them every month.

If you want these numbers worked out for your own call volume and systems, our AI voice agents team can model both routes in a free audit before you commit to either.

Originally published at apptycoons.com.

Rewardful’s Growth plan costs $99 a month, about $3,560 over three years. A custom affiliate tracking system from us starts at $25k before it has tracked a single click. We build custom software for a living, and for most affiliate programs that arithmetic settles it: buy. The exceptions are specific, and they follow.

Method: SaaS prices below come from each vendor’s own pricing page, checked October 18, 2026, and custom-build prices are our own published pricing. Tapfiliate and Rewardful are named only as examples of published price models; we have no relationship with either, and this post ranks no one.

Build vs buy affiliate tracking: the short answer

Buy if your program pays a percentage or fixed amount per sale, your partners are happy with a standard dashboard, and payouts go out by bank transfer or PayPal. Build if attribution, commission logic, payouts or the partner experience are part of what you sell, or if a vendor’s limits are capping revenue.

A quick way to place yourself:

• Standard SaaS or e-commerce referral program: buy.
• Commission logic the vendor can’t express (multi-touch, tiered by product margin, team overrides): build, or buy and extend.
• Earnings paid into your own wallet, card or balance: build the payout layer.
• The partner portal is your product (agencies, resellers, creators): build the experience, maybe on top of bought tracking.
• Tracking is a core revenue system for a marketplace: build.

What buying affiliate tracking software costs in 2026

Buying costs tens to low hundreds of dollars a month. The published plans differ less in price than in how they limit usage.

Two examples from vendors’ own pricing pages:

• Tapfiliate: Launch at $89 per month and Scale at $179 per month on monthly billing, with lower annual rates and a custom Enterprise plan. Plans include click and conversion allowances, with overage charged per 1,000 clicks and per 1,000 conversions.
• Rewardful: Starter at $49 per month (up to $7,500 a month of affiliate revenue), Growth at $99 per month (up to $15,000), and Enterprise from $149 per month. Rewardful says it charges 0% transaction fees on affiliate-attributed revenue; its optional Managed Payouts carry a 3% processing fee on payouts.

Note the two different limit models: one charges for traffic above an allowance, the other caps the affiliate-attributed revenue a plan covers. Model your own volumes against both before choosing.

The real costs of buying are not the subscription. They are the limits: commission rules the tool can’t express, a partner portal you can’t redesign, payout methods it doesn’t support, and data that lives in someone else’s system.

What building affiliate tracking software costs

Building costs tens of thousands of dollars upfront plus running costs, and you own the result. At Apptycoons the first step is a two-week, $5,000 discovery that pins down four things for an affiliate system: the attribution rules, the commission logic, how partners get paid and which fraud checks run before payout. It ends in one fixed price for the build, within our published $25k–$120k range over 6–16 weeks, and the discovery fee is credited to it. The pricing page has the full model; a large affiliate platform with a long roadmap may suit a Dedicated Team (from $12k a month) better.

A focused tracking system with one attribution model and one payout method sits toward the lower end of the build range. Multiple attribution models, several payout rails, advanced fraud detection and a full partner portal push it up. Running costs are hosting, monitoring and any payment provider fees.

A three-year cost comparison

Compare build and buy over three years, because that is roughly how long a tracking system lives before a major change. Using the published prices above:

• Buy, mid-tier plan: Rewardful Growth at $99 per month is about $3,560 over 36 months; Tapfiliate Scale at $179 per month is about $6,440, before any overage.
• Build, smallest scope: $5,000 for discovery (credited to the build) plus a build starting at $25k, then hosting and maintenance.

On cost alone, buying wins for a standard program several times over. Building only makes financial sense when the custom system creates revenue a bought tool cannot, removes a cap that is already costing you money, or replaces a platform fee that has grown with your volume.

The test is simple: write down the revenue the custom system creates, or the cost it removes, each year. If that doesn’t clearly exceed the build price within the first year or two, buy.

When building affiliate tracking wins

Building wins when tracking and payouts are part of the product rather than a marketing tool. These are the situations where it tends to pay off:

• Commissions follow your business model, not a template. Per-product margins, multi-level team overrides, recurring revenue shares or deal-based payouts.
• Partners are paid inside your platform. Earnings land in an in-app balance, wallet or card rather than leaving by bank transfer, the model we cover in stablecoin wallets and cards for partner payouts.
• You run a marketplace. Brands, partners and creators all need different views of the same deals.
• Attribution is disputed and costly. You need an audit trail detailed enough to settle every disagreement.
• The vendor is now the bottleneck. Their limits, pricing tiers or API are capping a program that already works.

If only one of these applies weakly, look at the hybrid route below first.

Example: Superdeal, where the deal is the unit

Superdeal shows why some programs outgrow off-the-shelf tracking. It is an influencer marketplace and campaign CRM: brands run creator campaigns across Instagram, TikTok and YouTube, with an AI agent doing the sourcing and drafting and the brand approving every step.

The payment model is what made custom the right call. Superdeal has no subscription; it is pay per deal, and creators are paid when their content is approved. The unit being tracked is a deal with deliverables and shipments, not a click or a checkout. Standard affiliate tools are built around clicks and conversions, so the workspace, the deal states, the approvals and the payout on delivery had to be built.

We built the shared campaign workspace, the AI agent that shortlists creators and drafts offers, the Draft, Review, Send approval flow, and scoped read-only dashboards for agency clients. The details are in the Superdeal case study, and our guide to creator platforms and revenue share covers the attribution, ledger and payout systems in more depth.

What a custom affiliate tracking system must include

If you build, these components are not optional. Leave one out and you will be adding it under pressure after launch, usually during a payout dispute.

• Click capture: tracking links, first-party click IDs, landing data and deduplication.
• Server-side conversion tracking: conversions recorded from your backend or by server-to-server postback, not only by a browser pixel.
• Attribution rules: first-click, last-click or custom windows, versioned so you can explain old payouts.
• Commission engine: rules per partner, product and tier, with reversals for refunds and chargebacks.
• Fraud checks: click and conversion validation, self-referral detection and anomaly alerts before payout.
• Partner portal: links, live stats, earnings, payout history and onboarding.
• Payouts: scheduled runs, thresholds if you use them, failure handling and statements.
• Admin tools and audit log: manual adjustments, disputes and an explanation for every number.

Tracking under browser privacy rules

Browser-only affiliate tracking is unreliable in 2026, so any system you build or buy should record conversions on the server. WebKit, the engine behind Safari, blocks all third-party cookies by default. It also deletes cookies created in JavaScript and other script-written storage after 7 days without user interaction with the site, and when a visitor arrives through a decorated link from a site it classifies as a tracker, it caps JavaScript cookies on the landing page to 24 hours.

In practice that means first-party click IDs stored on your own domain, conversions sent from your backend, and server-to-server postbacks to partners where they need them. Ask any vendor exactly how they handle this before you buy.

The hybrid route: buy tracking, build the experience

Many teams get the best of both by buying the tracking and building around it. The vendor handles clicks and conversions; you build what partners see and how they get paid, using the vendor’s API and webhooks.

Typical hybrid builds:

• A branded partner portal inside your own product, fed by the vendor’s API.
• Custom onboarding and approval flows for new partners.
• Payouts into your own wallets or balances, triggered by the vendor’s conversion webhooks.
• Reporting that joins affiliate data with your CRM.

Watch out

Before you sign

Check that the vendor’s API exposes what you need and that you can export all of your data.

Open-source tracking: what it saves and what it doesn’t

Open-source affiliate tracking saves the subscription and nothing else. Self-hosting a tool trades a monthly fee for hosting, security updates and an engineer who keeps it running, and it leaves every operational job where it was: fraud review before payout, the payout runs themselves, tax forms for partners, disputes and support.

It makes sense in two cases. Your team already operates servers and wants the data in its own database, or you plan a custom build later and want to learn your real requirements on a tool you can read and change. If neither applies, compare the cost of an engineer’s time each month with the $49 to $179 plans above, and the paid plan usually wins.

Compliance: disclosure is part of the system

Whichever you choose, your program has to support honest disclosure. The FTC’s Endorsement Guides FAQ says affiliates should disclose their relationship to the retailer clearly and conspicuously, so readers can decide how much weight to give the endorsement.

Software can make that easier: disclosure guidance in onboarding, approved copy and creative in the portal, and the ability to pause partners who don’t comply.

A decision checklist

Answer these before you request quotes, from vendors or from us:

• Can a standard per-sale or recurring commission express your program?
• Do partners need to be paid anywhere other than a bank account or PayPal?
• Is the partner portal something your customers judge you by?
• What revenue or cost would a custom system change each year, in dollars?
• Who will own the system after launch?

If the answers point to buying, buy, and revisit in a year. If they point to building, our affiliate and CRM software development page shows what we build. Bring your current commission rules and partner count to a free 30-minute call and we will tell you whether a build is worth pricing.

Originally published at apptycoons.com.

At 2,000 support outcomes a month, Intercom’s Fin costs about $71,000 over three years at its listed starting price, less than a custom agent. At 10,000 a month it costs about $356,000, roughly three times the custom option’s three-year cost in our model. Same job, same agent; volume alone flipped the answer.

Product vendors will tell you building is slow and risky. Development shops, us included, will tell you buying locks you in. Both are sometimes right, so what follows is a way to decide for one specific agent, including the cases where the right answer is not to hire a studio like ours.

Build vs buy AI agents: the short answer

Buy when the agent does a job every company has, at a volume where per-use fees stay modest, and a product already works with your systems. Build when the agent’s workflow is part of how you win, when it must act inside your own systems, when your data must stay under your control, or when usage fees would outgrow a one-off build within a few years.

Most companies end up in between. They buy the commodity layers, such as the models, telephony, vector search and observability tools, and build the workflow that is specific to them on top. The decision is less “build or buy” than “which layers do we own”.

The three real options: buy, configure or build

There are three ways to get an agent into production, and they differ in time to value, cost model and who owns the result.

A decision matrix for CTOs

Answer these eight questions for the specific agent you are considering. If most answers fall in the “buy” column, buy. If most fall in “build”, build. If it is mixed, buy now and design for a later move.

Three-year total cost: a worked example

The cost comparison flips with volume, so do the arithmetic for your own numbers rather than trusting a rule of thumb. Here is one worked example for a support agent that resolves customer questions.

The bought option is Intercom’s Fin AI Agent at its listed starting price of $0.99 per outcome, rechecked on October 18, 2026. The custom option uses assumptions we state openly: a $25k–$120k build placed at $60,000 for a support agent with helpdesk and order-system integrations, $500 a month for hosting and monitoring, 20% of the build per year for maintenance and model updates, and model tokens based on Anthropic’s own example of about $37 per 10,000 support tickets on Claude Haiku 4.5. Helpdesk seats are left out because you need them either way.

How the build column adds up at 10,000 a month: $60,000 build, plus $18,000 hosting over 36 months, plus $36,000 maintenance over three years, plus about $1,300 in tokens. The tokens barely register; the build and the people who maintain it are the real cost. On these assumptions, the break-even is about 3,200 outcomes a month.

Three caveats keep this honest. A product like Fin includes things a custom build has to create, such as reporting and content management, and its per-outcome price can be higher than the starting price. Intercom also counts a handoff to a person as an outcome when Fin completes that workflow, so outcomes are not the same as fully resolved tickets. A custom build can cost more than $60,000 if it needs more integrations or compliance work. And a bought agent is live in days, which has value the table does not show. Change the assumptions and rerun it; the method matters more than our numbers. For a fuller breakdown of build and running costs, see AI agent development cost.

Data, IP and lock-in: what to check before you sign

Lock-in is rarely about the contract term. It is about whether your data, history and logic can leave with you. Before buying, check:

• whether the vendor trains models on your data, and whether that can be switched off in writing,
• whether you can export conversation logs, knowledge sources and agent configuration in a usable format,
• where data is processed and stored, and for how long,
• whether you can choose or change the underlying model,
• and what happens to your history if you cancel.

If you build, the equivalent questions are about ownership. Our builds put the code in your repository from day one and the IP is yours, but whoever builds for you, confirm both in the contract.

Price the exit before you sign, too, because leaving a bought agent is a small project of its own. Expect to export conversation history and the knowledge base, map them into the next system, rebuild every integration the product handled for you, and rerun your evaluation cases to prove the replacement answers as well. None of that has a list price, so ask the vendor for a sample export on day one; a messy or partial export is the clearest sign of how much leaving will cost.

Governance and risk: why most failures are not about the model

Agent projects stall more often because of how they are run than because of the model, and the build-or-buy choice decides who carries that risk. On the buy side, the risk is a product that demos well but cannot reach the systems or rules your cases depend on. On the build side, it is a team that has never shipped an agent learning on your budget.

According to Fortune’s summary of MIT NANDA’s 2025 report on enterprise AI, tools bought from specialized vendors and builds done with partners succeeded about 67% of the time, and purely internal builds only a third as often. The lesson is not “never build”. It is that building from scratch in-house, without people who have shipped agents before, is the riskiest route. Whichever route you choose, insist on an evaluation set, approval steps for high-impact actions, an audit log, and a named owner after launch; our checklist of agent guardrails lists ten controls to ask for on either route. We cover this in more depth in why AI pilots stall before production.

When buying is the better choice

Buying is the right answer more often than development shops admit. Buy when:

• the use case is common, such as help-center answers, meeting notes or ticket summaries,
• a product already integrates with the tools you use, without custom work,
• your volume keeps per-use fees below what a build and its maintenance would cost,
• you need value this month and can accept the vendor’s workflow,
• or there is no one to own a custom agent once it ships.

In those cases, a custom build would cost more and arrive later, and you should not pay for one, from us or anyone else.

Do general-purpose agents like Muse and Grok Bot count as buying?

Yes, and for one kind of work they are the cheapest option there is. Meta’s Muse and xAI’s Grok Bot are general-purpose agents that sign in to the apps a person already uses and work through multi-step jobs. If the job belongs to one person or one small team and runs through common tools, try them before you buy anything narrower or build anything at all.

What each one is, from the vendors’ own pages (checked October 12, 2026):

• Muse launched on September 8, 2026, rolling out in the US. Meta says it is free for most of what people need, with paid plans for more. It runs on its own cloud machine, people choose which apps it connects to and how much access it gets, and it checks with the user before sensitive actions such as sending an email or making a purchase.
• Grok Bot has been in beta since August 11, 2026, included with SuperGrok and paid Cursor plans, with its own usage on top. Bots share a cloud computer that belongs to the account, sign in across apps and websites, use connectors where they exist and operate the screen everywhere else, and come back when something needs approval. xAI says teams use them for sales outbound, marketing campaigns and office operations; Enterprise access is a waitlist.

The limits are those of any bought agent, plus a few more. The agent runs in the vendor’s cloud with your users’ logins. It follows the vendor’s approval model, not yours, and your evaluation cases and audit requirements don’t travel with it. Where it operates a screen instead of an API, a layout change can break the job. Enterprise controls are still arriving on both.

So split the work by who carries the risk. An agent that drafts, researches or files on behalf of one person can be bought this way today. An agent that changes records, moves money or speaks to customers on the company’s behalf belongs in the build column of the matrix above. There is also a middle path: keep the workflow and its rules in your own systems, and let Muse, Grok Bot or Claude call them through an MCP server for Muse and Grok that enforces your permissions.

When building wins

Building wins when the agent is part of what makes your business different, or when no product can reach the systems it needs to act in. Two of our builds show both patterns.

Relm is a commercial real estate platform where the agents are the product: parallel agents turn a property address into a sourced report and a 10-year pro forma. No off-the-shelf agent does that, because that work is what Relm sells.

Superdeal is the second pattern. Its agent reads the platform’s own creator, deal and shipment records and works through the platform’s own approval step before anything is sent. A bought agent would sit outside that data and those approvals, which is where all of the agent’s value comes from.

The hybrid most teams end up with

In practice, nearly every custom agent is part bought. Models come from Anthropic, OpenAI, Google or open-source providers; vector search, telephony and observability come from vendors. What you build is the layer that encodes your workflow: the tools the agent can call, the rules it follows, the approvals it needs and the evaluation set that proves it works. Owning that layer is what lets you switch models as prices fall, and move between vendors without starting again.

AI agent vs chatbot vs RPA

Part of the build-or-buy question is whether you need an agent at all. Sometimes a chatbot or an RPA script is enough, and both are cheaper.

How to run a fair test before you decide

You can test both routes cheaply before committing to either. Run the bought product on a slice of real traffic for two to four weeks, with its own reporting turned on, and record three numbers: how many cases it fully resolved, how many it got wrong, and how many it handed to a person. Then run the same cases through a custom prototype on your real data; our discovery sprint ends with one for $5,000.

Compare the two on your evaluation cases, not on a demo. If the product resolves enough cases at a cost you can live with at year-three volume, buy it. If it stalls on the cases that matter most, such as those that need your internal systems or your rules, that gap is what a custom build is for. If you do go custom, the vetting questions are in how to choose an AI agent development company.

The method is not specific to AI. We ran the same decision for affiliate tracking, where SaaS plans that step up with tracked affiliate revenue play the part that per-outcome pricing plays here.

A build-vs-buy checklist

Before you decide, write down answers to these, for this agent specifically:

• The one business number the agent must move, and its current value.
• Expected volume in month one and in year three.
• Every system the agent must read from or write to.
• Where the data may be processed and stored.
• Which actions need a person’s approval.
• Who owns the agent after launch, and their budget for changes.
• The three-year cost of buying at year-three volume, and of building.

If the checklist points to buying, buy. If it points to building, our AI agent development team fixes the price after a two-week discovery sprint, and the first conversation is a free AI audit that covers this decision, including when the answer is to buy.

Originally published at apptycoons.com.

Since August 2, 2026, a support chatbot or voice agent that talks to people in the EU has to tell them it is an AI, at the latest at the first interaction. Breaching that duty can cost up to €15 million or 3% of worldwide annual turnover, whichever is higher (for SMEs and start-ups, whichever is lower).

Most of what the EU AI Act and GDPR ask of an agent is engineering work: a line in the greeting, a log, an approval step, a region setting. This guide maps each rule to the build, as the law stands on October 18, 2026. Apptycoons builds custom AI agents with engineers in Karachi, Pakistan, so the transfers section describes our own setup.

Does the EU AI Act apply to your AI agent?

Yes, if the agent is placed on the EU market or its output is used in the EU. Article 2(1) covers providers placing AI systems on the EU market wherever they are established, deployers located in the EU, and providers and deployers in third countries “where the output produced by the AI system is used in the Union”. A US or UK company whose agent answers EU customers is in scope.

The Commission’s AI Act Service Desk says the term AI agent “is not legally defined”, but agents fall under the definition of an AI system, so the same rules apply. It calls its view on agents preliminary.

Who is the provider when an agency builds the agent?

Usually the client. Article 3(3) makes the provider whoever develops an AI system, or “has an AI system … developed and places it on the market or puts the AI system into service under its own name or trademark”. A company that commissions a custom agent and runs it under its own brand fits that definition, and because it uses the agent in its own business, it is normally the deployer as well (Article 3(4)).

That is our reading of the definitions, not a ruling, and a vendor selling one agent to many customers under its own brand is a provider itself. Write the split into the contract: who holds the Article 50 duties, who keeps the documentation, who answers a regulator.

GDPR draws a parallel line: you are normally the controller and the development partner the processor, which requires an Article 28 contract (a data processing agreement, or DPA).

What changed in 2026: the Digital Omnibus dates

The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the high-risk deadlines and left the chatbot rules on schedule. It entered into force on July 27, 2026, so pages giving August 2, 2026 as the high-risk date are out of date.

The Omnibus also softened Article 4: providers and deployers must now “take measures to support the development of AI literacy”, not ensure a sufficient level of it.

What Article 50 requires of chatbots and voice agents

An agent that talks to people must be designed so that they “are informed that they are interacting with an AI system, unless this is obvious” (Article 50(1)). The information has to arrive “in a clear and distinguishable manner at the latest at the time of the first interaction or exposure”, and it must meet accessibility requirements (Article 50(5)). The Commission’s FAQ names “chatbots, AI agents, and avatars”; a voice agent on a phone line is the same two-way exchange.

Three details are often misreported:

• Naming the company. Article 50(1) does not require the agent to say which business it works for. It is good practice, and the GDPR notice usually needs it anyway.
• The “obvious” exception. Don’t build on it. A voice agent designed to sound human is the opposite of obvious.
• Marking output. Article 50(2) is a separate duty: providers of systems that generate synthetic audio, image, video or text must mark the output “in a machine-readable format and detectable as artificially generated or manipulated”. A synthetic voice is synthetic audio. The grace period to December 2, 2026 covers only systems on the market before August 2, 2026.

Our AI voice agent development page covers how we build and test the greeting, transfer and recording flow.

Disclosure scripts for chat, voice and handoff

These are examples to adapt, not legal wording. The voice greeting combines the Article 50 disclosure with the GDPR Article 13 recording notice, because both have to come first.

Chat, first message: “Hi, I’m [Company]’s AI assistant. I can check orders and book appointments. Type ‘person’ at any time to reach our team.”

On a voice call, the greeting, the reminder before a sensitive step and the line before a transfer look like this:

Keep the spoken notice short and put the full privacy notice online.

When does an AI agent become high-risk?

An agent becomes high-risk when it is used for an Annex III purpose. The ones closest to agent work: recruitment and selection of candidates (4(a)), decisions on terms of work, promotion or termination and the monitoring of workers (4(b)), creditworthiness and credit scoring, with fraud detection excluded (5(b)), risk assessment and pricing in life and health insurance (5(c)), and evaluating or classifying emergency calls (5(d)).

From December 2, 2027, those systems carry the Chapter III obligations: risk management, data governance, technical documentation, record-keeping, human oversight, and accuracy and cybersecurity.

Human oversight is where the “kill switch” idea comes from, and it is often overstated. There is no general duty for every AI agent to have one. For high-risk systems, Article 14(4)(e) requires that the people assigned to oversight can “intervene in the operation of the high-risk AI system or interrupt the system through a ‘stop’ button or a similar procedure that allows the system to come to a halt in a safe state” (checked October 18, 2026). In build terms, that is a switch that stops the agent and leaves any action it was taking either finished or rolled back, never half done.

A general customer-service, booking or FAQ agent is typically not high-risk. Add a step that screens job applicants or sets credit limits and it is. Draw that line in scope.

Banned practices to design out now

Article 5(1)(a) and (b) have applied since February 2, 2025. They ban manipulative or deceptive techniques that materially distort behavior and cause significant harm, and exploiting vulnerabilities linked to age, disability or social or economic situation.

For a sales or collections agent, design out the patterns that lean toward that line: invented deadlines, pressure on callers who sound confused, scripts that push harder when someone hesitates.

GDPR for agents: what still applies

GDPR applies to an agent the way it applies to any system that processes personal data, and it has not changed. The separate Digital Omnibus proposal to amend it (COM(2025) 837) was still in Parliament and Council when we checked on October 18, 2026.

The parts that turn into code:

• Lawful basis (Article 6). Pick it per purpose before the build.
• Minimization. Send the model only the fields the task needs.
• Retention. Transcripts, recordings, logs and vector-store chunks each need a deletion timer.
• DPIA (Article 35). Required before processing “likely to result in a high risk”, such as health data at scale.
• Automated decisions (Article 22). People have the right not to be subject to solely automated decisions with legal or similarly significant effects.
• Rights requests. Access and deletion must reach transcripts, logs and embeddings, not only the CRM.

Sub-processors in an agent stack

A voice or chat agent can involve five or six vendors that see personal data, and each belongs in the DPA as a sub-processor. Article 28 requires the controller’s prior authorization to use them.

Model providers differ. OpenAI has not trained on API data by default since March 1, 2023, keeps abuse-monitoring logs for up to 30 days, offers zero data retention only with prior approval, and can keep both storage and processing in Europe (EEA and Switzerland); its UK region stores data there but may process it elsewhere. Anthropic’s own API currently offers inference in the US or globally and stores workspace data in the US, so EU residency for Claude means going through a cloud platform such as Google Cloud, where the endpoint sets the region. Check current terms before you write the privacy notice.

Working with engineers outside the EU: a transfer setup that holds up

Engineers outside the EU can work on a GDPR-covered system, but personal data sent to a country without an EU adequacy decision needs a transfer tool and an assessment. Pakistan, where our engineers work, is not on the Commission’s adequacy list. The setup we propose:

• Production data stays in your environment, in your cloud account and, when you require it, an EU region.
• Development and testing run on synthetic or redacted data.
• Production access is limited to named engineers, for a stated reason, and logged.
• Where personal data does reach Karachi, the EU standard contractual clauses apply: Module 2 (controller to processor) or Module 3 (processor to sub-processor), depending on who signs. They already contain the Article 28 terms, so no separate DPA is needed for that transfer.
• Clause 14 requires a transfer impact assessment of the destination country’s laws and practices, with extra safeguards such as encryption where needed. We supply the technical facts; your counsel signs off.

None of this means data “never leaves the EU”. Access from Karachi is a transfer and is documented as one.

UK buyers: what differs

The EU AI Act is not UK law, but it reaches a UK company whose agent’s output is used in the EU (Article 2(1)(c)). Personal data falls under UK GDPR, and EU-to-UK flows rely on the adequacy decisions the Commission renewed in December 2025.

Transfers out of the UK work differently. The ICO is explicit that “the EU SCCs are not valid on their own” for UK transfers: you use the ICO’s International Data Transfer Agreement (IDTA), or the UK Addendum attached to the EU SCCs, and you must complete a transfer risk assessment (TRA). The Data (Use and Access) Act 2025 also rewrote the UK rules on automated decision-making; check them before an agent decides anything significant on its own.

The build checklist

This is the list we work through in discovery and build for an agent with EU or UK users: a legal hook, a change in the system and a record you keep. The last row, the kill switch, is a legal duty only for high-risk systems under Article 14; for every other agent it is good practice. The approval, audit and kill-switch rows are the same controls our AI agent guardrails checklist covers from the security side.

When you don’t need to worry

Most agent projects carry less regulatory work than the headlines suggest. The effort stays small when:

• Nobody in the EU uses the agent and its output isn’t used there. The AI Act does not reach it (Article 2), and EU GDPR usually doesn’t either.
• The agent is a support, booking or FAQ agent. It is typically not high-risk. The work is disclosure, logging and a DPA, not a conformity assessment.
• The agent processes no personal data. An agent that reconciles supplier invoice totals raises few GDPR questions.

The cases that need care are Annex III uses, agents that decide things about people, and health data or call recordings at scale.

What to ask your development partner

Five questions show whether a partner has thought about this:

1. Who is the provider and who is the deployer, and where does the contract say so?
2. Where does each component run, and which can be pinned to an EU region?
3. Which sub-processors see our data, and with what retention and training settings?
4. Will you sign our DPA, plus the SCCs or the UK IDTA or Addendum, and support our transfer assessment?
5. How is the AI disclosure built and tested, and how do we switch the agent off?

Our answers: we can sign your DPA and the SCCs or UK transfer documents, deploy in an EU region on request, use endpoints that exclude training (zero retention where the provider offers it), and supply the system description and sub-processor list for your DPIA. For wider vendor questions, use our checklist for evaluating an AI agent development company. To map your own agent against the table above, book a free AI audit.

This guide summarizes the law as of October 18, 2026 and is not legal advice. Check your situation with counsel or your data protection officer.

Originally published at apptycoons.com.

Exigo bought DirectScale in 2022, and directscale.com now redirects to exigo.com, yet many “Exigo alternatives” lists still put both names on the shortlist. Start with a cleaner question: are you choosing your first enterprise MLM platform, or are you on one and something has started to hurt? What follows works for both, and ends with a plain test for when a platform is the better answer and when custom MLM software wins.

Disclosure: Apptycoons builds custom MLM and direct-selling software, so we have a stake in this question. We have no partnership with any vendor named here, and this post does not rank anyone. Vendor facts come from each vendor’s own website as of October 2026; the one third-party figure (Exigo pricing) is labeled as such. Where a platform is the better choice, we say so.

What Exigo is, in its own words

Exigo is an enterprise software platform for direct-selling and MLM companies. Its website describes a commissions and order-management core, a mobile-first distributor back office, analytics, an e-commerce and website builder, and AI features. Exigo says it has served the industry for over 25 years and powers more than 100 direct-selling brands.

The commission engine, Exigo Core, is the part most companies buy it for. Exigo says it supports binary, unilevel, matrix and hybrid plans, lets you model a plan in a sandbox before going live, and connects to other systems through APIs. It also says it has completed over 400 migrations from legacy platforms.

Two facts matter when you compare options:

• Exigo and DirectScale are one company now. Exigo acquired DirectScale in October 2022, and directscale.com redirects to exigo.com. A shortlist with both names on it is a shortlist of one vendor.
• Exigo does not publish its pricing. Its site asks you to request a demo. The software directory Capterra lists a starting price of $5,000 per month, flat rate. Treat that as a directory listing, not a quote.

None of this is a weakness. A mature platform with a large customer base, a tested commission engine and a long migration record is exactly what many direct-selling companies need.

The kinds of Exigo alternative: platform, script, custom or hybrid

Exigo alternatives fall into three groups, plus a hybrid of them, and they solve different problems. Comparing a platform with a custom build feature by feature misses the point, because the trade-off is about who controls the roadmap, not about checklists.

• Another enterprise direct-selling platform. For example ByDesign, which describes itself as software for direct selling, MLM, party plan, affiliate and influencer marketing, with a commissions engine, back office, party module and shopping cart. You trade one vendor roadmap for another.
• A packaged or licensed MLM script. Lower entry cost and faster setup, usually aimed at smaller companies. Fit depends heavily on how close your plan is to the templates it ships with.
• Custom MLM software. A compensation engine, back office, distributor app and payouts built around your plan and owned by you. Highest control, and you carry the responsibility for it.

The hybrid is the option most comparison pages ignore: keep a platform for the commission engine and order core, and build the parts members touch, such as the distributor app, the wallet and the onboarding funnel, as custom software on top of its APIs.

Why some lists of Exigo alternatives mix different products

Not everything sold as commission software can replace Exigo, because an MLM platform runs a distributor network and a sales-commission tool pays a sales team. If a shortlist mixes the two, sort it by what each product runs before you book demos.

Sales-commission tools are good at what they do: Everstage describes itself as sales compensation and commission tracking software, and spiff.com now redirects to Salesforce’s incentive compensation management product. Neither describes a genealogy, distributor enrollment or replicated sites, which is most of what an MLM company buys Exigo for. Take them off an MLM shortlist, and keep them in mind only if you also pay an internal sales team.

When a platform like Exigo is the better choice

A platform is the better choice when your compensation plan is conventional and your competitive edge is product, brand and field leadership rather than software. In that case, a proven engine and an existing back office get you to market faster and with less risk than any build.

Choose a platform when most of these are true:

• Your plan is a recognizable binary, unilevel or matrix structure, or a common hybrid the vendor already supports.
• You do not have, and do not want, an internal product owner for the software.
• You need multi-country tax, currency and shipping support from day one.
• Your distributor experience can live inside the vendor’s back office and app.
• Your payouts go to bank accounts or a payout provider the vendor already integrates.

If that describes you, a platform is the sensible default. Spend your energy on product, training and compliance, and push the vendor for the features you need.

When custom MLM software wins

Custom MLM software wins when the thing holding you back is something Exigo’s own feature list does not cover. Be careful here: a complicated plan alone is not a reason to leave, because Exigo says its engine already handles hybrid plans and lets you test plan changes in a sandbox. Look instead for these signs, and price a custom or hybrid build if two or more apply:

• Your roadmap keeps waiting on the vendor’s. Promotions, bonuses or plan rules you need this quarter are queued as paid customizations or feature requests.
• Earnings have to stay inside your product. Partners hold their balance, spend it by card or receive it in stablecoins, rather than receiving a periodic bank transfer.
• Members buy services, not just shipped products. Wireless, streaming or financial subscriptions need provisioning and one login across providers, which is product software, not a back office.
• Recruits judge you by the app. If the distributor app is your main sales tool, you need to control its design and release schedule.

If none of these applies, the platform is doing its job. If they do, our guide to custom MLM software covers how to design the commission engine itself.

Example: Freedom Pro, where three of the four signs applied

Freedom Pro is a direct-selling company whose signs pointed to custom: three of the four above applied. It bundles everyday services, including wireless, streaming, wellness and finance, and pays a partner network on its team’s activity.

Mapped against the signs:

• Earnings stay inside the product. We integrated Bridge so members hold dollars and stablecoins side by side and spend the balance by debit card. How those stablecoin payouts for partners work, from provider choice to ledger, has its own guide.
• Members buy services. Wireless, MyPro TV streaming, wellness, a trade club and other programs sit behind one member portal login.
• The app sells the opportunity. A guided sign-up funnel turns visitors into partners, and the partner back office covers registration, team genealogy, ranks and commission tracking.

The full write-up is in the Freedom Pro case study. The point is not that every MLM company needs stablecoins; it is that once money and services live inside your product, choosing between Exigo and a custom build becomes a product decision, not an IT purchase.

Exigo pricing compared with the cost of custom MLM software

Platform pricing is a recurring fee; custom software is mostly an upfront build plus running costs. Because Exigo does not publish its fees, the comparison only works once you have a written platform quote that answers these questions:

• What is the monthly fee, and does it grow with distributors, orders or transaction volume?
• What do implementation, plan configuration and data migration cost, and are they one-off?
• How are customizations and new plan rules priced after launch?
• What does a full data export cost when you leave, and in what format?
• Which payment, tax and shipping integrations are included, and which are extra?

On the custom side, our published model is a $5,000 two-week discovery that maps your plan, payouts and data, then one fixed price for the build in our $25k–$120k range. The pricing page has the details. Where an MLM build lands in that range depends mostly on how many payout and wallet integrations it needs, how many countries it serves and how much commission history it has to reproduce.

Compare on a three-year view. A platform fee is predictable but never ends and never becomes an asset. A custom build costs more in year one and gives you code you own, which you then have to maintain.

Compliance: switching software does not change the rules

Switching software does not change your compliance position, because regulators look at the compensation plan and how it works in practice.

Watch out

No setting makes a plan compliant

The US Federal Trade Commission’s guidance on multi-level marketing states that there is no percentage-based test for whether an MLM is a pyramid scheme, so no vendor can sell you a setting that makes a plan compliant.

What software does decide is how easily you can produce evidence. When you compare Exigo with any alternative, ask each to show you, from real data, retail sales to non-participants separated from distributor purchases, a reproducible commission statement for any past period, and the payout figures behind your income disclosure. The MLM software guide linked above lists the features behind each. Have counsel review the plan before anyone encodes it.

How to move off Exigo without breaking commissions

Leaving Exigo safely takes a parallel run: copy the data out, re-run past periods in the new system, and switch payouts only once both systems agree. Exigo says it has completed over 400 migrations onto its platform; moving off it is the direction to plan most carefully, so start with the contract.

A migration plan that works, whether the destination is custom software or another platform:

Our MLM software development page describes how we run that parallel period.

A quick decision checklist

Answer these five questions before you book any demo, including ours:

• Could you describe your compensation plan using only the vendor’s standard plan types?
• Do partners need to hold, spend or receive money inside your product?
• Do you sell services that need provisioning, not just products that ship?
• Will you change the plan more than once a year?
• Do you have, or will you hire, someone to own the software roadmap?

Mostly no: start with a platform. Mostly yes: price a custom or hybrid build. Mixed: the hybrid route, a platform engine plus custom member experience, is usually the right first step.

When not to hire us

Do not hire a custom developer, including us, if your plan is standard, you are pre-launch with no distributors yet, or nobody in the company can own the product after launch. A platform will serve you better. If you are past that point and want a second opinion on your own plan, book a 30-minute call and bring your current Exigo contract and plan document.

Originally published at apptycoons.com.

Switch lets a club’s treasurer issue a Visa debit card in seconds. Freedom Pro pays a partner network into USD and stablecoin wallets its members spend by card. We built both, both are “fintech apps”, and their scopes have almost nothing in common. That is why a single price range for fintech app development tells you so little.

We don’t publish client budgets, so there are no invented price tags for those two products here. There is what was in scope, why each piece costs what it does, and the prices we publish for our own engagements.

The short answer: what a fintech app costs in 2026

A fintech app costs what its money movement and compliance cost, not what its screens cost. The single biggest decision is whether a licensed partner holds customer funds while you build the product around it, or whether you take on that regulated role yourself.

For the first path, which is how most new fintech products launch, our published pricing is:

• Discovery Sprint: $5,000 fixed fee, 2 weeks. Scope, partner and compliance mapping, architecture, and a fixed price for the build. The fee is credited to the build.
• Fixed-Price Build: $25k–$120k per project, 6–16 weeks. Billed in milestones tied to demoed features, with 30 days of post-launch support.
• Dedicated Team: from $12k per month. For larger programs and the roadmap after launch.

Published agency estimates run wider, from about $25,000 for an MVP to $900,000 or more for a complex neobank. The next section shows why those numbers disagree, and the rest of this post shows which line items separate a first product on a partner’s rails from a neobank.

Why published fintech cost ranges disagree

Published fintech cost ranges disagree because each agency prices a different product, team location and compliance scope. Four 2026 guides from development agencies, with the figures copied as published:

Read side by side, three things explain most of the spread. Team location: Acquaint’s own table moves its MVP figure by about $10,000 between US and EU teams. Compliance scope: a product that becomes a regulated entity carries audits, licensing work and its own controls, while one built on a licensed partner inherits most of them. And what “MVP” means: RaftLabs’ smallest scope is a budgeting, expense-tracking or rewards app, while Interexy prices a neobank MVP separately at $110,000–$160,000. These are vendor estimates, ours included; none of them, and none of ours, is a price for your scope until the money flows are drawn.

The biggest cost decision: partner with a licensed provider or become one

Partnering with a licensed provider is cheaper and faster because the hardest regulated pieces, holding deposits, issuing cards and custody of digital assets, are already built and supervised. You integrate them through APIs and build the experience, the business logic and the controls on top.

The trade-off is dependency. Your product inherits the partner’s program rules, fees and onboarding timeline, and your users’ protection depends on that structure.

Watch out

Deposit insurance does not cover the app company

The FDIC is clear on one point founders often miss: deposit insurance does not protect against the insolvency or bankruptcy of a non-bank company. Your app, your disclosures and your record-keeping have to reflect how funds are held.

Our guide to stablecoin wallet integration covers this partner-first approach for digital assets in depth. Typical partner categories in a 2026 fintech build:

• Partner bank / banking-as-a-service for accounts, deposits, ACH and wires.
• Card issuing program for virtual and physical debit cards, spend controls and wallet provisioning.
• Stablecoin and wallet infrastructure, such as Bridge, which offers one API to move, store and accept stablecoins, plus wallets and a card program.
• KYC and identity verification for onboarding.

Both case studies below use this model.

Real scope 1: Switch, a shared banking app

Switch is a banking app where clubs, teams and friends pool money, issue Visa debit cards in seconds and collect payments. It runs on iOS, Android and the web, with Thread Bank as its FDIC-insured partner bank. Here is what the scope contained, and why each part carries cost.

• Shared accounts with roles and permissions. Treasurers, admins and members each see and do different things. Permission models are a cost driver because every money action has to check them, and every one needs tests.
• Instant virtual and physical Visa debit cards. Spend limits, pause and close controls, plus Apple Pay and Google Wallet. Card issuing adds program integration, card lifecycle states and wallet provisioning flows.
• MoneyPools. Shareable collection links that work on the web with no download, with live tracking of who has paid. This is a second product surface, a public web flow, alongside the apps.
• Org tools. Multiple admins, one-tap handover to the next leader, QuickBooks sync and installment plans. Accounting sync means mapping transactions to someone else’s data model and keeping it in step.
• Full banking features from the partner: checks, cash deposits, wires and a fee-free ATM network.

What drove the effort was not the number of screens. It was the combination of three platforms, a permission model on every money action, card lifecycle handling and a public collection flow. The result: Switch is live on iOS, Android and web, has been adopted by 1,000+ organizations, and is rated 4.7 on the App Store. The details are in the Switch case study.

Real scope 2: Freedom Pro, a partner platform with wallets and cards

Freedom Pro is a direct-selling platform that bundles wireless, streaming, wellness and finance services and pays a partner network. Its fintech layer is a wallet: members hold USD and stablecoin balances and spend them by debit card. Its scope has little in common with Switch’s.

• Partner back office. Registration, team genealogy, ranks and commission tracking. Commission logic is business-critical code that needs reproducible calculations.
• USD and stablecoin wallets via Bridge. Earnings land in wallets members can hold or spend. Wallet integrations need balance reconciliation and clear state for every transfer.
• Debit card issuing. Members spend their balance anywhere by card.
• A member portal and single sign-on across several service verticals, plus an onboarding funnel that converts visitors into partners.

Here the cost sat in the money layer and the commission engine, not in banking features. Comparing the two scopes is the point: both are “fintech apps”, and a single price range would describe neither. See the Freedom Pro case study for the full build.

Fintech app cost by product type

What drives cost changes with the kind of fintech product, so compare scopes of the same type. We don’t publish per-type prices; this table lists the drivers and the real case that maps to each, where we have one.

A bundled platform is closer to financial aggregator development than to a banking app: most of its cost sits in connecting providers and keeping one view of the customer across them.

How long a fintech app takes to build

A focused first release on a partner’s rails typically takes 6–16 weeks of build after a two-week discovery, and partner approval often takes longer than the code. Banks, card programs and wallet providers each run their own onboarding, due diligence and program review. Start those conversations during discovery, so the build is not waiting for a sandbox key or a program sign-off in week eight.

The line items that drive fintech app cost

Every fintech quote is a sum of a few expensive line items and many cheap ones. These are the expensive ones, roughly in the order they move the price.

• Onboarding and KYC. Identity checks, document capture, failure and retry paths, manual review queues, and what the user sees while they wait.
• Money movement. Each rail (cards, ACH, wires, stablecoins) adds states, webhooks, failure handling and reconciliation.
• Ledger and reconciliation. Your record of balances has to match the partner’s every day, and someone needs a screen that explains any difference.
• Permissions and limits. Roles, spend limits and approvals, enforced on the server for every action.
• Admin and compliance tooling. Search, account holds, case notes, exports and audit logs for your operations team. It is often under-scoped and always needed.
• Security and PCI scope. The PCI Data Security Standard sets the baseline for handling payment card data. Using an issuer’s tokenized cards and hosted components keeps raw card numbers out of your systems and shrinks what you have to secure.
• Platforms. iOS, Android and web multiply UI and testing work. Our guide to native vs cross-platform apps covers that trade-off.
• Third-party integrations such as accounting sync, CRMs or data providers.

Design, marketing pages and settings screens matter, but they rarely decide whether a project lands at the low or the high end of a range.

How we turn a fintech scope into a fixed price

We price fintech work in two steps so the build price is fixed before you commit to it. The Discovery Sprint produces the scope; the build is then quoted as one fixed price, paid in milestones.

What the two-week discovery covers for a fintech product:

• Which partners hold funds, issue cards or verify identity, and what their APIs and program rules require.
• The money flows, drawn end to end, including failures and reversals.
• The permission model and the admin tools operations will need on day one.
• What is in the first release and what waits, with each cut explained.
• A fixed build price and milestone plan.

The build is then quoted as one fixed price inside the band above, set by what discovery found. If the program is bigger than that, for example several products or markets at once, a dedicated team from $12k per month is usually the better fit. Our post on how fixed-price software works explains what is fixed and what is not.

What a fintech app costs to run after launch

Running costs are mostly usage-based provider fees, and they can matter more than the build over three years. Get every provider’s fee schedule in writing during discovery, and model them against your expected users and transactions.

Typical running costs:

• Partner fees: banking program, card issuing and wallet provider fees, often per account, per card or per transaction.
• KYC fees: charged per verification, including the ones that fail.
• Hosting and monitoring: usually small next to provider fees for an early product.
• Security reviews and audits that partners or your own compliance team require.
• Ongoing development: partners change APIs and program rules, operating systems update, and regulations move.

Tip

Model fees before you sign

Get every provider’s fee schedule in writing during discovery and model it against your expected users and transactions. Usage-based fees can matter more than the build over three years.

How to cut fintech development cost without cutting compliance

The cheapest fintech build is the one that ships a narrow first release on top of strong partners. Cut scope, not controls.

• Launch one money flow first. For example accounts and cards, then collections, rather than every rail at once.
• Pick partners before you design screens. Their onboarding and program rules shape your flows.
• Keep raw card data out of your systems with tokenized cards and hosted components.
• Build the admin tools in the first release. Operations without tooling is the most expensive manual process in fintech.
• Use one codebase across platforms where performance and device features allow it.

Scope checklist before you ask for a fintech quote

Bring answers to these questions to any vendor, including us, and the quote you get back will be far more accurate:

• Who holds customer funds, and is that partner already chosen?
• Which money rails do you need at launch: cards, ACH, wires, stablecoins?
• Which platforms at launch: iOS, Android, web?
• Who are the user roles, and what can each one do with money?
• What does your operations team need to see and do every day?
• Which markets, and what has counsel said about licensing in each?

If you have those answers, request a Discovery Sprint and we will turn them into a fixed quote. You can also see how we approach the sector on our fintech software development page and our pricing page.

Originally published at apptycoons.com.

Choosing an AI agent development company is hard because every vendor’s demo looks good. Demos run on clean data, happy paths and a presenter who knows what to type. Production agents run on messy data, edge cases and users who don’t. This checklist is built to tell those two apart.

It is vendor-neutral on purpose. It ranks no one, it recommends no list, and it works for any team you are talking to. Disclosure: Apptycoons builds AI agents, so at the end we answer the same twelve questions about ourselves, and you can hold us to them.

Why demos are a poor way to choose an AI agent vendor

A demo shows that a model can do a task once; a production agent has to do it thousands of times, safely, with a record of what it did. The questions that separate vendors are about evaluation, permissions, failure handling and ownership, and none of them show up in a demo.

It also helps to know what a good vendor will often recommend: less agent than you expected. Anthropic’s engineering guidance on building agents advises finding the simplest solution possible and adding complexity only when needed, and distinguishes fixed workflows from agents that direct their own steps. A vendor who proposes a simple workflow where it fits is usually a better sign than one who proposes a multi-agent system for everything.

1. Can they show an agent running in production?

The strongest evidence is a live product you can use, or a customer you can call. Ask what the agent does, how long it has been live, what broke after launch and how they found out.

Good answers are specific: a monitoring dashboard, a class of failure they didn’t expect, the fix and the test they added. Weak answers stay at the level of frameworks and model names.

2. Do they start from your workflow, not their framework?

A good vendor asks about the job before the stack: what triggers it, who does it now, what systems it touches, what a correct result looks like and what a mistake costs. If the first meeting is about frameworks and vector databases, the scoping hasn’t started.

Ask them to describe the first agent in one sentence, with one metric. If they can’t, the project will drift.

3. Can they say what the agent will not do?

Scope is defined as much by exclusions as by features. Ask the vendor to write down which actions the agent may take, which it may only propose, and which it must never touch.

This maps to a real security risk. The OWASP Top 10 for LLM Applications 2025 lists excessive agency, an AI system given more functionality, permissions or autonomy than it needs, as one of the ten main risks. The fix is design, not a disclaimer: least-privilege tool access, separate credentials, and approval steps for anything irreversible.

4. How will they evaluate the agent before and after launch?

An agent without an evaluation set cannot be improved safely. Ask how the vendor will build a test set from your real cases, what score counts as good enough to launch, and how every change to a prompt, model or tool is re-scored before it ships.

Good answers include real examples from your data, a pass mark agreed before the build, and regression testing when models change.

Watch out

Any accuracy promise made before seeing your data is a guess.

5. How do they defend against prompt injection and data leaks?

Ask directly how they handle prompt injection, the first risk on the OWASP list, and sensitive information disclosure, the second. Any agent that reads email, documents, web pages or user input can receive instructions hidden in that content.

Look for layered answers: untrusted content treated as data, tools scoped to the minimum, outputs validated before they trigger actions, sensitive data redacted, and model endpoints configured not to retain your data. Our AI agent guardrails checklist maps ten such controls to the OWASP risks, so you can ask which of them the vendor builds by default.

6. Where does a human approve, and is every action logged?

Every consequential action should have a clear owner. Ask where in the flow a person reviews or approves, how the agent escalates when it is unsure, and whether every action is logged with its inputs and outputs in a way an auditor could follow.

If your industry is regulated, ask how the logs map to your existing controls. Frameworks such as NIST’s AI Risk Management Framework, a voluntary framework for managing AI risk, give you a shared vocabulary for that conversation.

7. Which models do they use, and can you switch?

Models change every few months, so lock-in to one provider is a cost. Ask whether the architecture is model-agnostic, how a model swap would be tested, and what happens to cost and latency if you move.

A good answer is often “we pick per task”. Combined with an evaluation set, that lets you change models with evidence rather than hope.

8. How will it connect to your systems?

Most of the work in an agent project is integration, not prompting. Ask which of your systems the agent reads from and writes to, how authentication works, what happens when an API is down, and whether the agent can do anything a normal user with the same role could not.

9. Who owns the code, prompts, evaluations and data?

You should own everything that makes the agent work: code, prompts, evaluation sets, infrastructure configuration and documentation. Ask for it in the contract, and ask whether the agent can run in your own cloud account.

Then ask the uncomfortable question: what happens to the agent if the vendor disappears? If the answer involves their proprietary platform, you are renting, not buying.

10. What is fixed in the price?

Compare what is fixed, not the headline number. Ask whether there is a paid discovery phase, whether the build price is fixed after it, how payments map to delivered features, and what running costs (model usage, hosting, monitoring) you should expect.

Open-ended time-and-materials with no discovery is not wrong, but it moves all of the risk to you. Our AI agent development cost guide breaks down what a build and its running costs usually include, so you can check a quote line by line.

11. What happens after launch?

Agents need care after launch: models update, data drifts, and users find new edge cases. Ask what support is included, how monitoring works, who watches cost and success rate, and how improvements are scoped.

12. Will they tell you when not to build an agent?

The best signal of an honest vendor is a recommendation against their own interest. Ask: “What would you not automate here?” A good partner will point to steps where a rule, a form or a person is cheaper and safer than a model, or to an off-the-shelf agent that already does the job. Our build vs buy framework for AI agents is a useful way to test that advice.

What to put in the contract

The contract is where the answers to questions 9 to 11 become enforceable. A vendor who answered them well on a call should have no trouble writing them down. Before you sign, check that it covers:

• IP assignment: the code, prompts, evaluation sets, tool definitions and any fine-tuning data are assigned to you, not licensed.
• Accounts: model provider, cloud and monitoring accounts are opened in your company’s name, with the vendor as a user you can remove.
• Data processing: what data the vendor and each model provider may store, where and for how long; for EU personal data that means a data processing agreement (see our guide to the EU AI Act and GDPR for AI agents).
• Acceptance: launch is accepted against the evaluation set and pass mark agreed in discovery, not against a demo.
• Handover: the repository, infrastructure as code, a runbook and the evaluation set are delivered at the end, whether or not you renew.
• Support: how long post-launch support lasts and what a change costs once it ends.

None of these clauses is unusual in software contracts. What changes for AI agents is the list of assets: prompts and evaluation sets are as much part of the product as the code. This is a buyer’s checklist, not legal advice; have counsel review the final terms.

How to check a certification claim

Ask for the document behind the badge, then read its scope and date. A certification or report that covers a vendor’s office IT, or expired last year, says nothing about the team that will build your agent.

• ISO/IEC 42001 is the management-system standard for AI, published on December 18, 2023. A vendor claiming it should show a certificate naming the issuing body, the scope and the validity dates.
• SOC 2 is not a certificate. The AICPA describes it as reporting on an examination of controls at a service organization, carried out by a CPA firm. Ask for the report itself under NDA, check which services it covers and the period it tested.
• “HIPAA certified” does not exist. For health data, ask whether the vendor will sign a business associate agreement and which of its subprocessors will too.

A vendor without a certification can still be the right choice for a first agent if it answers the twelve questions above with evidence. What matters is that any claim on the website matches the document behind it.

Red flags when choosing an AI agent developer

These are the patterns that should end a conversation or at least slow it down:

• Accuracy or savings figures promised before anyone has seen your data.
• No evaluation set, or “we test it manually”.
• No answer on prompt injection or excessive agency.
• Write access to production systems with no approval step.
• Prompts, evals or orchestration kept as the vendor’s intellectual property.
• A demo built on data that is not yours, presented as proof.
• No discovery phase, and no clear statement of what is fixed.

A scoring sheet you can copy

Score each vendor from 0 to 2 on each line (0 = no answer, 1 = general answer, 2 = specific evidence). Compare totals only after the calls, and weigh the first four lines double.

Our answers to the same questions

Here is how Apptycoons answers the checklist. Hold us to it, and ask us for the evidence on a call.

• Production evidence: Innovative AI, voice agents for US car dealerships that matched callers’ requests to a service on the vehicle’s menu, read it back and booked it in Xtime, and Superdeal, an AI agent that runs creator campaigns with the brand approving every step. Both are live products, and both case studies show how the work was built.
• Workflow first: our process starts by mapping one workflow and one metric.
• Limits and approvals: approval steps, escalation rules and full audit logs for every action. On Superdeal, every consequential step goes Draft, Review, Send.
• Evaluation: a test set built from your real cases, scored before launch and again after every prompt, model or tool change.
• Security: least-privilege permissions, PII redaction and zero-retention model endpoints, so your data does not train public models.
• Models: we choose per task from Anthropic, OpenAI, Google or open-source models and keep the model swappable.
• Ownership: the code lives in your repository from day one, the IP is yours, and the agent runs in your cloud or on endpoints you control.
• Pricing: published on our pricing page. Discovery is two weeks at $5,000, credited to the build; builds are fixed at $25k to $120k; a Dedicated Team starts at $12k a month. Every build includes 30 days of post-launch support.
• When not to build: if a rule or a form solves the problem, we will say so. Our post on taking AI pilots to production covers why so many stall.

If that matches what you need, our AI agent development page has the details, and a free AI audit is the fastest way to test our answers against your workflow.

Originally published at apptycoons.com.

An internal assistant that answers 10,000 questions a month from 20,000 pages of company documents costs about $80 to $210 a month in tokens and storage. Indexing all 20,000 pages costs about 20 cents. The vector database and the model, the parts most RAG (retrieval-augmented generation) cost guides price, are the cheap parts.

The money goes into getting your documents into a state where retrieval works, enforcing who can see what, and proving the answers are right. So we price a RAG system the way we scope one: by what the data and the permissions demand.

How much does RAG development cost?

A production RAG system costs $25k–$120k to build with us, as one fixed price. We set it at the end of a two-week Discovery Sprint ($5,000) that tests retrieval on a sample of your real documents, so the quote reflects the data you have rather than a clean demo set.

Running it is the small number. The worked example below lands at about $80 to $210 a month at 10,000 queries, before hosting and monitoring.

What a RAG system is made of, and what each part costs

A RAG system has six parts. The first and the last take the most engineering; the middle ones are mostly configuration and usage fees.

RAG cost by scope

The scope of a RAG system is set by three questions: how many sources, how messy the documents are, and whether different users may see different things. Each answer pushes a project toward one row of the table below. The rows are our own placement of typical scopes inside the published $25k–$120k band, not quotes; the real number comes out of discovery once we have seen your documents.

What drives the price of a RAG system?

Six things move a RAG quote. The vector database and the model are not on the list, because they barely change the build.

Data preparation is the largest cost

Retrieval can only find what ingestion made findable. Scanned PDFs need OCR and layout-aware extraction; tables need to be kept intact rather than split mid-row; duplicate and outdated versions need to be removed or they will be cited as if current. The messier the documents, the more of the build goes here, which is why discovery tests real files.

Number of sources and how fresh they must be

Each source needs a connector, authentication and a sync schedule. Nightly batch syncs are simple; near-real-time updates need change tracking and more careful re-indexing. Five sources cost meaningfully more than one, even if the total volume of text is the same.

Permissions

If everyone can see every document, permissions are free. If a salesperson must never see HR files, every passage needs access metadata copied from its source system, and every query must be filtered by it. Getting this wrong is a data leak, so it needs its own tests. Once the assistant can also call tools, the same filtering has to cover what it may do, not only what it may read; our checklist of guardrails for agentic RAG covers those controls.

Retrieval quality

Basic vector search is quick to set up but misses exact terms such as product codes and names. Combining it with keyword search and adding a reranking step costs more to build and pays back in accuracy. In Anthropic’s published tests, contextual embeddings plus keyword search cut failed retrievals by 49%, and adding reranking took the cut to 67%. Preparing the contextualized chunks cost about $1.02 per million document tokens, once.

Evaluation

An evaluation set is a list of real questions with known correct answers and source passages. It is how you know a change made things better rather than worse. Building it takes time with your subject-matter experts, and it is the part most often skipped in pilots.

Hosting and compliance

Running in your own cloud, using zero-retention model endpoints or self-hosted models, keeping data in a region, and logging access for audits all add work. For regulated data, such as health or financial records, these are not optional.

Worked example: monthly RAG run cost at 10,000 queries

Here is the arithmetic for a mid-sized internal knowledge assistant, using list prices from each vendor’s pricing page.

Assumptions: 20,000 pages of documents at about 500 tokens a page, so 10 million tokens to index. 10,000 queries a month. Each query sends about 6,000 input tokens (the question, instructions and retrieved passages) and gets back about 400 output tokens.

So tokens and storage come to about $80 to $210 a month. At this size the index itself is small: 25,000 passages of 1,536-dimension vectors take roughly 0.15 GB. Add the hosting for your application and sync jobs, logging and scheduled evaluation runs, which depend on your cloud and retention rules.

The same system at 1,000 and 100,000 queries a month

Run cost scales with queries, not with the build. The per-query figures stay the same: about $0.008 on Claude Haiku 4.5 and $0.016 on Claude Sonnet 5.5 for 6,000 tokens in and 400 out.

At 1,000 queries the vector store minimum can cost more than the model, which is an argument for pgvector in a database you already run. At 100,000 the model is the bill, and routing simple questions to the smaller model is worth more than any storage choice. The corpus size barely moves either column: indexing 10 million tokens costs about 20 cents once.

Score your documents before you get a quote

You can estimate where your project lands before talking to any vendor by scoring your own documents against seven questions. Each “yes” in the middle column pushes the build price up; several together move a project from the bottom of a price band to the top.

Seven “no” answers describe the single-source assistant at the bottom of the scope table. Four or more “yes” answers usually mean the top of the band, or a first phase that leaves the hardest sources for later.

What a RAG system costs after launch

After launch, the model bill is the predictable part; the work is keeping answers right as documents, models and people change. Four recurring jobs make up most of it:

• Re-indexing changed sources, and fixing connectors when a source system changes its API or export format.
• Rerunning the evaluation set after every prompt, chunking or model change, and adding questions users asked that it missed.
• Migrating to a new model when the current one is retired or a cheaper one passes your tests.
• Auditing permissions when teams, roles or clients change, so a passage never outlives its access rule.

Our builds include a post-launch support window; after that, the work runs as small fixed-price changes or a Dedicated Team, both on the pricing page. Whoever does it, budget engineering time for these four jobs, not only tokens.

How long does a RAG project take?

A typical RAG project takes two weeks of discovery and then 6–16 weeks to build, depending on scope. A single-source assistant with clean digital documents is at the short end. Several sources, per-user permissions and scanned documents push it to the long end, or into phases.

The timeline follows the same drivers as the price:

What slows projects down is rarely engineering. It is waiting for access to source systems, agreeing who may see what, and finding subject-matter experts to write and check evaluation questions. Lining those up before the build starts is the single most effective way to keep the schedule.

RAG vs long context vs fine-tuning: the cost angle

RAG is not the only way to put your knowledge in front of a model, and the alternatives have different cost curves.

Long context has become a real option: Anthropic includes a one-million-token context window at standard pricing on Claude 4.6 and later models, and its retrieval research puts the cut-off for skipping RAG at roughly 500 pages (about 200,000 tokens). Past that size, every query pays for every token. Filling that window on Claude Sonnet 5.5 costs about $2 per query at list price before caching, against roughly $0.016 for the RAG query in our example, a difference of more than 100 times. For a deeper comparison of the architectures, see RAG vs fine-tuning.

When an off-the-shelf tool is enough

You do not always need a custom RAG build. If your documents live in one workspace tool and its built-in AI search answers your team’s questions well enough, use it. The same applies if a document-chat product already connects to your sources, respects their permissions and keeps your data where your policies require.

Custom RAG is worth paying for when answers must come from several systems at once, when per-user permissions are strict, when documents are scans or complex tables, when the assistant must act through tools rather than only answer, or when it is part of a product you sell. If none of those apply, start with what you have. We set out a fuller decision method in build vs buy AI agents.

A real example: document intelligence in Relm

Relm, a commercial real estate platform we built, shows what the top end of the scope table involves. Its document intelligence runs OCR, extraction and vector search across rent rolls, offering memoranda, P&Ls and leases. Every finding is traceable to a source record, and tenant isolation covers the database, the vector store and the AI context, so one firm’s documents can never surface in another firm’s answers. The work that made it reliable was ingestion, citations and isolation, exactly the drivers above, not the choice of vector database.

How to keep RAG development cost down

The cheapest RAG project is a narrow one that grows on evidence.

• Start with one source and one group of users, and add sources once answers are trusted.
• Prototype on your messiest real documents in discovery, not a clean sample.
• Write fifty real questions with known answers before the build starts; they become your evaluation set.
• Use the database you already run for vectors unless scale says otherwise.
• Route simple questions to a smaller model and cache stable instructions.
• Keep regulated documents out of version one if the use case allows it.

To get a fixed price on your own documents, start with a free AI audit from our enterprise LLM and RAG team. Discovery then ends with retrieval tested on your data and a quote that does not move unless the scope does.

Originally published at apptycoons.com.

Most direct-selling companies start on an off-the-shelf MLM platform. It works until the compensation plan changes, the distributor count passes a few thousand, or the mobile experience starts costing you recruits.

What breaks after that is predictable, and most of it can be designed out before it costs you a payout run.

Where off-the-shelf platforms struggle

• Hybrid compensation plans that mix binary, unilevel and matrix rules.
• Commission runs that take hours and need manual fixes.
• Dated distributor apps that new recruits abandon.
• Payouts that can’t reach modern wallets or cards.

None of these is a flaw in the platforms themselves. They are built to run the plans most companies use, and they do that well. The friction starts when your plan, your payout model or your member experience is the thing that sets you apart, and every change has to wait for a vendor roadmap or a paid customization.

Build, buy or combine?

Buy when your compensation plan is conventional and launching quickly matters more than differentiation. Established platforms come with commission engines that are already in use at other companies, plus replicated sites, e-commerce and reporting. They are not cheap: the software directory Capterra lists Exigo, one of the best-known enterprise platforms, from $5,000 per month, flat rate. But they are proven.

Build when the software is part of the product:

• Your plan mixes structures in ways the platform can only approximate.
• Distributors need near real-time earnings, not a nightly or weekly run.
• Earnings should land in a wallet or on a card, not only a bank transfer.
• You sell bundled services, such as subscriptions or financial products, that the platform does not model.

Combine the two when only part of the stack is the differentiator. A common pattern keeps a platform for orders and the commission run, and builds custom distributor apps, onboarding and payouts around it. We compare the main options, and how to migrate between them, in Exigo alternatives: when custom MLM software wins.

What MLM software costs in 2026

MLM software costs either a recurring platform fee or a one-off build plus running costs, and the two are hard to compare until your plan is written down. On the platform side, the software directory Capterra lists Exigo from $5,000 per month, flat rate; most enterprise vendors don’t publish prices at all. Packaged MLM scripts are cheaper to start with, and what they buy you is a set of templates: the further your plan sits from them, the more of the saving goes on customization.

On the custom side, our model is a two-week Discovery Sprint ($5,000, credited to the build) that turns your compensation plan into written rules, then one fixed price inside our $25k–$120k range, delivered in 6–16 weeks. Where an MLM build lands in that band depends on four things. The placements below are our judgment, not client budgets:

Add the time for at least one commission cycle run in parallel with your old system before payouts switch. That cycle sets the go-live date more often than the code does. For a three-year view of platform fees against a custom build, use the exit and pricing questions in our Exigo guide above.

Compensation plan types your engine must handle

The compensation plan decides how much of the engine is hard. These are the structures most plans combine:

• Binary: each distributor has two legs, and commissions usually pay on the volume of the weaker leg, with carry-forward rules for the stronger one.
• Unilevel: unlimited frontline recruits, with commissions paid on a set number of levels below each distributor.
• Matrix: a fixed width and depth, so new recruits beyond the width spill over to lower levels.
• Stair-step and breakaway: ranks raise the commission percentage, and leaders who reach a rank break away into their own group with an override.
• Hybrid: any mix of the above, plus fast-start, matching and leadership bonuses.

Around the structure sit the rules that cause most commission errors: rank qualification windows, compression when inactive distributors are skipped, caps, breakage, and how returns and refunds claw back commissions already paid.

A worked binary commission example

A binary payout is simple arithmetic repeated across thousands of people, which is why small rule ambiguities turn into large payout errors. Here is one distributor over two weeks under a common binary rule: 10% of the weaker leg’s volume, the stronger leg’s unused volume carried forward, and a weekly cap of 100. These are illustrative numbers, not a client plan.

The table looks settled until the questions start, and each one is a rule your engine has to store:

• Refunds. If a 200-point order in the left leg is refunded in week 2, is week 1 recalculated and the difference clawed back, or is the refund deducted from week 2’s left leg?
• The cap. If week 2 had paid 130, does the 30 above the cap disappear, or carry forward as volume?
• Flush. Many plans reset carried volume when a distributor misses a qualification, so the 600 points on the right may be worth nothing next week.
• Compression. In the unilevel part of a hybrid plan, if a distributor two levels down is inactive, the next active distributor below moves up a level for that period, which changes who earns on whose volume.

Write the answer to each question into the plan document before anyone builds, and keep a test period like this one for every rule. When the engine and the document disagree, the document wins, and the test tells you which code to change.

What a custom platform should include

• A rules-driven compensation engine you can change without a rewrite.
• Genealogy, ranks and bonuses calculated in near real time.
• E-wallets and debit cards so earnings are spendable immediately.
• A distributor app that makes enrollment and team tracking effortless.

Add an admin back office with commission previews, adjustments and an audit trail, an enrollment funnel that works on a phone, and reporting that finance and compliance can both use.

How to design a commission engine that doesn’t break at scale

Commission engines rarely fail on day one. They fail when the plan changes, a period has to be re-run, or the genealogy grows deep. Five design choices prevent most of that:

• Store the plan as versioned rules, not code, so each period is calculated with the rules that applied at the time.
• Make every run deterministic and repeatable: the same inputs always produce the same payout, so a corrected period can be re-run safely.
• Record every commission as a ledger entry with its source order and rule, so any distributor’s statement can be explained line by line. Affiliate programs need the same ledger, which is why the trade-offs in affiliate commission tracking: build vs buy carry over almost unchanged.
• Treat returns and clawbacks as first-class events, not manual adjustments.
• Preview runs before they pay out, and test with synthetic genealogies far larger than today’s network.

What breaks at 100,000 distributors

Scale problems in MLM software are predictable, which means they can be designed out. The usual pressure points are:

• Deep genealogy queries: calculating volume across many levels gets slow if every query walks the tree from scratch, so store precomputed paths or closures and update them as the network changes.
• Period close: thousands of distributors check their earnings at the same moment the commission run finishes, so statements should be generated ahead and served from a cache.
• Event spikes: enrollment surges during launches and conventions, so the sign-up flow and payment provider must handle bursts without double-charging or losing a placement.
• Mobile performance: team views with thousands of members need pagination and search, not one long list.
• Support load: when an earning looks wrong, support staff need the same line-by-line explanation the ledger gives finance.

Test each of these with synthetic data well above your current size before a launch event, not after.

Compliance is part of the software

Compliance in direct selling is mostly about evidence, and the evidence lives in your software. The FTC’s business guidance on multi-level marketing focuses on whether rewards come from sales to real customers rather than recruitment, looks at how the company operates in practice rather than what its policies say, and requires earnings claims to be truthful, substantiated and typical of what participants earn.

That translates into concrete features: tracking retail customers separately from distributor purchases, reporting personal consumption, producing earnings data for income disclosures from real payouts, and keeping marketing claims in the app consistent with that data. This is not legal advice, and your counsel should define the rules; the point is to build the platform so it can prove them.

“Your compensation plan is your product. The software should bend to it — not the other way around.”

Payouts: wallets, cards and bundled services

For Freedom Pro, we combined a partner back office with Bridge-powered USD and stablecoin wallets and debit cards, so partners earn and spend in one place.

Its wireless, streaming, wellness and finance services sit behind one member account, and partners enroll customers, track their team and get paid from a single dashboard. The full build is in the Freedom Pro case study, and the wallet side is covered in how stablecoin wallets fit into an app. Whatever the rail, distributors judge payouts by their statements: a schedule they can predict and a line for every amount, the same payout schedules and statements problem creator platforms face.

Moving off a platform without breaking commissions

If you are migrating, run both systems in parallel. Move distributors, genealogy and commission history first, recalculate past periods in the new engine, and switch payouts only when both produce the same numbers. Distributors forgive a new app; they do not forgive a wrong commission. The Exigo guide linked above has a step-by-step version of this plan, from exit terms to cut-over.

If you are weighing a custom build, our MLM software development work starts with your compensation plan and payout model, and you can see how we price discovery and fixed-price builds on our pricing page.

Originally published at apptycoons.com.

A Freedom Pro member signs up, picks the services they already pay for, and earns on their team’s activity. The earnings land in a USD or stablecoin wallet, and a debit card spends them. Nobody in that flow has to know what a blockchain is. Behind it sit a stablecoin provider’s API, a ledger we built, and a lot of decisions about who holds the money.

This guide covers those decisions in the order a product team meets them: which kind of infrastructure to use, how the integration works call by call, what the 2026 rules mean in the US and the EU, and when stablecoins are the wrong tool.

The fastest way to add stablecoin wallets to an existing app

The fastest way is to let a regulated orchestration provider hold the funds and run the regulated steps, while your app owns onboarding screens, the ledger and the interface. You integrate through its API instead of holding crypto yourself.

A first release that ships quickly usually looks like this:

1. Hosted identity checks. Use the provider’s hosted KYC flow at first. Building your own document capture can wait.
2. Custodial wallets. The provider creates and holds a wallet per customer. You never touch private keys.
3. One transfer type. For example, bank dollars in through a virtual account and converted to a dollar stablecoin. Add withdrawals and wallet-to-wallet sends after the first one is reconciled daily without surprises.
4. Cards second. A card program adds lifecycle states, disputes and spend controls. Launch it once balances are trusted.

Bridge’s documentation shows how much of this one provider can cover: virtual accounts that accept USD, EUR, GBP, MXN and more, each with a unique account and routing number; orchestration APIs for on-ramps, off-ramps and crypto-to-crypto transfers; custodial wallets; cards backed by stablecoins; and issuance of your own stablecoin.

Four kinds of stablecoin wallet infrastructure

Stablecoin infrastructure comes in four broad kinds, and the kind you pick decides who holds keys, how much you build and how much regulatory weight lands on you. Vendor lists mix them together, so separate them before you compare prices.

Most fintech and platform products start in the first row. Embedded wallets fit crypto-native users. Issuance is a business decision about becoming a stablecoin brand, not a wallet feature, and under the GENIUS Act it brings issuer-level rules.

Custodial or non-custodial: who holds the keys decides your obligations

Whoever can move the funds carries the obligations, so decide custody before you design screens. In a custodial model the provider holds the keys; in a non-custodial model the user does, and your app helps them sign.

The OCC’s 2026 proposal shows how regulators think about it. As summarized by Mayer Brown, a custodian has “control” of a tokenized asset when “no other party can transfer the asset on a distributed ledger without the custodian’s consent.” That is a useful test for your own design: if your servers can move a user’s balance without them, assume you are in a custody conversation, and take it to counsel.

For consumer products, custodial wallets with a regulated provider are the practical default. Users get password resets and support. You get a partner that runs sanctions screening and can freeze an account when asked.

How a stablecoin wallet integration works, step by step

An integration is a sequence of provider objects and events that your ledger mirrors one for one. The exact names vary by provider; the shape is the same:

1. Create the customer in the provider with your own user ID stored beside the provider’s ID.
2. Run identity checks, hosted or through the API, and listen for the result by webhook.
3. Open the money objects: a wallet, a virtual account for bank deposits, or both.
4. Move money with a transfer request: deposit, conversion, withdrawal or send.
5. Receive webhooks for every state change and write each one to your ledger.
6. Reconcile your balances against the provider’s records on a schedule.
7. Issue a card on the balance, once the steps above run cleanly.

Each object moves through states, and each state needs its own screen copy. These are the ones a first release has to handle:

For retries, Bridge’s API reference requires an Idempotency-Key header on every POST request and says not to send one with GET, PUT, PATCH or DELETE. The key holds for 24 hours after the first request, a retry must send the identical request body, and reusing the key after the 24 hours returns a 422 error.

Watch out

Retries are where wallets pay twice

Generate the key once per user intent, store it with the pending transfer, reuse it on every retry inside the window, and treat a retry after the window as a new transfer that needs a fresh check of the user’s balance.

Ledger rules that prevent wrong balances

Most bugs in wallet products are ledger bugs, not interface bugs. Your ledger is the record your support team, your finance team and your users read, and the provider’s records are what it must match.

• Store both IDs. Every customer, wallet, destination and transfer carries your ID and the provider’s ID side by side, so support can search either.
• Append, never edit. A reversal or a fee is a new entry linked to the original one.
• Let webhooks drive state. Your app requests; the provider’s events confirm. A screen never shows “completed” on the strength of an API response alone.
• Replay safely. Webhooks arrive twice and out of order. Process them by event ID, idempotently.
• Reconcile daily, alert on any difference. A wallet that shows “pending” honestly loses less trust than one that shows a wrong balance for a few minutes.

What the GENIUS Act means for a product team in 2026

The GENIUS Act is the US federal law for payment stablecoins, and its rules are still being finished. It was signed on July 18, 2025, and takes effect on January 18, 2027, or 120 days after final implementing regulations if that comes first.

Where the rulemaking stands, as of October 18, 2026:

• No final rule yet. Comptroller Jonathan Gould said on August 19, 2026: “We will have a final rule out by November” (reported by PYMNTS). At DC Fintech Week on October 15 he said publication was expected “in the very near term”, and the OCC was reported to be targeting the end of October (GNcrypto, October 16, 2026). As of October 18, 2026 no final rule had been published. Check the OCC’s news releases before you rely on any detail below.
• Reserves: permitted issuers hold identifiable, segregated reserve assets backing outstanding coins at least one to one.
• Yield: issuers may not pay holders interest or yield, and the proposal would create a rebuttable presumption that certain affiliate and third-party arrangements involving issuers violate that ban.
• AML and sanctions standards come in a separate proposal.

Three product decisions follow. Pick coins and providers that will operate as permitted issuers or work with them. Run every “rewards on your balance” idea past counsel before design, because a third-party arrangement is exactly what the proposal looks at; Stripe, for example, documents rewards on eligible stablecoin balances for its own business Treasury accounts, which is a different product from a consumer feature you build. And expect identity and sanctions checks to stay strict, because for your provider they are a legal obligation.

Serving EU users: MiCA and which stablecoin you offer

In the EU the coin itself has to fit MiCA, so the stablecoin you offer may differ by market. MiCA treats dollar and euro stablecoins as e-money tokens, and on January 17, 2025 ESMA and the European Commission said national regulators should make sure crypto-asset service providers stop offering non-compliant tokens as soon as possible, and no later than the end of the first quarter of 2025.

Circle says it holds an e-money institution license from France’s ACPR and that USDC and EURC are issued in the EU in compliance with MiCA (Circle press release, July 1, 2024). For an EU launch that usually means three checks:

• A coin whose issuer is authorized under MiCA, such as USDC or EURC, confirmed with the provider on the day you launch.
• A provider or partner licensed to serve EU users, not only US ones.
• Screens and disclosures reviewed for each market you open.

We haven’t shipped an EU stablecoin product yet, so read this section as guidance from the public sources above, not as experience, and not as legal advice.

Design for people who don’t care about crypto

Most users want dollars that move fast, so show balances in USD, hide chain details by default, and make the card the hero.

Use words like “balance”, “send” and “card” in the main flows, not “wallet address” or “network”. Advanced users can still find the chain, the transaction hash and the destination on a detail screen. Confirm every outgoing transfer with the amount and destination in plain words, because a stablecoin sent to the wrong address is hard to get back. Receipts matter more as money moves faster.

When stablecoin wallets are the wrong choice

Stablecoins are the wrong rail when your users need what a bank account gives them: deposit insurance through a partner bank, checks, cash deposits and ATMs. In that case a partner bank and a card program fit better.

Switch, a shared banking app we built for clubs and teams, made exactly that choice: Thread Bank as its FDIC-insured partner bank and Visa debit cards, with no stablecoins. Stablecoins earn their place when money crosses borders, settles outside banking hours, or lands as platform earnings that users want to hold and spend in one account, as they do on Freedom Pro.

What adding stablecoin wallets does to timeline and budget

A focused wallet integration fits inside one of our fixed-price builds of $25k–$120k, delivered in 6–16 weeks after discovery; what moves it up the band is how many money paths it has. These are the usual drivers, in our judgment:

• Transfer types. Each one (deposit, conversion, withdrawal, send, payout) adds states, webhooks, failure screens and reconciliation rules.
• Cards. Card lifecycle, limits, disputes and wallet provisioning add a second integration.
• Markets. US plus EU means two coin and partner checks and two sets of disclosures.
• Your own onboarding UI instead of the provider’s hosted flow.
• Operations tooling. Search by provider ID, holds, case notes and exports for support and compliance.

Provider fees, KYC checks and card program costs come on top and are usage-based. For full scopes of two fintech products and their line items, see our guide to fintech app development cost; our pricing page lists the Discovery Sprint and build terms.

Launch checklist for stablecoin wallets

Before real money moves, check each of these:

• Money flows drawn end to end, with counsel’s sign-off on who holds funds at each step.
• Sandbox tests for every transfer type, including failures, returns and late webhooks.
• One idempotency key per user intent, stored with the transfer and reused inside the provider’s window.
• Webhook replay test: the same events delivered twice and out of order leave balances unchanged.
• Daily reconciliation with alerts, and a support view that searches by provider ID.
• Onboarding tested for approved, pending-review, rejected and limited customers.
• Coin and provider confirmed for every market you launch in.
• Copy reviewed for anything that implies deposit insurance, interest or yield on a stablecoin balance.
• Limits for new accounts and a fast way to freeze one when the provider asks.

How Freedom Pro uses it

On Freedom Pro, stablecoin wallets are where a partner network gets paid. Partners earn on their team’s activity in the back office, and earnings arrive in USD or stablecoin (USDC) balances that members spend by debit card, under the same single sign-on as the platform’s wireless, streaming and wellness services. Bridge provides the wallets and the card program; we built the product around it, from the member portal to the back office. That makes Freedom Pro a bundled financial services platform as much as a direct-selling one, and the commission side is covered in our guide to MLM software and commission engines.

If you are adding wallets or cards to an existing product, our fintech app development team starts with the provider choice and the money flows, then builds the ledger and the apps.

Originally published at apptycoons.com.

Every leadership team has seen the demo: a chatbot that answers questions about the company handbook, or an agent that drafts a customer reply in seconds. Six months later, almost none of them are in production.

The failure pattern is consistent, and it is not about model quality. Pilots are built under ideal conditions — clean sample data, a friendly test group, no integrations. Production removes every one of those assumptions at once.

The four reasons pilots stall

• No business metric. Teams measure whether the tool “works”, not whether it moves cost, revenue or cycle time.
• Data that isn’t ready. Curated demo data hides the messy, partial inputs real systems produce.
• No integration plan. An agent that can’t read from or write to your systems of record is a toy.
• Unclear ownership. AI teams, IT and the business unit each assume someone else will run it.

Each of these is invisible in a demo. Without a metric, the end of the pilot produces a debate instead of a decision, and debates tend to end in “not yet”. Without real data, the first week in production surfaces scanned PDFs, missing fields and edge cases the prototype never saw. Without integrations, someone has to copy results into the CRM by hand, and the time saved disappears. And without an owner, nobody updates prompts, watches costs or answers the first support ticket.

“A successful demo answers whether the model can work. Production readiness asks whether the whole system keeps working under real conditions.”

What the research says

Four widely cited studies agree on the direction, though each measures something different. Read the “what it measured” column before quoting any of them.

Industry research points the same way on causes too. BCG’s 10-20-70 rule holds that only about 10% of the value of an AI transformation comes from the AI application itself, 20% from the underlying data and technology, and the remaining 70% from redesigning workflows, culture and governance. Gartner’s forecast is blunter: more than 40% of agentic AI projects canceled before 2028, and the reasons it gives (rising costs, value nobody can show, weak risk controls) are all about how the project is run, not which model it uses.

Gartner’s June 2025 forecast also warned about “agent washing”, the rebranding of existing assistants, RPA and chatbots as agents, and described most agentic projects at the time as early experiments driven by hype. The MIT NANDA report adds a finding about how companies build: according to Fortune’s summary, buying from specialized vendors and building partnerships succeeded about 67% of the time, while internal builds succeeded about a third as often. Read together, the message is that the bottleneck is organizational and architectural, not the model. We weigh the build-or-buy question in more depth in build vs buy AI agents.

What the 5% do differently

The order matters. Picking the workflow and the number first decides which data you need, which systems the agent must touch, and where a person stays in control. Choosing a model is one of the last decisions, and the easiest to change later.

A production-readiness checklist for AI agents

Before an agent goes live, every item below should have an owner and an answer:

• Metric and baseline: the number the agent must move, measured before launch so improvement can be proven.
• Evaluation set: real past cases with the correct outcome, rerun on every change to prompts, models or tools.
• Integrations: read and write access to the systems of record, with error handling, rate limits and a rollback path for writes.
• Permissions: the agent sees only what the user it acts for may see, enforced outside the model. Our list of production guardrails covers how.
• Human approval: consequential actions, such as sending, paying or deleting, wait for a person until the data shows they can be automated.
• Audit log: every input, tool call, output and approval is recorded and searchable.
• Monitoring: accuracy, exception rate, latency and cost per task tracked weekly, with alerts.
• Ownership: a named team that runs the system, handles support and decides on changes.

None of this is exotic. It is the same discipline any production software needs, applied to a component that behaves less predictably than ordinary code. If what you have is an app built with an AI app builder rather than an agent, the matching list is our checklist for taking a vibe-coded app to production, and our prototype to production service does that work for you.

Questions to answer before you start a pilot

Most failed pilots could have been predicted on day one. Before committing budget, answer these in writing:

• Which single workflow will change, and who does it today?
• Which number will prove success, what is it now, and what result would justify a full build?
• Where will the data come from in production, and have we looked at a real sample, not a cleaned one?
• Which systems must the agent read from or write to, and who owns access to them?
• Which actions need a person’s approval, and who is that person?
• Who will run the system after launch, and what budget covers running costs?

If any answer is “we’ll figure it out later”, that is where the pilot is most likely to stall. A good discovery phase exists to turn each of these into a concrete answer before the build is priced.

When to stop a pilot: continue, change or kill

A pilot should end in one of three decisions, and the criteria for each should be written down before it starts. Without them, a stalled pilot drifts for months because nobody wants to call it.

“Change” is the most common honest answer, and it should come with one specific change and a date for the re-test. Two rounds of “change” on the same check usually mean “stop”. We don’t publish universal thresholds, because a 10% gain is a win in one workflow and noise in another; what matters is that the number exists before the pilot does.

Two examples from our own builds

Superdeal avoids the integration trap: its agent works inside the same campaign workspace as the creators, deals, deliverables and shipments, so nothing is copied between tools and the time it saves stays saved. And nothing the agent drafts is sent until someone on the brand’s side approves it.

Relm, a multi-agent system for commercial real estate due diligence, had a trust problem to solve before a usage one: an analyst will not put a number from an AI into an investment memo unless they can check it. So every finding links to its source record, and each client firm’s data is kept apart at every layer the AI touches, from storage to the model’s context. Those two choices are what let an analyst rely on it.

Structure the engagement for production, not for a demo

We structure our own engagements around the questions above. The Discovery Sprint takes two weeks, costs $5,000 (credited to the build) and ends with a working prototype on your data. It answers the questions that sink pilots: is the data good enough, which integrations are needed, where must a person approve, and what will it cost to run. The build that follows is quoted at a fixed price and usually takes 6–16 weeks, delivered in two-week sprints with live demos and billed against working features. So the path from first workshop to a production launch is two weeks of discovery plus the build, not an open-ended pilot phase.

You can see the plans on our pricing page, what drives the number in AI agent development cost, and why we prefer this contract shape in fixed price or time and materials.

If you have a pilot that stalled, or one you want to get right the first time, our AI agent development team can take it from prototype to production.

Originally published at apptycoons.com.

A companion app has 20 electrodes on the other end of its Bluetooth connection, and a dropped packet is not a spinner: it is a workout that stops halfway, on a person.

OHM Fitness ran its EMS training only in studios. To grow beyond them, OHM needed an app members could use at home to drive the emPower Suit, a wearable with 20 electrodes, safely and without a trainer in the room. We built that app, native on iOS and Android. This guide is what we would tell any team starting a BLE companion app, and it pairs with our IoT and BLE app development page, which covers the device-to-cloud side.

What we learned building OHM at Home

• Pairing must be one tap, with clear recovery when it fails.
• Control commands need acknowledgements and timeouts, never fire-and-forget.
• Safety limits live in both firmware and app, never just one.
• Test on the phones your users own, not on an emulator.

The rest of this guide expands each lesson with the platform rules that apply in 2026, checked against Apple and Google documentation on October 18, 2026.

Pairing people can recover from

Pairing is the first experience every user has, and the first place a connected product can fail. One tap is the goal, but recovery matters more: Bluetooth switched off, a permission denied, a suit that is not charged, or a phone that remembers an old connection. Each needs a plain message and a single next step, not a generic error.

Both platforms now offer a pairing flow designed for companion apps, and it is worth using them on a new build:

• iOS 18 and later: AccessorySetupKit. The app hands the system a description of its accessory, and iOS shows a picker with the product name and image. One tap pairs it and grants the app access to that accessory. Apple’s WWDC24 session says apps that declare AccessorySetupKit support do not show the Bluetooth permission prompt at all. Accessories that need stronger security still show pairing UI such as numeric comparison or a passkey.
• Android 8.0 and later: companion device pairing. The system scans on the app’s behalf, without the app holding ACCESS_FINE_LOCATION, although Location Services must be switched on. After the user associates a device, the app can request permissions to run and use data in the background and to start a foreground service from the background.

On Android 12 and later, an app that scans and connects on its own must declare and request BLUETOOTH_SCAN and BLUETOOTH_CONNECT. Design the permission screens early; a denied permission is a pairing failure the user caused without knowing it.

Keeping the connection alive in the background

A BLE app can keep working when the phone locks, but the platforms limit how, and the product has to be designed around those limits. Decide in discovery what the device does when the app goes to the background mid-session, because that answer shapes both the firmware and the app.

On iOS, the bluetooth-central background mode lets an app keep discovering, connecting to and exchanging data with peripherals while it is in the background, and the system wakes the app when a Bluetooth event arrives. Three limits matter:

• Scanning slows down. Background scans coalesce repeated advertisements into one event and scan less often, so finding a device can take longer.
• Wake-ups are short. Apple’s guide says an app has around 10 seconds to complete a task after it is woken, so keep that work small.
• The app can be terminated. With state preservation and restoration, iOS remembers the peripherals the app was connected to and the characteristics it subscribed to, and relaunches the app with that state when something happens.

On Android, background work for an associated device runs through the companion permissions above and a foreground service, which shows a persistent notification while the session runs.

Watch out

The device must be safe without the app

Whatever the platform allows, design the device so that a phone that locks or loses the connection cannot leave it running unchecked. The app can lose its process at any time; the device cannot depend on it.

Real-time control needs acknowledgements

A command to change intensity is not done when the app sends it; it is done when the device confirms it. Every command should expect an acknowledgement and have a timeout, and the interface should show what the device reports, not what the app requested. When a connection drops mid-session, the app has to decide quickly and predictably what happens next, and the device has to be safe even if the app never reconnects.

Designing the command protocol

Write the protocol down and agree it with the firmware team before app work starts. A protocol that only exists in chat messages gets implemented two different ways, once in firmware and once in the app.

A protocol that holds up in production has these properties:

• Versioned. The device reports its protocol version on connect, and the app refuses or adapts to versions it does not know. Firmware updates will happen; the app must not guess.
• Absolute, not relative. “Set zone 3 to level 12” survives a retry; “increase zone 3 by one” applied twice is a different session.
• Acknowledged. Every write gets a reply with the resulting state, and the app treats a missing reply as a failure after a fixed timeout.
• Recoverable. After a reconnect, the app reads the device’s current state before sending anything, instead of assuming nothing changed.
• Small. Bluetooth Low Energy packets are small, so compact binary messages with a documented layout beat JSON on the wire.

The document should also list every error the device can return and what the app shows for each one.

Safety limits live in two places

With wearable hardware, the firmware is the last line of defense: it enforces hard limits whatever the app sends. The app enforces the same limits in the interface, adds session rules and guidance, and never offers a setting the device would refuse. OHM’s app carries those rules into each workout as session limits and intensity guardrails.

Security belongs in the same conversation. Android’s documentation warns that once devices pair over Bluetooth Low Energy, the data they exchange is accessible to all apps on the phone, so sensitive data needs its own app-layer encryption. NIST IR 8259A gives a voluntary baseline for the device side, with six capabilities: device identification, device configuration, data protection, logical access to interfaces, software update and cybersecurity state awareness. Its software update capability, updates only by authorized entities through a secure mechanism, is the one a companion app most often delivers, because the app is usually how firmware reaches the device.

Test on real devices

Emulators cannot test Bluetooth properly, so real phones and real hardware are where a companion app is signed off. Build a device lab covering the phone models and operating system versions in your user base, and run the same test plan on each:

• First pairing, re-pairing after a reset and pairing with a second phone.
• Permission denied, Bluetooth off and Location Services off on Android.
• Connection loss mid-command, and reconnection with state read-back.
• Background and lock-screen behavior for a full session length.
• Long sessions on a low battery, for both the phone and the device.
• Upgrades: the app over an old firmware version, and an OS update on the phone.

Before the hardware is ready, a simulated peripheral that implements the agreed protocol keeps app work moving. It does not replace the real device for timing and radio behavior.

“With hardware, reliability is the user experience.”

What a hardware companion app costs

A companion app is priced like any other build on our pricing page: a $5,000 Discovery Sprint to settle the protocol, the platforms and the riskiest flow on real hardware, then a fixed price inside the $25k–$120k band. The device layer is what moves it within that band:

• Firmware maturity. A documented, stable protocol is the biggest saving. A protocol still changing every week makes the app chase it.
• Device count. Each model or hardware revision adds pairing rules, commands and test passes.
• Real-device testing time. Long sessions, background behavior and OS upgrades take calendar time, not only engineering time.
• Cloud and data. Syncing sessions, telemetry or memberships to a backend adds a service to build and run; that part is often a cloud architecture job of its own.

Where a given app lands in the band is our judgment after discovery, not a figure we can promise before seeing the protocol.

When you don’t need a custom app

Skip the custom app when someone else’s software already does the job. The device maker’s own app or white-label SDK is often enough for a pilot or a small fleet. If devices already report to a hub or gateway, a web dashboard over that data may be all users need, with no phone in the control path.

And if the firmware is still changing every week, stabilize the protocol first. An app built against a moving protocol is rebuilt, not finished.

A checklist before you start

1. A written command protocol, versioned and agreed with the firmware team.
2. A decision on native or cross-platform for the Bluetooth layer.
3. Pairing flows chosen per platform, including AccessorySetupKit and companion device pairing where they fit.
4. Background behavior defined for a locked phone and a lost connection.
5. Safety limits listed, with which ones the firmware enforces.
6. App-layer encryption for any sensitive data over BLE.
7. A firmware update path, and who signs the updates.
8. A simulated peripheral for development.
9. A device lab that matches your users’ phones.
10. A test plan that covers the six cases above on every release.

Today OHM at Home runs guided sessions in four training modes for members on both app stores, and it gave OHM a remote membership it could not sell before. If you are building a companion app for connected hardware, our mobile app development team can help, and our guide to native or cross-platform covers the framework decision.

Originally published at apptycoons.com.

The phone is still the highest-intent channel most businesses have. Someone who calls is usually ready to book, buy or escalate. For many teams, it is also where revenue leaks without anyone noticing.

That study is from 2016 and covers a small sample, so treat it as a warning sign rather than a benchmark for your business. The better number is your own, and you can work it out in a few minutes with the formula below or with our AI voice agent ROI calculator, which uses the same inputs.

A simple way to estimate your loss

Multiply four numbers: calls per month × the share you miss × the share of callers who would have bought × the value of a new customer. A clinic taking 60 calls a day, missing 30%, converting a quarter of callers at $400 each, is leaving about $54,000 on the table every month. Clinics are a common case because the front desk answers phones and patients at the same time; we cover clinic call handling and its privacy rules on our healthcare page.

Each input has a source you already have:

• Calls per month: your phone system or carrier call log, averaged over every day of the month, including days you are closed.
• The share you miss: missed, abandoned and voicemail calls from the same log. Leave out spam, wrong numbers and existing customers who will reach you another way.
• The share who would have bought: how many answered calls from new prospects become a booking or a sale, from your CRM or booking system.
• The value of a new customer: the gross profit on a first sale, or lifetime value if customers usually come back.

A worked example

Take the clinic above: 60 calls a day is 1,800 calls a month. Missing 30% means 540 missed calls. If a quarter of those callers would have booked, that is 135 lost customers, and at $400 each, $54,000 a month.

The missed-call rate drives the result more than anything else, which is why it is worth measuring rather than guessing:

These are the default inputs of our ROI calculator, so you can start from the same example and change one number at a time.

Why your real number may be lower or higher

The formula gives revenue at risk, not revenue you will certainly recover. Three adjustments make it more realistic.

• Some callers try again. If one in five missed prospects calls back and books, the $54,000 becomes about $43,200.
• Revenue is not profit. At a 50% gross margin, the same example puts about $27,000 of profit at risk each month.
• Lifetime value works the other way. If a new patient or customer usually returns several times, the first sale understates the loss.

Run the numbers both ways. If even the conservative version is large, the problem is worth solving.

What the statistics do and do not tell you

Most articles on missed calls repeat the same few figures, and some of them do not hold up. The 62% figure above comes from a real study you can read: 411 Locals, a marketing company, tracked 85 businesses across 58 industries for 30 days in 2016 and found that 37.8% of calls were answered by a person.

Another figure appears almost everywhere: that 85% of callers who reach no one never call back. We tried to trace it to a primary study and could not find one, so we do not use it in this guide or in our calculator. If you want to know how many of your callers try again, look for repeat numbers in your call log within a day of a missed call.

How to find your missed-call rate in your phone system

Your missed-call rate is the share of inbound calls from real prospects that ended without reaching a person, and every business phone system or carrier portal can export the data to work it out. Take the last full month, not a single busy week.

The plot shows where missed calls come from, and usually it is one of three places. Peak hours, when calls arrive in bursts exactly when staff are busiest. After hours, when calls keep coming and nobody is there. And voicemail, where many callers hang up rather than leave a message. Each points to a different fix: lunch cover, an overflow line or after-hours answering.

Answering service, receptionist or voice agent: what each fix costs

The three fixes are priced in different units: an answering service by the minute, a receptionist by the hour and a voice agent by a one-time build plus a per-minute running cost. Putting them on the clinic example shows where each one wins.

Assume each missed call would have taken 3 minutes to handle, the default in our calculator. At 540 missed calls a month, that is 1,620 minutes.

The arithmetic: Ruby lists $250 for 50 minutes, $395 for 100, $720 for 200 and $1,725 for 500, with no overage rate published, so the per-minute figures are $250 ÷ 50 and $1,725 ÷ 500. A 500-minute plan at 3 minutes a call covers about 166 calls a month, roughly 38 a week. The receptionist figure is the BLS median of $38,010 a year (May 2025) divided by 12, before payroll taxes, benefits and cover for breaks and holidays.

Our reading of the table: under about 38 missed calls a week, an answering service is the cheaper fix. Above a few hundred a month, or when the misses are at night and at peak times, a person answering stops scaling and an agent starts to make sense. These break-points are our arithmetic on list prices, not a quote from any vendor.

What a modern voice agent changes

A well-built voice agent answers every call at once, replies at a natural conversational pace, copes with interruptions and acts on your systems — checking orders, booking slots, updating the CRM. Complex calls go to a person with a full summary attached. Speed matters more than it seems; we explain why in why sub-second latency makes or breaks a voice agent.

“The goal isn’t to replace your team. It’s to make sure no high-intent caller ever hears a ring tone that never ends.”

When does a voice agent pay for itself?

Payback is the one-time build cost divided by what the agent recovers each month, minus what it costs to run. Running costs are mostly per-minute fees for telephony, speech recognition, the language model and the synthetic voice, so they grow with call volume.

Tip

The payback formula

Months to pay back = one-time build cost ÷ (revenue recovered per month minus running cost per month).

On our published pricing, a custom build follows a $5,000 discovery sprint and lands in the $25k–$120k range, fixed before the build starts. Whether that pays back in months or years depends almost entirely on the revenue at risk: a business losing tens of thousands a month to missed calls recovers it far faster than one losing a few hundred. For a line-by-line breakdown of build and per-minute costs, see AI voice agent cost.

What to measure after launch

If you do deploy an agent, measure the result against the same formula, not against a vendor dashboard. Track four numbers each week, starting with a baseline from the month before launch:

• Answer rate: the share of calls that reach a person or the agent, which should be close to all of them.
• Bookings or sales from calls the agent handled, especially after hours and at peak times.
• Transfer rate: how often the agent hands a caller to a person, and whether those callers were helped.
• Cost per handled call, including per-minute fees and the time your team spends reviewing calls.

If the agent books appointments, add booking completion: of the callers who chose to book, how many hung up with an appointment in the calendar. It measures the booking flow only, so read it next to the answer rate. Our Innovative AI case study reports this number for a dealership build, and how AI service scheduling works at a dealership covers the steps behind it.

Listen to a sample of recordings every week as well. Numbers show whether the agent is answering; recordings show whether it is helping.

When a voice agent is not the answer

Sometimes the honest answer is something simpler. If you miss fewer than about 38 calls a week, a 500-minute answering-service plan covers them for $1,725 a month on Ruby’s list price, and a business missing three or four a week fits the 50-minute plan at $250. A small change in staffing, such as staggered lunch breaks, can cost less still. If most calls need judgment a person should make, such as clinical triage or complex complaints, an agent can still take details and book a callback, but it will not recover the whole loss. And if the problem is that nobody follows up on voicemails, fix the follow-up first.

Run your own numbers

Put the figures from your own call log into the ROI calculator linked above; it uses the same formula as this guide, with your call length and per-minute costs. If the result is large enough to matter, see how we build custom AI voice agents that answer, qualify and book calls inside your own CRM and calendar.

Originally published at apptycoons.com.

On DubCam, a fan picks a program at sign-up, 50% of every subscription is attributed to that program, and the money goes out on the 1st of the month with no minimum threshold. That one sentence hides four systems: attribution, a ledger, payouts and tax reporting. It also hides a choice most platforms make too late: is 50% of the price the fan paid, or of what is left after the app store takes its cut?

This guide covers each system with real published fees and the arithmetic, so you can set the rules before the first statement goes out.

What a creator revenue share system needs

A revenue share is four systems that must agree with each other every month:

• Attribution: every payment linked to exactly one creator, by a rule the fan can see.
• Ledger: every split, fee, refund and payout recorded as its own entry.
• Payouts: creators paid on a fixed schedule through a provider that verifies who they are.
• Statements and tax: each creator sees how their number was calculated, and the platform files the forms the law requires.

The percentage in the contract is the easy part. Creators leave when a statement can’t be explained or a payout is late, not when the split is a few points lower than a rival’s.

Attribution: decide who gets credit, once

The most trusted attribution rule is the one the fan chooses. On DubCam the fan picks who to back at sign-up, and renewals follow that choice until the fan changes it. Store the choice on the subscription, keep a history of every change with its date, and show the fan who they are supporting.

Disputes start when credit is inferred, for example from viewing time that nobody outside the platform can see. If your model has to split one subscription across several creators by usage, publish the formula and keep the usage data each split was based on, because a creator will ask.

The ledger: every split as an entry

Each payment should create separate ledger entries for the fee, the platform’s share and the creator’s share, all linked to the original transaction. Refunds and chargebacks create new entries that reverse the old ones; nothing is edited.

Here is one $10 web subscription with a 50% creator share of gross, refunded the next week. The fee is Stripe’s standard US card rate of 2.9% plus 30 cents, as listed in October 2026; the numbers are illustrative, not a client’s.

Whether the processing fee comes back on a refund depends on your processor’s terms, so model it as its own entry rather than assuming. A creator statement is then a filtered view of the creator payable lines, and any line traces back to the payment that produced it.

Gross or net: the store fee decides

App store fees take 15% to 30% of an in-app subscription, so a share of gross and a share of net can differ by more than a dollar on a $10 plan. Apple pays developers 70% of an auto-renewable subscription price in a subscriber’s first year and 85% after one year of paid service; free trials don’t count toward that year. Members of the App Store Small Business Program, for developers with up to $1 million in proceeds in the prior year, receive 85% from the start. Google Play lists 10% plus a 5% billing fee on auto-renewing subscriptions bought through Play Billing by users in the US, EEA and UK (rolled out June 30, 2026) and in Australia and Japan (September 30, 2026), on a developer’s first $1 million of annual earnings.

The last column is the one founders miss. A share of gross on iOS in year one leaves the platform $2.00 of every $10, before hosting, streaming and payout costs. A share of net keeps the platform’s margin steady but pays creators less on mobile than on the web. Neither is wrong. The creator terms must say which rule applies, the ledger must calculate it the same way, and the statement must show it.

Can you send fans to the web to pay?

In the United States storefront, yes. Apple’s App Review Guidelines, section 3.1.1(a), say entitlements “are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps.”

Watch out

The US rule is not global

In other storefronts, links to outside purchasing need a specific entitlement or are not allowed, so check the guidelines for each country you launch in.

A web checkout changes the fee line in the table above, not the creator rule. Record the channel on every payment, and decide whether creators earn the same share whichever way the fan paid. Most platforms keep the rule identical so creators don’t have to understand app store economics.

What payouts cost, and why most platforms set a minimum

Paying a creator has a fixed cost per account and per payout, so small payouts are expensive. Stripe Connect’s pricing where the platform sets its own fees lists $2 per monthly active account (an account is active in any month it receives a payout), 0.25% plus 25 cents per payout, 1% for instant payouts and $2.99 per 1099 form e-filed with the IRS, as of October 2026.

That is why most platforms set a minimum and roll smaller balances into the next month. DubCam pays on the 1st with no minimum threshold, which makes the promise to a small high-school program simple. Paying with no minimum means small balances carry per-payout fees in full, so decide who bears them before launch. It is a product decision, and it should be made with this table in front of you.

Payouts don’t have to leave your platform as bank transfers. Earnings can land in an in-app balance or wallet that creators spend by card, the model behind stablecoin wallet payouts on a platform we built for a partner network.

Refunds, chargebacks and payout timing

Pay creators from settled money, not from payments that can still be reversed. Three rules keep a platform from paying out money it later loses:

• Hold period. Pay a month’s earnings after the refund window for that month has closed, or hold back a reserve until it does.
• Reversals as entries. A refund or chargeback after payout creates a negative entry for the creator, linked to the original payment.
• Negative balances carry forward. Deduct them from the next payout instead of chasing the creator, and show the deduction on the statement.

Tell creators the schedule and the hold rule in writing before their first payout. A late payout explained in advance costs less trust than an early one clawed back.

Tax and identity: what the platform must collect

Verify every creator before the first payout and collect tax details at onboarding, not at year end. Payout providers such as Stripe Connect run identity verification of the people you pay; your onboarding should collect a W-9 from US creators and a W-8 from non-US creators.

In the US, the IRS says payment apps and online marketplaces must file Form 1099-K when a payee’s payments for goods or services exceed $20,000 in more than 200 transactions, and that payees may receive the form for smaller amounts. In the EU, the DAC7 directive (Council Directive (EU) 2021/514, applied from January 1, 2023) requires platform operators to report sellers carrying out certain activities, including personal services, defined as time- or task-based work done at a user’s request. Whether a creator subscription counts depends on the model, so put the question to tax counsel during discovery. This section is not tax advice.

Build or buy a creator payout system

Buy when monetization isn’t your product. Patreon, for example, lists a 10% platform fee on creators’ income for creators who publish after August 4, 2025, plus payment processing, currency conversion and payout fees, as of October 2026. For a creator who only needs a membership page, that is cheaper than any build.

Build when the split, the attribution or the app is the product: a network where fans back a specific program, a share that follows rules no membership tool expresses, or live video and payouts inside one branded app. DubCam is that case. The same build or buy test applies to partner commissions, and the three-year numbers for that decision are in affiliate tracking: build or buy.

A custom build also decides your platforms. Live video and subscriptions on iOS, Android and the web is a different scope from a web-only membership site; the trade-offs between one shared codebase and separate apps are in native vs cross-platform development.

What we learned building DubCam

Letting the fan choose the creator at sign-up made everything downstream simpler. Attribution is a stored field, not a model. A creator’s statement is a list of their supporters’ payments. Support questions about “why did I earn this” have one answer.

DubCam ships as iOS and Android apps plus the web, with a ten-minute free preview before a fan subscribes, in-app purchases on the App Store and Google Play, and automated payouts on the 1st. The no-minimum rule tells a small program that every supporter counts.

What a revenue share build costs

A streaming app with subscriptions, attribution, a ledger and payouts is a fixed-price build within our $25k–$120k range, delivered in 6–16 weeks after a Discovery Sprint. In our judgment, these move it up the band: live video rather than uploads only, iOS plus Android plus web, more than one payout rail, a creator statements portal, and usage-based splits instead of fan-chosen ones. The pricing page has the terms.

If you are planning a creator or streaming product, our live streaming and creator platform development work covers subscriptions, splits and payouts, and our mobile app development team ships the iOS and Android apps.

Originally published at apptycoons.com.

Ask any CTO about their worst vendor experience and you will hear the same story: a project that was “80% done” for six months while the invoices kept arriving.

The averages are only half the story. When Flyvbjerg and Budzier studied 1,471 IT projects, the average cost overrun was 27%, but one project in six was a “black swan” with a cost overrun of 200% on average and a schedule overrun of almost 70%. The risk in software is not that every project runs a little late; it is that a few run catastrophically over, and nobody knows in advance which ones.

Why overruns happen

• Scope is estimated before anyone understands the problem.
• Progress is reported in hours spent, not software shipped.
• Risky unknowns, such as integrations, data and performance, are left until the end.

All three come down to the same thing: the price is set at the moment the buyer and the vendor know least. A contract model can move the risk from one side to the other, but it cannot remove an unknown. Only work can do that.

Fixed price vs time and materials: who carries the risk

The real difference between the two models is who pays when the estimate is wrong. Under fixed price the vendor does; under time and materials the buyer does. Everything else follows from that.

What the contract definitions say

The U.S. government’s procurement rules state the trade-off more bluntly than most vendors do. They govern federal contracts, not private ones, but they are a neutral reference written from the buyer’s side, not a vendor’s.

• Fixed price. FAR 16.202-1 says a firm-fixed-price contract “places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss”.
• Time and materials. FAR 16.601 says a time-and-materials contract may be used “only when it is not possible at the time of placing the contract to estimate accurately” the extent or duration of the work. It must also carry a ceiling price, and a contractor that goes past the ceiling does so at its own risk.

Read together, the rule is simple. Time and materials is the exception for work nobody can estimate, and even then the buyer gets a cap.

A worked example: the same overrun under each model

Take a build estimated at $60,000 and apply the overruns from the Flyvbjerg and Budzier study above: 27% on an average project, and about 200% on the one project in six that becomes a black swan. The figures are illustrative arithmetic, not a client case.

The arithmetic: $60,000 × 1.27 = $76,200, and $60,000 × 3 = $180,000. The cap of $72,000 is 120% of the estimate, a figure we picked for the example.

Two things the table hides. A fixed quote on a poorly understood scope is often higher than $60,000, because the vendor prices in the black-swan risk it is taking on. And under a cap, a vendor that hits the ceiling with work unfinished has every reason to stop. The discovery row is the only one where the price is set after the biggest unknowns have been tested, which is why the quote can be both fixed and close to the real cost.

When time and materials is the better choice

Fixed price is not always right, and a vendor that says otherwise is selling. Time and materials, or a dedicated team on a monthly fee, fits better when:

• The work is research: you are exploring whether something is possible at all.
• The roadmap is ongoing: a product team that reprioritizes every sprint will spend more time on change requests than on software.
• You have strong in-house product leadership that wants to steer week by week.

In those cases, protect the budget with short sprints, a demo at the end of each one, and the right to stop at any time.

When fixed price works

Fixed price works when both sides can describe what “done” looks like: the screens, the integrations, the data, the performance targets and the acceptance criteria. It fails when that description is guessed rather than known, because the vendor either pads the price heavily or protects its margin later by cutting corners. That is why the quote should come after discovery, not before.

The same holds for an app that already exists. If you built a prototype with an AI tool, an audit does the job of discovery, and our production-readiness checklist for AI-built apps lists what it should test before anyone quotes the fix list.

Capped time and materials and other hybrids

Most real contracts mix the two models, and the hybrids are often the best fit. Four are common:

• Capped time and materials. Hourly billing with a not-to-exceed price, the private-sector version of the FAR ceiling. It protects the budget, but only if the contract says what happens at the cap: the vendor finishes at its own cost, or work stops and the remaining scope is renegotiated.
• Fixed price per milestone. The project is split into milestones, each with its own scope, acceptance criteria and price. Later milestones can be re-quoted once earlier ones have answered the open questions.
• Fixed-fee discovery, then fixed build. A short paid phase resolves the unknowns and produces the quote for the build. This is the structure we use, described below.
• Dedicated team. A monthly fee for a stable team that works through a backlog you prioritize. It replaces the fixed price when the roadmap is ongoing, and the protection is the right to stop at the end of any month.

Pick the hybrid by where the unknowns are. Unknowns at the start favor discovery first; unknowns that only appear later favor milestone pricing; a roadmap that never ends favors a team.

How milestone payments work on a fixed-price build

On a fixed-price build, payments follow milestones, and each milestone is a working feature you have seen demoed, not a document or a percentage of hours. That keeps the vendor’s cash flow tied to software you can use.

Agree three things per milestone before work on it starts: what is delivered, how it is accepted (the tests or behaviors that count as done) and what is paid. If a milestone slips, the payment slips with it.

Watch out

Read the payment schedule

A schedule that pays most of the price up front, or that ties payments to dates instead of delivered features, turns a fixed price back into a time-based one.

Fixed price for AI projects

AI work can be priced fixed, but the unknowns sit in different places. The model is rarely the risk. The data is: whether it exists, how clean it is, and whether the agent can reach the systems it needs. The other risk is the quality bar, so agree an evaluation set and a pass threshold before the build is quoted, or nobody can say when the work is done.

That makes discovery more important for AI than for a standard app, because the prototype is the only way to test both on real data. How AI agent budgets break down by agent type is covered in AI agent development cost, and why so many AI pilots never become products in AI pilots to production.

A better structure

Split the work in two. First, a short fixed-fee discovery sprint that resolves the biggest unknowns and produces a prototype. Then a fixed-price build, quoted only once the scope is genuinely understood.

“You shouldn’t pay for a vendor to learn your business on an open-ended clock.”

This is how we sell our own work, and the details are on our pricing page. The Discovery Sprint is a two-week, $5,000 fixed fee, credited to the build: workshops with a senior architect, a working prototype on your real data, an architecture and integration plan, and a fixed-price quote. The build that follows is $25k–$120k depending on scope, runs 6–16 weeks in two-week sprints with live demos, and includes 30 days of post-launch support. Scope is locked after discovery and changes go through change requests. For an ongoing roadmap, a dedicated team from $12k per month replaces the fixed price.

What a discovery sprint should produce

A discovery phase is only worth paying for if it leaves you with something you could take to any vendor. At the end of it you should have:

• A working prototype of the riskiest part of the product, built on your real data or systems.
• An architecture and integration plan that names every external system, how it is accessed and what can go wrong.
• A scope document with features, priorities and acceptance criteria, written in plain language.
• A fixed price, a timeline and a milestone plan for the build.
• A list of assumptions and open risks, each with an owner.

If a vendor’s discovery ends with only slides and an estimate range, the unknowns are still there; they have just been moved into the build.

How to compare quotes from different vendors

Quotes are only comparable when they describe the same scope. Ask each vendor to price against the same scope document, and then compare what each one includes: testing, security review, deployment, documentation, post-launch support and who owns the code. A low hourly rate multiplied by an open number of hours is not a lower price, and a fixed quote that excludes testing is not a fixed price.

How to keep a fixed-price project on track

• Demand a live demo every two weeks.
• Keep the code in your own repository from day one.
• Tie milestones to working features, not documents.

Add two more. Write acceptance criteria for each milestone before work on it starts, so “done” is never a negotiation. And agree the change-request process at the start: who can raise a change, how it is estimated, and that nothing outside the agreed scope is built until you have approved its price.

Questions to ask any vendor before you sign

• What happens to the price if your estimate is wrong?
• What exactly will the discovery phase produce, and do we own it if we stop there?
• How are milestones defined, and what do we see at each one?
• How are scope changes estimated and approved?
• Where does the code live, and who owns the IP?
• What support is included after launch, and what does it cost afterwards?

A good vendor answers each in a sentence. For AI work specifically, we have written a fuller checklist on how to evaluate an AI agent development company.

The same buy-or-commission logic applies before any contract is signed. Sometimes the cheapest fixed price is no build at all; our build vs buy analysis for affiliate tracking shows that comparison on one product category, and our web app development page shows how we scope custom web builds when building does win.

Originally published at apptycoons.com.

Sending a 150,000-token handbook with every question costs about $3,000 a month on Claude Sonnet 5.5 at 10,000 questions. Retrieving only the right passages costs about $160 on the same model, and prompt caching brings the handbook approach down to about $550 on Sonnet 5.5, or $340 on Haiku 4.5. The third option, fine-tuning, got harder to reach in 2026: OpenAI is winding down its fine-tuning platform.

So the old question, retrieve or retrain, now has three answers, and each wins somewhere. Many production systems combine two.

The short answer: retrieve facts, tune behavior

Use retrieval-augmented generation (RAG) to give a model knowledge, and fine-tuning to change how it behaves. Long context sits in between: it works well when the knowledge is small and stable enough to send with every request.

The research backs the first half of that rule. When Ovadia and colleagues compared the two methods for injecting knowledge, RAG consistently outperformed unsupervised fine-tuning, both for facts the model had seen in training and for entirely new ones. Models struggle to learn new facts from fine-tuning alone. Fine-tuning earns its place elsewhere: format, tone, classification and cost.

When retrieval (RAG) wins

• Your knowledge changes weekly or daily.
• Answers must cite a source document.
• Access rules differ by user or team.

RAG searches your documents at request time and gives the model only the passages it needs. That has three practical effects. Updating knowledge means re-indexing a document, not retraining a model. Every answer can point back to the passage it came from, which is what auditors, lawyers and analysts ask for first. And because retrieval runs per request, it can filter by the user’s permissions before the model sees anything.

Our Relm build shows the pattern. Analysts upload rent rolls, offering memorandums, P&Ls and leases; Relm reads them with OCR, indexes them for vector search, and links every finding in its reports back to the record it came from. That traceability is the reason to choose retrieval: a commercial real estate analyst will not act on a number nobody can check.

When long context is enough

If the material is small and stable, skip the retrieval pipeline and put it in the prompt. Anthropic’s guidance is specific: a knowledge base under about 200,000 tokens, roughly 500 pages, can be included in the prompt whole, and prompt caching makes that much faster and cheaper on repeated requests.

Long context has limits that matter in enterprise work:

• Cost per query: you pay for every token on every request, so a large context sent thousands of times a day gets expensive, even with caching.
• Attention: the “Lost in the Middle” study by Liu and colleagues found that models use information at the start or end of a long input much better than information buried in the middle.
• Permissions: one shared prompt cannot easily respect different access rules for different users.
• Citations: pointing to the exact source passage is harder when the model read everything at once.

Long context is a good fit for a policy assistant over one handbook, or a contract review tool that reads one agreement at a time. It is a poor fit for a company-wide assistant over thousands of permissioned documents.

When fine-tuning wins

• You need a consistent format, tone or classification behavior.
• Latency or cost demands a smaller model.
• The task is narrow and examples are plentiful.

Fine-tuning trains a model on examples of the inputs and outputs you want. It is the right tool when prompting cannot reliably produce a strict JSON schema, a house writing style, or a classification label across thousands of edge cases. It can also move a task that works on a large model to a smaller, cheaper and faster one, which matters for voice agents and high-volume pipelines.

OpenAI’s own guidance puts fine-tuning last in the sequence: start with evaluations and prompt engineering, which may be all you need, and fine-tune when prompting alone does not deliver the behavior or performance required. The same guide now notes that OpenAI is winding down the fine-tuning platform, so for new teams that last step happens somewhere else. We follow the same order. Fine-tuning before you have an evaluation set means you cannot tell whether it helped.

What OpenAI’s fine-tuning wind-down changes

It removes the easiest self-serve path to a tuned GPT model, and it makes “prompt, retrieve, evaluate, tune last” the default for anyone starting now. OpenAI’s pricing page, checked October 18, 2026, says the company “is winding down the fine-tuning platform.” The platform is no longer open to new users. Existing users can create training jobs for the coming months, and fine-tuned models stay available for inference until their base models are deprecated.

Three practical consequences for an architecture decision:

• A plan that depends on fine-tuning a GPT model needs an account that already has fine-tuning access, and an exit date for that model.
• A tuned model now carries a retirement risk tied to its base model. Keep the training data and the evaluation set, because they are what let you rebuild the behavior on another model.
• Teams that need tuning will do it with another provider or an open-weight model they host. That adds hosting and evaluation work, which is one more reason to prove that prompting and retrieval fall short first.

Watch out

A tuned model now has an exit date

Fine-tuned GPT models stay available only until their base models are deprecated. Keep the training data and the evaluation set, or there is nothing to rebuild the behavior from.

None of this changes the research above. Retrieval was already the better way to add knowledge; the wind-down only raises the cost of reaching for tuning early.

A decision table for enterprise LLM architecture

Can you combine RAG and fine-tuning?

Yes. Retrieval supplies the facts at request time, and a tuned or carefully prompted model supplies the format and behavior. The two solve different problems, so they stack rather than compete.

“Retrieval for facts, instructions for behavior, and tuning only where evaluations show a gap.”

A typical enterprise assistant retrieves the relevant passages, sends them in a context window large enough to keep surrounding detail, and relies on careful instructions, or occasionally a tuned model, for format and tone. The architecture question is about which part of the problem each method should own.

Research has gone a step further and tuned models to use retrieval better. RAFT, from Zhang and colleagues (2024), trains a model on questions paired with retrieved documents, some of them deliberately irrelevant, and teaches it to ignore the documents that do not help and to quote the passage that does. The authors report that it consistently improved performance on PubMed, HotpotQA and Gorilla datasets in domain-specific RAG. The lesson for a buyer: if a tuned model is part of the design, tune it on retrieval-shaped examples from your own documents, not on the documents alone.

What each approach costs to run at 10,000 queries a month

At 10,000 queries a month, RAG costs about $80 to $160 in model tokens, long context over a 150,000-token reference set costs about $340 to $550 with caching and about $3,000 without, and a fine-tuned small model with retrieval costs about $61. The table shows the arithmetic, using list prices checked on October 18, 2026.

Assumptions: each RAG query sends 6,000 input tokens of question, instructions and retrieved passages and returns 400 output tokens, the same figures as our RAG development cost model. Each long-context query sends the full 150,000-token reference set plus a 100-token question and returns 400 tokens. Traffic has gaps, so we assume the five-minute cache expires and is rewritten 1,000 times a month. Anthropic bills a five-minute cache write at 1.25 times the input price and a cache hit at 0.1 times, except on Claude Sonnet 5.5 and Opus 5.5, where a hit costs 0.05 times.

Two things the table hides. RAG and the tuned model also need a vector store and the engineering to build retrieval, while long context needs almost none; that build cost is what the per-query saving pays back. And a fine-tuned model still needs retrieval for facts, which is why it appears with RAG rather than alone. For how these run costs sit next to the build price of a whole agent, see AI agent development cost.

Latency follows the same pattern. Retrieval adds a search step, usually small next to generation. Prompts of hundreds of thousands of tokens slow the first token. A smaller tuned model is often the fastest option of all, which is why fine-tuning matters most in latency-sensitive products such as voice agents.

Retrieval quality decides how accurate a RAG system is

When a RAG system gives a wrong answer, the cause is usually that it retrieved the wrong passage, not that the model reasoned badly. Retrieval is worth engineering properly. Anthropic reported that adding context to each chunk before indexing, combined with keyword search, reduced top-20 retrieval failures by 49% in its tests, and by 67% with a reranking step. The exact numbers will differ on your data, but the lesson holds: chunking, hybrid search and reranking move accuracy more than swapping the model.

Build evaluations first

Whichever you choose, build evaluations first. A set of real questions with expected answers is what lets you swap models safely when a better or cheaper one ships.

It is the cheapest part of the project and the one that makes every later decision measurable.

If you are choosing an architecture for private data, our enterprise LLM and RAG development work starts with exactly this: your documents, your access rules and an evaluation set, before any model is chosen, and RAG development cost explains what drives the price. For why so many AI projects stall after the demo, read why AI pilots stall before production.

Originally published at apptycoons.com.

In conversation, people leave about 200 ms between turns. When an agent takes two seconds to respond, callers start talking over it — or hang up.

That pause is the first thing a caller judges, before they notice the voice or what the agent says, and most of it can be engineered away.

How fast should a voice agent respond?

A voice agent should start speaking within about one second of the caller finishing, and faster is noticeably better. That target comes from how people talk to each other, not from what the technology finds easy.

Conversation research is consistent here. Levinson and Torreira summarize it as gaps between turns “of the order of 200 ms”, while the time a person needs to plan even a short utterance is over 600 ms. People manage this by predicting how the other speaker will finish and preparing a reply while they are still listening. A comparison of ten languages by Stivers and colleagues found the same pattern everywhere: speakers avoid overlap and minimize silence, and the average gap varies by language only within about 250 ms of the cross-language mean.

The phone network has its own guideline. ITU-T G.114 sets a target of 150 ms one-way delay for most voice uses, before any AI is involved. Together, these numbers explain why a two-second silence feels broken: it is roughly ten times longer than the gap a caller expects.

Where the time goes

Each item hides a further delay. Before transcription can finish, the system has to decide that the caller has stopped talking. The model’s first token arrives quickly, but a long system prompt, a large model or a tool call can push the first useful sentence much later. Speech synthesis needs a full phrase to sound natural. And on a phone call, audio travels from the carrier to your telephony provider, then to each AI service and back, so a service hosted far from the others adds a round trip on every turn.

Mid-call lookups belong in the same budget: when a dealership booking agent loads a vehicle’s service menu or checks open slots during an Xtime API integration, each request is a tool call inside the caller’s turn, and the caller waits through it.

A latency budget, stage by stage

A one-second target only works if each stage has its own share of it, written down before the build. The table splits a turn into stages, with the published figure for each where one exists, checked October 18, 2026, and how to measure the rest.

The table shows why the fixed parts matter. With the network at the G.114 limit in both directions and a 500 ms silence threshold, those two items alone take 800 ms (150 + 150 + 500), before transcription, the model or speech start. That is illustrative arithmetic, not a measurement, but it is why end-of-turn tuning and same-region hosting do more for latency than swapping models.

Why vendor latency numbers don’t add up

Vendor latency figures usually measure one model in isolation, while the caller hears the whole chain. ElevenLabs is explicit about this: its models page lists Flash v2.5 at about 75 ms and marks the figure as excluding application and network latency.

That is a fair way to describe a model, and it is the right comparison between models. It is not what a caller experiences. Add up model-only figures for speech-to-text, the language model and text-to-speech, and the sum still leaves out end-of-turn detection, the phone network, the hops between services and any tool call. Those are the stages that set the pause a caller hears.

When a vendor quotes a latency number, ask three questions: which stages it covers, whether it is a median or a 95th percentile, and whether it was measured on a phone call or in a browser.

End-of-turn detection is the hidden delay

The most overlooked delay is deciding when the caller has finished. A simple voice activity detector waits for a fixed stretch of silence before it ends the turn. OpenAI’s documentation for its realtime API describes the trade-off directly: with a shorter silence duration, turns are detected more quickly. Set it too short, and the agent interrupts people who pause mid-sentence; set it too long, and every reply starts late.

Newer approaches look at meaning as well as silence. LiveKit’s agent framework, for example, uses a turn detector model that predicts the end of a turn from both what was said and how it sounded, on top of voice activity detection, and can adapt its delay to the caller’s own pauses. OpenAI offers a semantic mode with an adjustable eagerness setting. Neither removes the trade-off, but both let the agent answer quickly when a sentence is clearly complete and wait when it is not.

What we measured: turn detection is most of the wait

We measured this ourselves in October 2026. A scripted caller (six turns booking a dental appointment) talked to OpenAI’s realtime API over a server WebSocket from a US cloud machine: 30 turns per model and setting, audio streamed at real-time pace, timed from the end of each caller clip to the first audio of the reply.

| Model and turn detection | Median wait | 90th percentile | Model, after the turn ended | |---|---|---|---| | gpt-realtime-2.1, semantic (default) | 4.5 s | 4.9 s | 0.71 s | | gpt-realtime-2.1, semantic, eagerness high | 2.6 s | 3.2 s | 0.72 s | | gpt-realtime-2.1, 500 ms silence | 1.0 s | 1.3 s | 0.65 s | | gpt-realtime-2.1-mini, semantic (default) | 4.5 s | 4.8 s | 0.58 s | | gpt-realtime-2.1-mini, 500 ms silence | 0.9 s | 1.1 s | 0.58 s |

Our caller clips ended about 0.35 s after the last spoken word, so add that much to get the wait from the caller’s last word. The model itself answered in about 0.6 to 0.7 s in every setting. The difference is the turn detector: in its default mode it waited around 4 seconds before deciding our caller had finished, while a plain 500 ms silence rule cut the whole wait to about one second. The trade-off from the previous section still applies, so test the faster setting with callers who pause mid-sentence.

At list prices the two models cost about $0.078 and $0.023 per minute of talk in these runs, before telephony and hosting; our AI voice agent pricing tracker compares that with Vapi, Retell and other platforms. You can hear the 500 ms setup, and see your own reply times, in our live voice agent demo.

How to cut latency without making the agent worse

We stream every stage, start speaking before the full response is generated, and run tool calls in parallel with filler acknowledgements — so the agent feels present even while it works.

That comes down to six choices:

• Stream transcription, generation and speech, so each stage starts on partial output instead of waiting for the previous one to finish.
• Send the first sentence to speech synthesis as soon as it is complete, and keep generating the rest while it plays.
• Keep the speech, model and telephony services in the same region, and keep connections warm between calls.
• Keep the system prompt short and move rarely needed instructions into tools, so the model reads less on every turn.
• Use a smaller, faster model for routing and simple turns, and a larger one only where reasoning is needed.
• Cache data that does not change during a call, such as opening hours or the caller’s account, after the first lookup.

None of these require a worse answer. The goal is to remove waiting, not thinking.

Interruptions matter as much as speed

A fast agent that cannot be interrupted still feels robotic. When a caller starts talking, the agent should stop speaking almost at once, keep what it heard, and respond to the interruption rather than finishing its script. Frameworks such as LiveKit pause agent speech when they detect the caller and can tell a real interruption from a backchannel like “uh-huh”, so the agent does not stop every time someone agrees with it.

Test this on purpose. Interrupt the agent mid-sentence, talk over it in a noisy room, and pause halfway through a long account number. These are the moments callers remember.

Latency targets by call type

Not every call needs the same speed, and the right target depends on what the caller is trying to do. A booking or FAQ call is made of short, scripted turns where speed is most of the experience. A discovery or sales call has longer answers where quality matters more than shaving a few hundred milliseconds.

• Booking, FAQs and routing. Short questions and short answers. Aim for the fastest turns you can measure, a small fast model for most turns, and cached data such as opening hours.
• Account lookups and changes. The tool call dominates. Acknowledge at once (“Let me check that”), run the lookup in parallel, and set a budget per tool.
• Discovery, sales and support with judgment. Longer reasoning is acceptable if the agent signals it is thinking. Keep the first sentence fast and let the rest follow.
• Regulated calls, such as healthcare scheduling. A disclosure or confirmation step adds a turn by design; budget for it instead of cutting it. Our healthcare software development page covers the privacy side of those calls.

Whatever the type, measure the same way and report the median and the 95th percentile separately for each call flow.

Platform or custom pipeline: who controls the latency?

Hosted voice platforms such as Vapi and Retell assemble the pipeline for you: telephony, transcription, model and voice behind one API. That is the fastest way to a working agent, and for many call flows their latency is good enough. The trade-off is control. You choose from the vendors and regions the platform supports, and when a turn is slow, you can see less of why.

A custom pipeline, built on frameworks such as LiveKit or Pipecat, puts every stage under your control: where each service runs, which models handle which turns, how end-of-turn detection is tuned, and how tool calls are scheduled. It takes more engineering and more operational work. It is worth it when calls involve heavy lookups in your own systems, when data must stay in a specific region, or when volume makes per-minute platform fees a large line item. Same-region hosting does double duty there: it cuts a network hop on every turn and it is also how an agent keeps EU callers’ data in an EU region when a client asks for it; the transfer rules are explained in EU AI Act and GDPR rules for AI agents. The per-minute side of the decision is worked through in AI voice agent cost. Whichever route you take, measure it the same way.

How to measure voice agent latency

Measure what the caller hears, not what a dashboard reports. The number that matters is the time from the end of the caller’s speech to the first audio of the reply, recorded on a real phone call.

• Place test calls over the phone network, not only in a browser demo, because the carrier and telephony hops add delay a demo never sees.
• Record both sides of the call and mark the end of caller speech and the start of agent audio.
• Report the median and the 95th percentile across many turns; a good median with a slow tail still produces awkward calls.
• Log each stage separately, so a slow turn points to transcription, the model, a tool or speech synthesis.
• Repeat the test with background noise, accents and the longest tool calls in your flow.

Run this test on your own call flows before launch, because a latency figure measured on a different script, network or vendor mix says little about your calls.

“Latency isn’t a technical metric. It’s the difference between a conversation and a phone tree.”

What to do next

If you are planning a voice agent, set a latency target alongside your business goals, and ask any vendor or platform how they measured theirs. Our AI voice agent development work starts with your call flows, integrations and a latency budget for each one. To put a value on every answered call, read what missed calls really cost or put your own call volume into the AI voice agent ROI calculator.

Originally published at apptycoons.com.

Since August 31, 2026, every new Android app and every update submitted to Google Play must target Android 16. That rule lands on native and cross-platform apps alike, once a year, and it is a better place to start this decision than benchmark charts.

For most new products, cross-platform frameworks now deliver near-native quality with one codebase and one team. Native still wins when the app’s core feature lives close to the hardware. The decision is less about technology than about what your app has to do well, and this guide gives the table we use with clients, what each path changes in the quote and the apps we shipped each way.

Native vs cross-platform at a glance

Cross-platform means one codebase for iOS and Android; native means a Swift app and a Kotlin app; Kotlin Multiplatform shares logic and optionally the UI. A web app skips the stores entirely. Versions below were checked on October 18, 2026: React Native’s latest stable release is 0.87, and Flutter’s docs reflect Flutter 3.47.

The “best fit” column is our judgment from builds, not a ranking of frameworks.

Choose cross-platform when

Cross-platform is the right default when speed to both stores matters most, the app is mainly forms, content, lists and payments, and one team will maintain it.

Most business apps fit this description: booking, banking, marketplaces, member portals and internal tools. One codebase means one set of features, one release cycle and one team to hire. Native modules are still available when a single feature needs them, so choosing cross-platform does not close the door on platform APIs.

Choose native when

Native is the safer choice when the product depends on deep hardware access, when performance is the product, or when platform-specific design is a competitive edge.

Hardware is the clearest case. For OHM Fitness we built native iOS and Android apps that drive the 20 electrodes of an EMS suit over Bluetooth Low Energy, zone by zone, while the user trains. When a dropped connection can stop a workout, the Bluetooth code cannot behave slightly differently on one platform. We cover what that involves in building apps that control hardware, and the device-to-cloud side in BLE companion app development.

Other signals point the same way: camera pipelines that process frames live, background audio, widgets, watch apps and CarPlay, where each platform’s newest APIs arrive in Swift and Kotlin first.

React Native vs Flutter

Both frameworks are production-ready in 2026, and both have removed their old performance complaints. React Native has run its New Architecture by default since version 0.76, a rewrite of its internals the team worked on for six years. Flutter’s Impeller renderer precompiles shaders when the engine is built, which removes the runtime shader-compilation jank older Flutter apps were known for; it is the only renderer on iOS and the default on modern Android devices.

The practical differences are about people and design:

• React Native uses React and TypeScript, so web teams can contribute and share business logic with a web app, and it renders real platform components.
• Flutter draws its own interface, so a highly custom design looks identical on every device, at the cost of working in Dart.
• Both have mature libraries for payments, maps, notifications and analytics.

If your team already writes React, React Native is usually the shorter path. If the product is design-led and you are hiring from scratch, Flutter is a strong option.

Kotlin Multiplatform: the third option

Kotlin Multiplatform shares business logic, such as networking, data models and validation, in Kotlin across Android and iOS, while each platform can keep its own native UI. Compose Multiplatform adds a shared UI layer on top, and JetBrains declared it stable and production-ready for iOS in version 1.8.0, in May 2025.

It suits a team that already has a strong Android app in Kotlin and wants iOS without a second codebase for the logic. It suits a web-first team less well, because nothing is shared with a React frontend. Treat it as a way to share the parts of an app that should never differ between platforms, such as pricing rules or a sync engine, rather than as a replacement for React Native or Flutter on every project.

Is cross-platform cheaper? What changes in the quote

Cross-platform is usually cheaper for screen-heavy apps, but rarely half the cost of two native apps.

Note

Rarely half the cost

One codebase saves on screens, business logic and API work. Testing, store submission, device quirks and native modules are still done per platform.

When we quote a mobile build, these are the drivers that move the price, whichever path you pick:

• Platform count. iOS and Android, plus a web app if users need one. Each platform adds testing and release work even with a shared codebase.
• Native surface. Every feature that needs native code, such as Bluetooth, background tasks or a camera pipeline, is built and tested twice.
• Design fidelity. A design that follows each platform’s conventions is cheaper than a custom one that must look identical everywhere.
• Device testing. The range of phones and OS versions your users own, and how much of the app depends on them.
• Integrations. Payments, banking partners, streaming or device firmware usually cost more than the screens.

On our pricing, a mobile app is a Fixed-Price Build inside the $25k–$120k band, delivered in 6–16 weeks. A cross-platform app with standard integrations tends to sit lower in that band than a native app with a hardware layer. That is a pattern from our builds, not a quote; the number comes after discovery. For a worked example of how integrations drive a mobile budget, see fintech app development cost.

When a web app or PWA is enough

Skip the app stores when users arrive from a link, use the product occasionally and need nothing a browser cannot do. Internal tools, B2B portals, admin back offices and one-off payment or sign-up flows are usually better as web apps: no store review, one deploy, and no update the user has to install.

Switch shows where the line falls. Its shared accounts and cards live in iOS and Android apps, but MoneyPools, its payment-collection links, open in any browser without an install, because the person paying is often not a Switch user and should not have to install an app to pay.

A store app earns its cost when users come back weekly, need push notifications or background work, or touch hardware. Bluetooth is the clearest example on iPhone: WebKit, the engine behind every iOS browser, has declined to ship Web Bluetooth, so a device companion for iPhone users has to be an app.

Maintenance: the cost after launch

Every mobile app needs work each year even if no feature changes. Apple and Google ship a major OS release every year, store policies change, and SDKs deprecate old APIs.

A cross-platform app has one upgrade path for the shared code, but its framework version becomes one more dependency to keep current, and every native module is upgraded on both platforms. A native app has two upgrade paths and no framework layer in between. Neither is free. Budget for an upgrade cycle every year, and treat a framework that is three major versions behind as technical debt, not a stable choice.

Watch out

Google Play’s yearly deadline

Google Play enforces the yearly cycle directly. From August 31, 2026, new apps and updates must target Android 16 (API level 36). Existing apps must target at least Android 15 to stay available to new users on newer devices.

Subscription apps add one more recurring cost: the store fee on every renewal. How those fees interact with creator or partner payouts is covered in our guide to store fees on subscriptions and creator revenue share.

Real apps and the path we chose

Each of these was a product decision first and a framework decision second:

• OHM Fitness: native iOS and Android. Live control of a wearable suit is the product, so the Bluetooth layer was written in each platform’s own language.
• Switch: React Native for iOS and Android, plus web. Shared banking for clubs and teams, with cards, roles and permissions in one React Native codebase for both apps, and MoneyPools on the web for people who will never download them.
• DubCam: iOS and Android apps plus web. Programs go live from a phone and fans watch and subscribe, so the platforms follow where fans already are.

Our mobile app development team builds both ways, and the choice is made per product in discovery.

How we make the call

We make this call in discovery, with a prototype of the riskiest screen on real devices before the build starts. Five questions decide most cases:

1. Does the core feature touch hardware, such as Bluetooth, a camera pipeline or background execution? If yes, lean native, or plan native modules from day one.
2. Is audio or video real-time? Live media pushes toward native or a cross-platform app with a native media layer.
3. What does the team already write? React and TypeScript point to React Native, Kotlin to Kotlin Multiplatform, a fresh hire to Flutter or React Native.
4. Is a web version needed? Sharing logic with a React web app is a strong argument for React Native.
5. Which screen is riskiest? Prototype that one. If it holds up on real devices, cross-platform is safe; if it doesn’t, you learned that in two weeks rather than after launch.

Originally published at apptycoons.com.