DEV Community: Vrunda Chauhan

Why Do You Still Need a Builder When You Have All the Tools?

Vrunda Chauhan — Thu, 22 Oct 2026 10:02:36 +0000

A lot of growing companies spend $50,000 or more every year on enterprise integration tools like MuleSoft, Boomi, or Workato. The goal is straightforward: you want your sales software, your warehouse database, and your billing system to talk to each other so your team does not have to spend all day copying and pasting data.

On paper, these platforms make it sound like everything connects in a few clicks. But buying the software is not the same thing as making your systems work together in real life.

We saw a company run into this problem with a $500,000 deal. Their sales team checked their CRM, saw that 500 units were listed as available, and closed the contract with a major client. But because the integration between the sales software and the warehouse only updated once every night at midnight, nobody realized those units had already been sold online two days earlier. When the shipping team went to pack the boxes, the shelves were empty. The company missed the delivery deadline, and the client cancelled the order and went to a competitor.

The software was running and the servers were up, but the setup was flawed.

This happens all the time because integration platforms give you the tools to connect your apps, but they do not know how your business actually runs. That is where an integration development partner comes in.

Here are the practical reasons why having the platform is only half the job.

1. Ready-made connectors rarely fit real businesses

Most integration tools come with pre-built connectors. They show you a simple menu where you can click one button to link Salesforce to an accounting tool or an inventory system.

This works great in a quick sales demo, but real businesses have unique requirements. You probably have custom discount rules, wholesale pricing tiers, special shipping rules, or an internal database built years ago that has no standard connector at all.

When a ready-made connector runs into data it does not understand, it usually does not stop to fix it. Instead, it quietly skips that field or throws an error in a log file that nobody reads. An integration partner builds custom connections and rules to make sure all of your specific business details move across systems without getting dropped.

2. Different apps speak different languages

Even when two systems are connected, they almost never organize information the same way.

Your sales software might list a product as "Blue Shirt, Size L" with a price of "$25.00". Your accounting system might track that same shirt as item number "1042" with the price recorded in pennies as "2500". Meanwhile, your warehouse database might track it by barcode and weigh it in kilograms.

If you plug these apps together without a translator, they get confused. The accounting system might try to charge twenty-five hundred dollars instead of twenty-five, or the warehouse system might reject the order completely because it expected numbers instead of letters.

An integration partner builds data maps between these systems. They make sure prices, product codes, taxes, and customer addresses are translated into the exact format each computer expects before anything gets saved.

3. Real-time checks stop you from selling what you do not have

A lot of default integrations run on a timer. They collect changes throughout the day and push them over in one big batch late at night.

That setup might be fine for monthly financial reports, but it is dangerous for inventory and sales. If a customer buys your last 30 items at noon, and your website does not find out until midnight, other customers can keep buying those same 30 items all afternoon.

An integration partner sets up real-time checks using APIs and webhooks. When a sales rep or an online customer clicks to place an order, the system instantly asks the warehouse database if the items are physically in stock. If they are, it locks them for that order within a fraction of a second. That way, nobody promises products that are already gone.

4. Handling glitches without losing orders

Every internet service has bad moments. Servers restart, connections drop, and cloud tools hit temporary limits during busy hours.

The real test of an integration is what happens when something fails. If your billing software goes down for five minutes during a flash sale, what happens to the orders placed during that time?

In a basic setup, those orders might simply vanish. The customer thinks they purchased the item, but the warehouse never receives the ticket. In a properly built setup, the integration uses message queues and automatic retry logic. If the destination system does not respond, the order waits safely in line. The system tries again in thirty seconds, then two minutes, and then five minutes.

When we build system integrations and AI automation workflows at EnactOn, setting up safe failure handling is where most of the effort goes. We also configure instant alerts so our engineers get notified right away if an issue persists, allowing us to fix it before customers ever notice. Following standard DevOps best practices ensures these data pipelines stay reliable even under heavy traffic.

5. Preventing accidental double orders

Imagine a customer placing an order on their phone with a spotty mobile connection. They tap "Submit Order", but the screen takes several seconds to load. Thinking nothing happened, they tap the button three more times.

Without proper safeguards, the integration platform will process all four requests. That means the customer gets charged four times and receives four identical packages in the mail.

Engineers prevent this using a method called idempotency. In simple terms, it means giving each order a unique digital tag. If the server sees that same tag arrive again within a short window, it recognizes that it is a duplicate from an accidental click and safely ignores it.

The integration platform gives you the ability to filter requests, but a developer has to write the specific logic to catch those duplicates and protect your customers.

The Tool vs. The Builder

Buying an integration platform is like buying a high-end set of power tools. It gives you the equipment you need to build something great, but the tools cannot measure the room, cut the wood, or assemble the furniture on their own.

If your team is already paying for a platform like MuleSoft, Boomi, or Workato, ask yourselves these four simple questions:

If our inventory system goes offline for twenty minutes right now, do incoming orders wait safely in a queue, or do they disappear?
If an API request sends twice because of a network glitch, does our system catch the duplicate before charging the customer twice?
Does our inventory update across all channels the moment a sale happens, or are we still relying on scheduled updates?
When a sync fails in the background, does an engineer get alerted right away, or do you only find out when an unhappy customer calls?

If you are not sure about the answers, the platform is not the problem. You just need an experienced development partner to build the guardrails and make those tools work for your business.

Have you ever had an integration quietly fail in production? What broke, and how long did it take your team to catch it? Let's talk about it in the comments below.

Stop Gluing 7 APIs Together: The 5 Tools You Actually Need for Voice AI

Vrunda Chauhan — Wed, 21 Oct 2026 11:18:17 +0000

When developers try to build their first voice AI agent, they usually make one big mistake.

They connect too many tools.

They grab one tool to turn speech into text, another tool for the AI brain, a third tool to generate the voice, a fourth tool for the calendar, and a fifth tool for their customer database. Then they tape it all together with complex webhooks.

On paper, it sounds like an amazing setup.

Then you test it on a real phone call. You say "Hello," and the line goes completely quiet for three seconds. Just as you start to speak again, the bot finally cuts in and talks over you.

In a normal conversation, people only pause for about half a second before speaking. If a computer takes two or three seconds to answer, the caller thinks the call dropped or the system is broken.

Building voice agents on our engineering team at EnactOn taught us a simple lesson: great voice agents do not need a dozen different tools. They need a small, clean setup that answers quickly without awkward pauses.

Here is how voice AI actually works, the two ways to build it, and the only five tools you need to get started.

The Two Ways to Build a Voice Agent

Before you connect any extra tools, you must decide how your bot will listen and speak. There are two main ways to do this today:

1. The 3-Step Chain:
Caller Speaks -> [Speech-to-Text] -> Text -> [AI Brain] -> Text -> [Voice Maker] -> Bot Speaks

2. Direct Voice AI:
Caller Speaks -> [Live Voice AI Model] -> Bot Speaks

Method 1: The 3-Step Chain (Listen, Think, Speak)

This is the traditional setup most developers start with. You connect three separate tools together:

The Ears (Speech-to-Text): Listens to the caller's voice and types it out as text (using tools like Deepgram or Whisper).
The Brain (The AI Model): Reads the text and decides what to say back (using models like GPT-4o mini or Claude Haiku).
The Voice (Text-to-Speech): Takes the AI's written reply and reads it out loud (using tools like Cartesia or ElevenLabs).

This setup gives you total control. You can check the text, filter bad words, and pick any voice you like.

The downside is delay. If the ears take 200 milliseconds, the brain takes 400 milliseconds, and the voice takes 250 milliseconds, the caller is already waiting nearly a second. Add in slow phone networks, and the call starts to feel laggy.

Method 2: Direct Voice AI (Listen and Speak Directly)

Newer models, like the OpenAI Realtime API or Gemini Live, do not convert sound into text and back again.

Instead, the AI listens to the audio directly and speaks right back, just like a person on the phone.

This cuts the delay in half. The bot can answer in less than half a second. It sounds more natural, and it stops talking the moment the caller interrupts it.

The trade-off? Direct voice models cost more to run. When looking at the real cost to build an AI agent, paying for live audio minutes can add up quickly if your bot handles thousands of calls.

Once you pick your voice engine, you only need five types of tools to make it useful.

1. The Voice Platform (The Engine)

Writing your own code to manage live audio and detect when a person stops talking is very hard. Voice platforms handle this difficult work for you.

Popular Tools

LiveKit: Great if you are a programmer who wants full control and wants to write your own agent code in Python or Node.js.
Vapi and Retell AI: Great if you want a ready-made platform that connects phone numbers, AI brains, and voices in a simple dashboard.
OpenAI Realtime & Gemini Live: Foundation-level engines that stream audio directly back and forth.

Simple Tip

Make sure your bot is not too quick to interrupt. If the bot jumps in every time the caller clears their throat or takes a breath, the call feels stressful. Give the caller about half a second of silence before the bot starts talking.

2. The Phone Line (Telephony)

An AI bot running inside your web browser is fun for testing, but a real business needs it to answer normal phone calls.

Popular Tools

Twilio: The most popular phone service on the internet. It gives your bot real phone numbers and streams live audio directly to your server.
Telnyx: A developer-friendly phone service that offers fast connections and low rates for busy phone systems.

Simple Tip

Do not send phone audio through slow website links. Phone calls need a direct, live stream so words flow back and forth smoothly without cutting out.

3. Customer Memory (CRM)

If your bot cannot remember who is calling, it cannot be very helpful. Connecting your bot to a customer database gives it a memory.

Popular Tools

HubSpot and Salesforce: Well-known systems where businesses store customer names, emails, and past purchases.
GoHighLevel: A popular system used by local businesses and clinics to track new leads and messages.

Simple Tip

Never make the caller wait while the bot searches a big database.

If the bot pauses to look up a customer in the middle of a sentence, the caller will hear awkward silence. Instead, look up the person's phone number before answering the call. That way, the bot can say "Hi Alex, thanks for calling back!" on ring one.

4. The Calendar (Scheduling)

One of the most useful jobs for a voice bot is booking appointments. But you should never let an AI guess what times are open.

Popular Tools

Cal.com: A developer-friendly tool for checking open calendar times.
Calendly: A widely used booking app that connects directly to Google and Outlook calendars.
Google Calendar API: A direct way to check open spots with simple code.

Simple Tip

Let the AI speak in friendly, everyday language, but let the calendar tool check the actual open dates. That way, your bot will never double-book an appointment by mistake.

5. The Helper Robot (Automation)

When a call ends, there are always chores to finish. You might need to send a confirmation text message, update customer notes, or notify your team.

Call Ends
    │
    ├──> Write Short Summary
    │
    └──> Trigger Background Chores
            ├──> Send Text Confirmation to Caller
            ├──> Update Status in CRM
            └──> Send Alert to Team in Slack

Popular Tools

n8n: A powerful automation tool. Running self-hosted n8n workflow automation lets you handle tasks on your own servers without paying extra fees for every single run.
Make.com: A friendly visual tool that connects different apps using drag-and-drop steps.
Simple Webhooks: Small cloud functions that send data directly from one app to another.

Simple Tip

Run these chores after the phone call hangs up. Using event-driven ai automation workflows in the background keeps your phone line clear and super fast.

Three Simple Rules for a Better Voice Bot

Picking your five tools gets your bot working. Following these three simple rules keeps it helpful and polite:

1. Fill Awkward Silences

If your bot has to check a slow system, make it say something like "Give me just a second while I check that for you." This lets the caller know the call did not drop.

2. Always Offer a Way to Reach a Human

An AI bot should never trap an unhappy customer. If the caller gets frustrated or asks to speak with a person, transfer the call to a real human right away.

3. Keep Private Information Safe

Phone calls often involve names, addresses, and phone numbers. Always protect customer data and never store secret passwords in open files.

Summary: Keep Your Stack Simple

A great voice AI agent is not the one with twenty different tools glued together.

It is the one that answers fast, listens carefully, and gets the job done without keeping the caller waiting.

Start with a small setup, test your speed on a real phone call, and only add new tools when you really need them.

What tools are you using for your voice bot right now? Drop a comment below and share your stack!

Why Calling a Patient at 9:30 PM Can Cost You a $1,500 Fine

Vrunda Chauhan — Tue, 20 Oct 2026 05:42:11 +0000

According to Netwrix's 2026 research, 33% of healthcare companies that experienced a security incident lost more than $250,000. In other industries, only 21% of companies faced costs that high.

Why does a security problem cost so much more in healthcare?

Because healthcare companies handle personal medical data. When patient information is mishandled, clinics face strict privacy laws, mandatory investigation costs, and heavy federal fines.

At the same time, Voice AI has become one of the most effective tools for modern clinics.

In our engineering work at EnactOn with telehealth clinics, we have seen automated voice agents recover about 10% of lost consultations. These agents automatically call back patients who started an intake form but left the checkout page before paying.

Let's say a clinic has 1,000 abandoned visits every month. Recovering 10% means bringing back 100 paying patients. That adds $15,000 in monthly revenue for around $350 in phone bills. Patients get immediate, friendly help, and clinic staff don't have to spend hours making manual phone calls.

Because Voice AI works so well, many teams are rushing to build their own. But building a voice agent for healthcare is not like building a regular web app. A small bug in a normal app might just show an error on a screen. A bug in a healthcare voice agent can leak private medical details, trigger unwanted phone calls, or get your clinic's number blocked by phone companies.

If you want to build a voice AI agent for a clinic or telehealth service, here is a practical, step-by-step guide to making it work reliably and safely.

1. The 4 building blocks you need to make a Voice AI agent

Every voice AI agent is built by connecting four core tools together in real time:

The Ears (Speech-to-Text): When the patient speaks into their phone, this tool converts their voice into written text in under 200 milliseconds. Tools like Deepgram Nova-2 are commonly used because they are fast and accurate with medical terms.
The Brain (The AI Model): An AI language model (like GPT-4o mini or Claude 3.5 Haiku) reads the patient's text, looks at the conversation rules, and decides what to say next.
The Voice (Text-to-Speech): This tool turns the AI's written reply back into a natural, friendly human voice. Tools like Cartesia or ElevenLabs stream audio back to the caller with very low delay, so the conversation feels smooth and natural.
The Phone Line (Telephony): A service like Twilio or LiveKit connects the AI pipeline directly to real telephone networks.

When you put these four blocks together, you have a working voice agent. But how you configure those blocks determines whether your agent is a huge success or a legal disaster.

2. How to write the agent's instructions (The System Prompt)

The "system prompt" is the set of rules you give the AI model before it answers any calls.

In healthcare, your prompt must have clear, hard boundaries. Here is an example of the core rules every healthcare voice agent needs:

You are a friendly patient support coordinator for City Telehealth.
Your only job is to help patients finish booking their consultation.

Follow these strict rules:
1. ALWAYS confirm the patient's name before discussing any appointment details.
2. If another person answers the phone, do not share any medical information. Politely ask them to check their email.
3. NEVER give medical advice, diagnose symptoms, or guess what treatment a patient needs.
4. If a patient mentions an emergency (like chest pain, severe bleeding, or trouble breathing), STOP immediately and transfer them to the nurse line.

Keeping the prompt focused on administrative help (scheduling and payment) prevents the AI from stepping into clinical territory where it doesn't belong.

3. Give your voice bot access to only the data it needs

To help a patient complete their booking, the voice agent only needs basic information: the patient's first name and phone number.

Here is where developers often make a serious mistake:

During testing, a developer might generate an API key with full access to the clinic's entire electronic health records (EHR) database. Suddenly, an AI bot that only needs one phone number has the master keys to 50,000 patient charts.

Netwrix's 2026 report found that 79% of healthcare organizations do not properly track their automated bots and API keys.

The fix: Scoped 30-minute access tokens.

Instead of giving your voice agent a permanent key to the whole database, your server creates a temporary token. That token:

Only unlocks that single patient's contact record.
Allows access only to the fields needed for the call.
Automatically expires after 30 minutes.

Think of it like giving someone a hotel keycard that only opens room 204 for one night, instead of handing them the master key to the entire building.

4. 5 engineering rules for safer healthcare Voice AI

When a voice agent makes real phone calls, its code needs to protect patients and prevent mistakes. Here are five practical rules to build into your backend code.

Rule 1: Stop duplicate calls with a simple code lock

The problem

A server can run several background workers at the same time. If two workers grab the same task, they might both place a call to the same patient at the exact same millisecond.

This is called a race condition. In normal web apps, a duplicate job might just create an extra row in a spreadsheet. In phone calls, it places a real call to a patient's personal device.

Under the United States Telephone Consumer Protection Act (TCPA, 47 U.S.C. § 227), unwanted automated calls carry fines of $500 to $1,500 per call.

A real-world example

When our engineering team audited a legacy callback system for an online telehealth provider, we found a dangerous failure mode.

A patient was filling out an intake form on his phone while riding a bus. His cellular connection was weak, and the checkout page took too long to load. He tapped the "Submit" button five times.

The server received five identical requests. Because the previous developers had built the dialer without a code lock, three worker processes picked up the task at the exact same moment. When the patient didn't answer, all three processes began automated retry loops. By late afternoon, that un-guarded system had dialed that single patient 104 times in one day.

Courts do not show leniency for dialing loops. In King v. Time Warner Cable, an automated system called one person 153 times, resulting in a $229,500 judgment. In healthcare, Walgreens agreed to an $11,000,000 settlement (Kolinek v. Walgreen Co.) after automated prescription calls were sent without proper consent.

How to fix it

Before making any call, check whether the system has already dialed that number today. You can use Redis, a fast in-memory data store, to create a 24-hour lock:

// Create a 24-hour lock for this phone number before calling
const lockKey = `dial_lock:${patientPhoneNumber}`;

// If the lock already exists, stop immediately!
const lockAcquired = await redis.set(lockKey, "called", "EX", 86400, "NX");

if (!lockAcquired) {
  console.log("SAFETY LOCK: Number was already dialed today. Discarding call.");
  return;
}

EX 86400 means the lock expires automatically after 24 hours.
NX means Redis creates the lock only if it doesn't already exist.

If another worker tries to call at the same millisecond, Redis blocks it instantly.

Rule 2: Check the patient's local time before calling

The problem

Patients live across different time zones. Your server might run in New York, while your patient lives in California. If your code checks only the server's clock, it could call a patient late at night.

Under federal telemarketing rules and state laws like Florida (Florida Statute § 501.059) and Oklahoma (Oklahoma Telemarketing Act), commercial follow-up calls are prohibited outside of 8:00 AM to 8:00 PM, with fines up to $1,500 per call.

A real-world example

Imagine a patient in California submits a form at 9:15 PM and closes her browser. The clinic's server is in New York, where it is 12:15 AM after midnight. A callback script set to dial after 15 minutes rings her phone at 9:30 PM local California time.

The loud ring wakes up her household. The customer complains, creating immediate legal liability for the clinic.

How to fix it

Never use your server's clock to decide when to call. Instead:

Check the patient's local time zone using their phone area code or billing address.
Restrict automated calls strictly to safe daytime hours (10:00 AM to 6:00 PM local time).
If an inquiry comes in after 6:00 PM in their time zone, automatically schedule the callback task for 10:15 AM the next morning.

Rule 3: Verify who is answering before discussing medical information

The problem

When your voice agent calls a phone number, anyone might answer: a spouse, roommate, parent, or coworker.

Under HIPAA privacy regulations (45 CFR § 164.502), health information is strictly confidential. If the agent blurts out medical details before confirming who is listening, an unauthorized disclosure occurs. HIPAA penalties range from $100 to $50,000 per violation, up to $2,000,000 annually.

A real-world example

A college student starts an online form for private anxiety therapy but leaves before paying. Twenty minutes later, the voice bot calls. The student is busy, so his roommate answers.

If the voice bot says: "Hello, I am calling about John's anxiety consultation," John's confidential medical information has been blabbed to his roommate.

How to fix it

Every healthcare voice bot should follow a Zero-Diagnosis Protocol:

Neutral Introduction: Start with general support phrasing: "Hello, this is patient support calling about a recent website inquiry. Am I speaking with John?"
Polite Exit If Someone Else Answers: "Thank you. Please let John know to check his email from patient support whenever convenient."
Confirm Identity First: Only discuss the booking after the patient confirms their identity.

Connecting this check to a secure patient portal development workflow lets patients review and finalize their intake forms privately on their own devices.

Rule 4: Keep follow-up calls separate from doctor appointment calls

The problem

Major phone carriers (like AT&T, Verizon, and T-Mobile) use smart algorithms to identify spam calls based on answer rates and user reports.

If a clinic uses the same phone number for both website follow-ups and real doctor appointments, the entire phone system can be ruined. Follow-up calls naturally have lower answer rates than pre-scheduled doctor appointments.

A real-world example

A clinic makes hundreds of automated calls from a single phone number. Over two weeks, phone company algorithms see the low answer rates and attach a red warning: "Scam Likely" or "Spam Risk".

When a real doctor calls a patient for their scheduled video consultation, the patient's phone flashes "Scam Likely." The patient ignores the call. Attendance rates collapse, and doctors sit waiting in empty video rooms.

How to fix it

Create a clear Two-Lane Road:

Lane 1: Follow-Up Numbers: Use a dedicated pool of phone numbers exclusively for website recovery calls.
Lane 2: Doctor Appointment Numbers: Keep a separate, protected pool of numbers reserved solely for verified doctor calls.
Register with Carriers: Register your clinical numbers with official trust programs (STIR/SHAKEN and A2P 10DLC) so your clinic's verified business name appears on caller ID screens.

Rule 5: Transfer medical emergencies to a real healthcare professional

The problem

Voice AI is great at handling operational tasks: booking slots, verifying insurance, and helping with payments. But an AI agent is not a doctor. It cannot diagnose illnesses or handle life-or-death situations.

If an AI tries to make small talk with a patient who is having a medical emergency, the clinic faces extreme legal liability and medical malpractice claims.

A real-world example

Imagine a patient on a callback says:

"I couldn't finish paying because my chest feels tight and my left arm is going numb."

A basic sales bot without emergency logic might reply:

"I'm sorry to hear that! The doctor has an open appointment next Tuesday at 2:00 PM. Would you like me to book that?"

Treating a possible heart attack like a routine scheduling question could cost that patient their life.

How to fix it

Build an automated Safety Handoff directly into your audio pipeline:

Emergency Word Detection: Continuously scan the patient's speech for acute symptoms ("chest pain", "trouble breathing", "severe allergic reaction").
Immediate Speech Pause: The moment an emergency word is detected, stop automated generation instantly.
Reassuring Emergency Message: Play a clear pre-recorded prompt: "It sounds like you may be experiencing a medical emergency. Please hang up and call 911 immediately. If you stay on the line, I will connect you to our on-call nurse line."
Live Nurse Warm Transfer: Transfer the phone call immediately to an on-call triage nurse and display a real-time transcript on the nurse's screen.

5. The business numbers: How Voice AI recovers 10% of lost consultations

When you build these five rules into your system, Voice AI becomes one of the most profitable, high-leverage assets a clinic can deploy.

Here is what the real math looks like for a telehealth clinic handling 1,000 abandoned checkout visits each month:

Metric	Email Follow-Up Only	Voice AI (with 5 Guardrails)
Abandoned Checkouts	1,000 visits	1,000 visits
Typical Recovery Rate	~1.5%	~10.0%
Patients Recovered	15 patients	100 patients
Average Consultation Fee	$150	$150
Monthly Revenue Recovered	$2,250	$15,000 / month
Monthly Phone & Compute Costs	~$30 (email tool)	~$350 / month (Retell / Twilio)
Net Revenue Gained	+$2,220 / month	+$14,650 / month

Note: These figures are benchmarks based on live production data, not a guarantee. Actual results depend on patient demographics and response speed.

This comparison shows why understanding the real cost of building an AI agent comes down to smart engineering guardrails, not just API costs.

Once a patient completes payment, they move smoothly into their telehealth appointment on a platform such as Doxy.me, where the physician reviews the intake record in the EHR before starting video care. A proper telemedicine app development workflow keeps phone calls, records, payments, and appointments connected smoothly.

Pre-launch checklist: 5 things to check before you go live

Before turning on any healthcare voice bot, make sure your engineering team checks off these five controls:

The Code Lock: Did you set a 24-hour Redis lock so the bot cannot dial the same patient twice in one day?
The Timezone Check: Does your system verify the patient's local time zone so it never calls outside 10:00 AM to 6:00 PM local time?
The Zero-Diagnosis Rule: Does the bot hide all medical words until the patient confirms their identity?
The Two-Lane Road: Are your sales recovery numbers separated from your doctor appointment lines and registered with A2P 10DLC?
The Safety Handoff: Does the bot immediately stop and transfer to 911 or a live nurse if emergency symptoms are detected?

Healthcare Voice AI is not just about making a bot sound human. It is about making sure the system knows what data it can access, when it can call, what it can say, and when to get a real person involved.

Build these rules in from the beginning, and you will have a safe, high-converting voice agent that patients and clinics can trust.

Let's discuss

Have you built a voice AI agent for healthcare or another regulated industry? How does your team handle patient privacy, calling hours, and caller ID verification?

Is Voice AI Worth It? The Real Cost, True ROI, and What’s Pure Hype

Vrunda Chauhan — Tue, 13 Oct 2026 12:13:30 +0000

Think about how frustrating it is to scale a cold calling team.

You hire five people. You spend three weeks training them on your script. Two of them quit after a month. The three who stay make 50 dials a day, hit voicemails all morning, and spend half their afternoon typing messy notes into your CRM.

Meanwhile, social media promises you a miracle: "Just build a voice AI bot for 5 cents a minute and fire your sales floor!"

Whenever founders or developers ask our team at EnactOn about this, they want honest answers to three basic questions:

Is voice AI truthful, or is it mostly marketing hype?
Why do businesses actually need it instead of hiring more callers?
What does the real return on investment (ROI) look like?

We have built and tested voice AI pipelines on live phone lines. We tracked the phone bills, the connection rates, and the technical disasters that happen when code meets real people.

Here is the simple,breakdown of how the math works, why businesses are building this, and what vendors lie to you about.

1. Is Voice AI Truthful or Just Hype?

The short answer: The technology is real, but the vendor marketing is mostly hype.

Companies selling voice AI love to make it sound like a cheap robot that can replace your best salesperson tomorrow.

In the real world, here is what is true and what is an exaggeration.

The "5-Cent" Lie

Vendors love to put "starts at $0.05 a minute" in bold letters on their pricing pages.

Sounds like pocket change. But an AI phone call is not one piece of software. It is a four-step relay race between four different companies:

Pipeline Step	Who Runs It	What It Does	Real Cost / Min
1. Phone Carrier	Twilio / Telnyx	Connects call to cell networks	~$0.02 / min
2. The Ears (STT)	Deepgram / Whisper	Converts spoken voice to text	~$0.01 / min
3. The Brain (LLM)	GPT-4o mini / Claude	Reads context and picks an answer	~$0.04 / min
4. The Voice (TTS)	Cartesia / ElevenLabs	Speaks the reply back out loud	~$0.06 / min
5. Orchestration	Retell / LiveKit	Keeps pauses under 800 milliseconds	~$0.05 / min
Total Real Cost			~$0.18 / min

When you add those pieces together, a real production call costs between 16 and 22 cents a minute, not 5 cents.

Is that still much cheaper than a human caller? Yes. A human sales rep costs roughly $4.00 to $6.00 for every completed phone conversation. An AI costs around $0.45 to $0.60 for that same call. That is a massive 85% discount, but it is not 5 cents.

What Breaks on Real Phone Calls

In social media demos, the speaker talks into a podcast microphone, pauses politely, and follows the script.

Real prospects on a phone line do not act like that:

If a prospect clears their throat or says "uh-huh", a poorly tuned AI cuts itself off and loses its place.
If your server takes 1.5 seconds to think, the prospect says, "Hello? Anyone there?" That second question interrupts the AI and restarts the whole sentence.
If someone calls from a loud street with traffic, speech-to-text turns their words into scrambled letters.

Voice AI cannot charm an angry customer, navigate delicate office politics, or close a six-figure contract. Anyone who promises you that is selling snake oil.

2. Why Businesses Actually Need Voice AI (The Real Problem)

If voice AI has these limits, why are companies building it instead of hiring more sales reps?

Because cold calling is a math funnel, not just an activity:

[10,000 Lead Database]
         │
         ▼
[Prospects Reached] ──── (Only ~5% to 13% pick up the phone)
         │
         ▼
[Qualified Leads]   ──── (Checking budget, need, and timeline)
         │
         ▼
[Booked Meetings]   ──── (Handed to Senior Sales Reps)

When you hire more human callers, you only add more hours. You do not make the process more consistent.

Here is why software beats adding more headcount at the top of the funnel:

1. The Productivity Gap

Gong analyzed over 300 million sales calls and found a shocking gap between average and top sales reps:

Average rep: Connects with only 5.4% of dials, and books a meeting on only 4.6% of conversations.
Top-performing rep: Connects with 13.3% of dials, and books a meeting on 16.7% of conversations.

Why is there such a massive gap? Because human reps say different things every day. They get tired, they skip qualification questions, and they forget to log notes.

With voice AI, once you test and find an opening line that works, you update the prompt. Instantly, 100% of your calls use the winning script.

2. The AI Executes the Whole Workflow

A normal automated dialer just rings numbers. A voice AI agent is a connected software system that does three jobs at once:

Reads CRM data before dialing: It knows the prospect's company size, role, and industry before saying hello.
Handles routine qualification live: It asks if they have a budget, what tools they use, and when they want to start.
Takes action immediately: If the prospect is interested, the AI books a calendar slot, updates your CRM, and sends an SMS confirmation while still on the line.

Human reps spend up to 40% of their workday typing notes into spreadsheets. Voice AI does the data entry instantly.

3. The Unit Economics: Humans vs. Voice AI

To understand the real return on investment, let's compare what it costs to generate 50 qualified sales meetings using human callers versus a voice AI system.

Operating Factor	5 Human Callers	1 Voice AI System
Monthly Operating Cost	$12,500 ($2,500 per caller)	~$900 (telephony + minutes + software)
Daily Call Capacity	~250 total dials per day	1,000+ dials per day
CRM Data Entry	Done manually (often messy)	100% automated via webhooks
Script Consistency	Changes based on mood and fatigue	Follows approved logic on every call
Qualified Meetings Booked	~50 meetings	~60 - 80 meetings
Cost Per Qualified Meeting	$250 per meeting	~$15 per meeting

Even if the AI only books half as many meetings per conversation as a great salesperson, the cost per booked meeting drops from $250 to under $20.

This is why calculating the realistic cost to build an AI agent matters. You spend money upfront to build the system, but your cost to scale up calls drops to almost nothing.

4. The 4 Traps That Can Destroy Your ROI

Voice AI sounds simple on paper, but if you do not build safety rules, it can ruin your business reputation in days.

Trap 1: The Infinite Loop Bug (Calling Someone 100 Times)

When we first tested an automated callback system, a user with slow internet clicked the submit button several times.

Our code got confused. It thought 100 different people had signed up. Because our code was missing a safety lock, the system dialed that poor person over 100 times in a row!

To stop this nightmare, you must add an atomic lock in Redis before making any phone call:

 typescript
// Simple safety check before making any phone call
asyncfunctioncanWeDialLead(leadPhoneNumber:string):Promise<boolean>{
const lockKey=`dial_lock:${leadPhoneNumber}`;

// Rule 1: Has this number been called in the last 30 days?
const alreadyCalled=await redis.get(lockKey);
if(alreadyCalled){
returnfalse;// Skip! Never call again
}
// Rule 2: Lock this number for 30 days so duplicates can never happen
await redis.set(lockKey,"called","EX",60*60*24*30);
returntrue;
}

If you build an outbound phone bot, this safety lock is non-negotiable.

Trap 2: Legal Calling Hours (TCPA)

Federal law says marketing calls can only happen between 10:00 AM and 6:00 PM in the prospect's local time zone.

If a lead signs up at 9:30 PM, your system cannot call them right away. That is illegal. Your system must read their area code, calculate their local time, and hold the call until 10:15 AM the next morning.

Trap 3: Phone Companies Marking Calls as "Scam Likely"

Within two weeks of running outbound calls, people will stop answering your calls.

Why? Because cell carriers (like AT&T and T-Mobile) notice high calling volume from new numbers and slap a red "Scam Likely" warning on the screen.

You must register your company with phone carriers through official verification (STIR/SHAKEN and A2P 10DLC). That way, your real company name shows up on the screen instead of a warning.

Trap 4: Respecting Privacy Laws

If you operate in healthcare or finance, privacy laws are strict.

When an AI dials a phone, it does not know who picked up. It could be a spouse or a coworker. The AI must never state private details out loud until the person confirms their identity.

5. When Voice AI Wins vs. When Humans Must Win

Do not try to automate every conversation. Use this simple guide to decide what to give to an AI and what to keep with humans:

Sales Task	Best Fit	Why
Dialing cold lead lists at scale	Voice AI	Fast, tireless, handles voicemails instantly
Asking simple qualification questions	Voice AI	Checks budget, company size, and timeline
Rescheduling missed appointments	Voice AI	Easy calendar lookups and SMS confirmations
Handling angry or skeptical prospects	Human Rep	Needs empathy, patience, and creative problem-solving
Negotiating custom contract pricing	Human Rep	Requires business judgment and flexibility
Closing high-ticket enterprise deals	Human Rep	Trust and relationship building win big deals

The Winning Strategy: The Hybrid Assembly Line

The smartest companies do not fire their sales reps.

They build an assembly line:

The Voice AI makes the first contact, filters out dead numbers, and asks basic qualification questions.
It hooks into an AI automation workflow to log notes and book meetings directly on the calendar.
Your human sales reps spend 100% of their day talking to pre-qualified, interested buyers instead of dialing 50 cold numbers.

This is where AI agents for small businesses deliver real financial return. It is not about replacing human connection. It is about removing the repetitive phone grind so your best people can focus on closing deals.

Over to You

Have you experimented with voice AI agents for outbound sales or customer qualification? What has been your biggest headache with latency, pickup rates, or carrier flags?

Let's discuss in the comments below!

12 AI Consulting Firms to Consider in 2026: A Developer's Guide

Vrunda Chauhan — Mon, 12 Oct 2026 11:07:32 +0000

Businesses use dozens of tools every day, from CRMs and ERPs to customer support platforms, spreadsheets, and internal dashboards.

But many of these systems still depend on manual work.

Employees copy data between applications, update records, review documents, answer repeated questions, and prepare reports.

Individually, these tasks may seem small. Together, they create delays, increase costs, and make it harder for businesses to scale.

This is why AI-powered business automation is becoming important.

The goal isn't to replace every manual task with AI. It's to build connected workflows that reduce repetitive work, improve accuracy, and allow teams to focus on more valuable activities.

However, implementing automation across real business systems requires much more than connecting an LLM to an API.

Why Traditional Business Automation Is No Longer Enough

Traditional automation works well when processes follow fixed rules.

For example:

When a customer submits a form, create a CRM record.
When an invoice is approved, update the accounting system.
When an order is placed, send a confirmation email.

These workflows are predictable.

But business processes often involve unstructured information, changing requirements, and decisions that cannot be handled with simple rules.

Consider an incoming customer email.

A traditional workflow might detect keywords and route the email to a support queue.

An AI-powered workflow can interpret the customer's request, identify the relevant account, retrieve information from internal systems, and prepare an appropriate response.

The difference is not simply faster execution.

AI makes it possible to automate parts of workflows that previously required human interpretation.

That said, AI should not make every decision independently. Sensitive actions, such as refunds, payments, and account changes, still need defined rules, permissions, and human approval when appropriate.

Where AI Automation Creates Business Value

The strongest automation opportunities are usually found in repetitive, high-volume processes involving multiple systems.

Business area	Common problem	AI automation opportunity
Customer support	Repeated questions and slow responses	Classify requests, retrieve answers, and prepare responses
Sales operations	Manual lead research and CRM updates	Extract lead information, enrich records, and prioritize follow-ups
Finance	Manual invoice processing	Extract invoice data, match records, and flag exceptions
HR operations	Repetitive document and policy questions	Search internal knowledge and route employee requests
Supply chain	Disconnected inventory and demand data	Identify anomalies and support demand planning
Internal operations	Data scattered across multiple tools	Connect systems and automate routine workflows

These use cases have one thing in common: they combine business rules, data, and decisions.

This is where AI consulting becomes valuable, especially when an organization lacks the internal engineering capacity to connect these components reliably.

The Real Challenge: Automating an Entire Workflow

Let's take invoice processing as an example.

A business receives hundreds of invoices through email, supplier portals, and shared folders.

The manual process might involve:

Opening the invoice.
Extracting supplier details and amounts.
Checking the purchase order.
Confirming that the invoice matches the order.
Sending exceptions for approval.
Updating the ERP or accounting system.

An AI model can extract information from an invoice, but that is only one part of the workflow.

A reliable automation system also needs to validate the extracted data, check for duplicate invoices, apply business rules, and handle unexpected cases.

A practical architecture might look like this:

Invoice Received → Document Extraction → Data Validation → ERP Matching → Exception Review → Approved Update

The AI component handles interpretation. The surrounding software handles validation, permissions, integration, and execution.

This distinction matters because a successful AI response does not automatically mean a successful business transaction.

If the model extracts an incorrect amount or supplier ID, the system needs a way to detect and stop the error before updating financial records.

That is why reliable business automation requires both AI expertise and conventional software engineering.

Five Technical Challenges Behind AI Business Automation

1. Data is spread across different systems

Most businesses do not have a single source of information.

Customer details may live in Salesforce, transactions in an ERP, support tickets in Zendesk, and operational data in spreadsheets.

An automation system must retrieve the correct information without creating conflicting records.

This requires API integrations, data mapping, authentication, and sometimes event-driven architectures.

2. AI output is not always predictable

Traditional code follows defined logic. LLM output can vary even when the input is similar.

For business workflows, this creates risks.

A system should validate structured outputs against schemas, check required fields, and prevent the model from directly executing sensitive actions without safeguards.

For example, an AI agent might recommend a refund, but the actual refund should pass through a separate service that checks eligibility and approval rules.

3. Automation needs failure handling

What happens if the CRM API is unavailable?

What if the same event is received twice?

What if an AI model times out halfway through a process?

Production automation needs retries, idempotency, logging, and recovery mechanisms.

Without them, an automated workflow can create duplicate records, miss important actions, or fail silently.

4. Security cannot be added later

AI automation often accesses sensitive customer, employee, or financial information.

Teams need to define which systems the automation can access and which actions it can perform.

Important controls include role-based access, audit logs, encrypted data transfer, and approval steps for high-risk operations.

5. Automation must produce measurable results

A working AI workflow is not enough.

Businesses need to know whether it actually improves operations.

Useful metrics include:

Average processing time per task
Cost per completed workflow
Percentage of tasks requiring human review
Error and exception rates
Successful automation completion rate

These metrics help determine whether automation is delivering value or simply introducing another expensive technology layer.

Why Businesses Work With AI Consulting Firms

Building an AI automation system requires several capabilities working together.

A team may need business analysts to understand workflows, data engineers to prepare information, backend developers to build integrations, and AI engineers to implement model-based decisions.

DevOps and security engineers are also important when systems move into production.

An AI consulting firm can bring these skills together and help businesses avoid building isolated automation tools that do not integrate with daily operations.

The right partner should help answer three questions:

What should we automate? Identify repetitive processes with measurable value.

How should we automate it? Choose between rule-based automation, AI-assisted workflows, and AI agents.

How will we operate it safely? Define monitoring, permissions, error handling, and human oversight.

Not every workflow needs an AI agent. Sometimes a simple API integration or rule-based process is cheaper, faster, and more reliable.

A good consulting partner should be able to recognize that difference.

12 AI Consulting Firms to Consider in 2027

Based on their different technical strengths, these companies are worth exploring for AI development, integration, and automation-related projects.

Company	Key capabilities	Where they may fit
1. EnactOn Technologies	AI consulting, workflow automation, data engineering, and deployment	Businesses looking for end-to-end AI implementation
2. Appinventiv	AI-powered web and mobile applications	Customer-facing business applications
3. Simform	AI, cloud engineering, and data platforms	Cloud-based automation and system integration
4. LeewayHertz	Generative AI, LLMs, and AI agents	AI-powered knowledge and decision workflows
5. Markovate	AI agents and business software integrations	CRM and operational workflow automation
6. HatchWorks AI	Data engineering and AI transformation	Businesses improving data foundations before automation
7. EffectiveSoft	Enterprise AI integration and software modernization	Adding AI capabilities to existing systems
8. Neoteric	AI consulting and product engineering	Building custom AI-enabled business tools
9. STX Next	Python, RAG, LLMs, and MLOps	Data-heavy AI applications and integrations
10. Netguru	AI development and digital commerce	eCommerce and marketplace automation
11. Azumo	AI engineering and custom application development	Businesses needing dedicated AI development teams
12. BotsCrew	Conversational AI, chatbots, and AI agents	Customer support and internal assistant automation

These companies serve different project types. A firm experienced in conversational AI may not be the best choice for automating financial workflows or modernizing a complex ERP environment.

The shortlist should depend on the systems involved, the type of automation required, and the team's production experience.

How to Choose the Right AI Automation Partner

Before hiring a consulting firm, ask for a technical walkthrough of a similar automation project.

Focus on these questions:

Integration: How will the automation connect with our existing CRM, ERP, databases, and APIs?
Reliability: How will the system handle failures, duplicate events, and incorrect AI output?
Security: What permissions will the AI have, and which actions require human approval?
Monitoring: How will we track errors, model performance, and workflow completion?
ROI: What metrics will show that automation is saving time or reducing costs?

It is also worth starting with a small, measurable workflow rather than automating an entire department at once.

For example, automate invoice data extraction and validation before attempting fully automated invoice processing.

This makes it easier to test reliability, measure results, and identify problems before expanding the system.

Final Thoughts

AI business automation is not just about replacing manual tasks with intelligent software.

It is about connecting data, systems, business rules, and AI into workflows that operate reliably.

For developers, the challenge is building secure integrations, validating AI output, handling failures, and monitoring the entire process.

For businesses, the challenge is identifying where automation creates enough value to justify the investment.

The best results come when both sides work together.

Start with one clear business problem, build a reliable workflow, measure its performance, and expand only when the results support it.

If you're comparing implementation partners, our original guide covers 12 AI consulting firms, their capabilities, project budgets, and selection criteria.

Explore the complete AI consulting firms comparison

I Asked 4 AI Coding Tools to Design a Multi-Tenant Schema. They All Made the Same Fatal Mistake.

Vrunda Chauhan — Mon, 05 Oct 2026 13:16:31 +0000

I was reviewing an architecture document for a white-label project earlier this week.

Nothing crazy: a SaaS platform where about 60 different client businesses manage their own users, orders, and customer data. Standard multi-tenant setup.

I had ten minutes to kill before a call, and out of sheer curiosity, I decided to run a quick test.

I opened four different AI tools—ChatGPT (GPT-4o), Claude 3.5 Sonnet, Cursor, and Gemini.

I gave all four the exact same prompt:

"Design a PostgreSQL database schema for a multi-tenant B2B SaaS platform that will host 50+ business clients. Show the core tables for users, tenants, and orders."

I didn't expect revolutionary database theory. But I did expect at least some variation in how they approached isolation.

Instead, all four models generated almost the exact same architecture, down to the column names.

And all four shipped the exact same fatal production flaw.

The Code They All Gave Me

Across all four tools, the core schema looked roughly like this:

sql CREATE TABLE tenants ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), name VARCHAR(255) NOT NULL, created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() ); CREATE TABLE users ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), tenant_id UUID REFERENCES tenants(id) ON DELETE CASCADE, email VARCHAR(255) NOT NULL, role VARCHAR(50) NOT NULL ); CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), tenant_id UUID REFERENCES tenants(id) ON DELETE CASCADE, customer_name VARCHAR(255) NOT NULL, total_amount DECIMAL(10, 2) NOT NULL, created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() );

Every single one added a tenant_id foreign key column to every table, slapped an index on it, and called it a day.

Two of them even added a helpful comment at the bottom:
-- Remember to filter by tenant_id in your queries!

And that little comment is where the disaster starts.

The Problem Nobody Notices in Demos

On paper, this shared-table model looks clean. It’s easy to read, easy to run migrations on, and works flawlessly when you’re testing with mock data on localhost:3000.

In production, it is a ticking time bomb. Here's why:

1. It bets your entire security on developer memory

This setup relies 100% on the application layer to enforce tenant boundaries.

That means every single ORM query, raw SQL query, analytics script, background worker, and GraphQL resolver written by anyone on your team has to remember:

sql WHERE tenant_id = current_tenant

It works fine for the first three months.

Then a junior engineer writes an admin export feature. Or someone builds a quick background job to recalculate monthly metrics. Or a complex JOIN accidentally drops the tenant condition.

Suddenly, Restaurant A downloads a CSV report and can see Restaurant B’s order history and customer phone numbers.

I’ve had to help clean up client databases after this exact bug happened in the wild. When tenant isolation lives in application code rather than the database engine, a leak is not an "if"—it is a mathematical certainty over time.

2. Not a single model mentioned Postgres Row-Level Security (RLS)

PostgreSQL has had native Row-Level Security since version 9.5 (that’s over eight years ago).

With RLS, the database itself guarantees that a tenant can never see another tenant's rows, even if an engineer completely forgets to add WHERE tenant_id = ? in their backend code:

sql -- Enable RLS on the table ALTER TABLE orders ENABLE ROW LEVEL SECURITY; -- The database refuses to return rows that don't match the active tenant session CREATE POLICY tenant_isolation_policy ON orders FOR ALL USING (tenant_id = current_setting('app.current_tenant_id')::UUID);

Not one of the four AI tools enabled RLS by default. Not one even flagged it as a best practice in the explanation.

They all treated database security as an afterthought that the application should handle.

3. The GDPR / Data deletion nightmare

When you run a multi-tenant platform with real European or enterprise clients, you eventually get hit with a data deletion request or an offboarding requirement:

"We are ending our contract; delete all our company records and customer PII within 30 days."

With the naive tenant_id setup, your database has millions of rows commingled across shared tables. Deleting one tenant means running heavy cascading DELETE statements across multiple massive tables, fragmenting your indexes, causing table locks, and bloating your WAL logs.

If they had suggested a schema-per-tenant approach (or at least partitioned tables), wiping a client's data is literally as clean as:

sql DROP SCHEMA tenant_acme_corp CASCADE;

Zero locks on other tenants. Instant execution. Clean audit trail.

Why Do AI Models Keep Generating This?

Because LLMs don't optimize for production resilience. They optimize for probability.

And what makes up 90% of the public tutorials, blog posts, and GitHub starter kits on the internet?

Beginner CRUD tutorials.

Tutorials designed to get a reader up and running in a 10-minute YouTube video always use the single-database, tenant_id-on-every-table approach because it's the easiest thing to explain.

The models aren’t recommending it because it’s the right architecture for a B2B SaaS with 50+ businesses. They recommend it because it is the most common pattern in their training weights.

They are optimizing for syntax simplicity, not the 2 AM security breach.

What I’m Doing Differently Now

AI tools are fantastic for scaffolding boilerplate, writing regex, or reminding me of Postgres syntax I haven’t used in months.

But this experiment was a good reminder: AI will almost always default to the "tutorial tier" of architecture unless you explicitly force it into production mode.

If you ask an AI to build a database, don't ask it how to build it. Tell it the constraints:

"Use Postgres Row-Level Security (RLS) for tenant isolation."
"Optimize for zero-downtime client offboarding."
"Ensure tenant boundaries cannot be bypassed by raw SQL queries."

If you don't supply the engineering standards, it will hand you code that works in your demo and blows up in front of your first audit.

Over to You

If you’re running a multi-tenant setup in production right now:

Which model did you go with? (Shared table with RLS, Schema-per-tenant, or separate DBs?)
And have you ever had an AI tool generate code that felt totally normal until you realized it missed a massive security or scaling boundary?

Curious to hear what you guys have seen.

What Happens When an Agency Uses AI to Build Your Backend

Vrunda Chauhan — Mon, 28 Sep 2026 11:12:55 +0000

Over the last six months at EnactOn, we’ve started noticing a brand-new category of emergency audit requests.

It used to be that when a founder brought us broken software, it was built by a junior freelancer who was clearly in over their head. You’d find messy spaghetti code, but at least someone had sat there and typed it out by hand.

Lately, though, the code looks completely different.

The variable names are pristine. The comments look like they were written by a textbook author. The frontend is built with clean Tailwind components, smooth loaders, and snappy interactive states. On a screen-share demo, the app looks like a million bucks.

Then you look at the backend, and you realize what actually happened:

The agency charged the founder $15,000 for "senior custom development," opened an AI code generator, prompted their way through the backend in four days, and collected the final invoice.

AI coding assistants are incredible tools when an experienced engineer is steering them. But when an agency uses AI to generate an entire backend so they can cut corners, it creates a very specific kind of technical disaster.

Here is what actually breaks under the hood, why demos never catch it, and how to tell if your app was built on a foundation of sand.

1. The Exposed Root Key (How AI Fixes Permission Errors)

If you’ve ever watched someone build an app with an AI tool, you know how it handles friction.

When a human engineer runs into a database permission error, they take the time to configure server roles, environment boundaries, and access policies.

When an AI hits that same permission error, it doesn't care about security. It just wants the red error text in the terminal to disappear. And the fastest way to make the error disappear is to use the master admin key that bypasses all security rules:

// What the AI puts in a frontend component to make the error go away:
import { createClient } from '@supabase/supabase-js'

export const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY! // 🚩 Root bypass key bundled into every user's browser
)

Because the agency developer was just prompting instead of reading the architecture docs, they don't realize that prefixing a secret key with NEXT_PUBLIC_ literally bundles that key into the public JavaScript downloaded by every single visitor.

To the founder clicking around on a staging link, the app works seamlessly.

To anyone who opens Chrome DevTools and searches the network tab, the master key is sitting right there. Anyone with that key can read, modify, or drop the entire database without ever logging in.

2. The Illusion of Security: DISABLE ROW LEVEL SECURITY

In modern serverless databases like Supabase or Postgres, Row-Level Security (RLS) is what stops User A from reading User B's private files.

Writing solid RLS policies takes real thought. You have to write specific rules for every single table: who can insert, who can read, who can delete.

When an agency prompts an AI to scaffold ten database tables at once, the queries almost always fail because the policies conflict with each other.

We recently audited a health-tracking app where the previous dev team had run into this exact wall. Their solution? The agency had simply run this command across all eight tables:

ALTER TABLE user_medical_records DISABLE ROW LEVEL SECURITY;

The app stopped throwing permission errors. The agency marked the sprint as complete.

On a demo call with one test account, everything looked completely normal. But because RLS was turned off and the queries weren't guarded on the server, the entire table of sensitive patient intake logs was completely public to anyone who sent a raw GET request to their API endpoint.

Frontend forms don't protect data. If the database rules aren't enforced at the table level, you don't have security. You just have an unlocked door with a polite sign hanging on it.

3. Fake Scale: The Infinite Loop & Memory Bloat

AI models are trained on millions of simple tutorial projects. And in a tutorial project with five sample rows, you don't worry about connection pooling, rate limiting, or pagination.

This is where the "fake scale" kicks in.

We audited an internal directory app where the search bar felt blazing fast during the founder's initial review. But the second twenty people started using it at the same time, their server CPU shot to 100% and the entire site went down.

When we opened the codebase, we found two classic AI habits:

Unbounded Data Fetching: Instead of asking the database for the ten specific records on page one, the generated code was fetching all 15,000 directory rows into the server's memory on every single keystroke, then running a JavaScript .filter() in memory.
Missing Dependency Arrays: The AI had wired a data fetch inside a React useEffect without proper caching or dependency boundaries, causing the frontend to re-fetch the entire database every time the user's cursor hovered over a menu item.

In local testing on a developer's laptop, pulling 15 mock records takes 3 milliseconds. You never notice the problem.

In production with real users, you burn through your entire monthly database connection pool in twenty minutes, and the hosting provider slaps you with a 504 Gateway Timeout.

The Reality of Vibe Coding Development

We don't tell founders to avoid AI. AI has permanently changed the speed at which you can validate an idea, build a proof of concept, and test customer interest.

The problem starts when an agency treats a vibe-coded prototype like production-ready software.

A prototype only needs to survive a demo call with one person clicking the obvious buttons. A real software product has to survive real strangers: people with spotty Wi-Fi, people running script crawlers, and multiple users hitting the same database at the exact same second.

When an agency skips foundational engineering and lets an AI hallucinate the backend, they haven't saved you money. They’ve just taken out an uncollateralized loan on your technical debt that comes due the week you launch.

3 Quick Checks to Run on Your Own App Right Now

If an agency built your MVP using AI and you want to know what you’re actually dealing with before you launch, you don't need a computer science degree to check these three things:

- Check the Network Bundle: Open your app in Chrome, hit Inspect, go to the Network tab, reload the page, and filter by JS. Search inside the files for words like service_role, admin_secret, or your database master password. If they show up in the browser, your database is exposed.

- The RLS Confirmation: Ask your agency to send you a screenshot of your database console showing your active Row-Level Security policies. If every table says "RLS Disabled" or "No Policies Applied," your data is wide open.

- The Incognito Data Test: Open two different browser profiles. Log in as Account A in one, and Account B in the other. Try to access Account A’s private resource ID directly from Account B. If the app serves the data without an unauthorized error, your backend has no real authorization logic.

Has anyone else here had to step in and rescue an "AI-built" backend recently? What was the wildest shortcut you found buried in the code?

Four Times a "Quick Cleanup" Became an Emergency Rebuild

Vrunda Chauhan — Wed, 23 Sep 2026 13:30:00 +0000

Every engineering team has opened an inbox to find this message:

"The app is basically finished. We just need a developer for a day or two to clean up a couple of small things before our launch next week." Over the past year at EnactOn, we have audited dozens of inherited projects. Four times, what looked like a harmless 48-hour polish job turned out to be a structural house of cards that required an immediate rebuild. When founders evaluate software, they look at what is rendered on screen: nice colors, smooth animations, and working buttons. But software rarely breaks on the surface. It breaks in the invisible plumbing underneath. Here is what actually happened in all four cases, and what we learned from fixing them.

Case 1: The "Simple Lead Form" That Silently Lost 350 Customers

A B2B founder reached out because a form on his landing page "occasionally didn't send an email notification." When we inspected the setup, we found that the previous developer had avoided writing a backend. Instead, they stitched together eight different third-party no-code tools and browser scripts with webhooks. One script sent form data to a spreadsheet, another pulled from the spreadsheet to trigger an email, and a third tried to update a CRM. When the founder changed a single column name in the spreadsheet, the entire chain silently broke. For three weeks, the form looked completely normal to website visitors, but 350 inbound customer leads disappeared into the void. You cannot patch eight brittle automations running without error logs. We replaced the entire duct-tape workflow with a clean, single-endpoint backend and a database. Setting up a dedicated saas mvp development pipeline from day one costs far less than losing hundreds of warm customer leads.

Case 2: The "Slow Export Button" Costing $1,400 a Month in Cloud Fees

A small business client asked us to speed up their "Export Monthly Report" button because it took nearly two minutes to generate a simple spreadsheet. When we opened the server logs, we found something unbelievable: Every time an employee clicked "Export," the server downloaded their company's entire 60GB cloud storage bucket into server memory, processed every single image and document, and then generated the CSV. The client only had 50 active users, but their AWS cloud bill was running $1,400 every single month purely in unnecessary bandwidth fees. We rewrote the export service to query only the text database metadata. The report now downloads in under 800 milliseconds, and their cloud hosting bill plummeted from $1,400/month down to $38/month. Implementing lean DevOps best practices for startups prevents hidden architectural bloat from draining your runway.

Case 3: The "Color Change" Request With No Source Code

A client reached out with a tiny design tweak: "We just want to update our brand colors, swap our logo, and add two new form fields." We asked for access to their GitHub repository.

When we logged into their hosting account, we discovered the previous contractor had only uploaded a compiled, minified JavaScript file (app.min.js). The contractor had stored the actual source code on their personal laptop and had stopped answering emails three months earlier. The client owned a live URL, but they owned zero intellectual property. You cannot edit compiled production code. We had to recreate their interface from scratch in clean Next.js and properly transfer complete repository ownership to the founder. Failing to secure your source code repository is among the most painful mistakes to avoid before developing your MVP.

Case 4: The "AI-Generated Parser" That Only Worked on Two Files

A non-technical founder used an AI coding assistant to build an automated invoice parser for his logistics business. He told us: "The AI built the whole thing in a weekend! It works great, we just need you to fix a minor bug where some PDF dates are missed." When we opened the codebase, the AI had generated 1,400 lines of brittle string hacks with no data validation. The logic had been tailored precisely to the two sample PDFs the founder used in his initial AI prompts. The moment real vendors uploaded invoices with slightly different fonts or table layouts, the parser completely broke. Worse, every time we adjusted one line of code, three other invoice types failed. AI tools are incredible for rapid prototyping, but building durable production systems requires structured architecture. We replaced the 1,400 lines of fragile script with a structured document pipeline. For founders exploring vibe coding development, prototypes prove customer demand, but production code requires human architectural design.

The 4 Warning Signs You Are Facing a Rebuild

If you are inheriting or taking over a codebase, watch for these four red flags:

The Duct-Tape Stack: Critical business workflows depend on multiple third-party tools glued together with zero error monitoring.

Runaway Infrastructure Bills: Cloud costs are high despite having relatively few active users.

Missing Source Repositories: The code is hosted live, but no one has access to clean, uncompiled Git version history.

Fragile AI Monoliths: Massive files generated by AI where fixing one bug introduces two new ones. Catching these issues early saves you from promising a 2-day fix on a 4-week rebuild.

Why an $800 MVP Cost $6,000 to Make Work

Vrunda Chauhan — Tue, 22 Sep 2026 12:13:14 +0000

Two months ago, a non-technical founder reached out to our engineering team at EnactOn.

He had hired an agency on a freelance marketplace to build a multi-tenant booking platform. The agreed contract was $800 with a promised delivery of 21 days. On day 22, the contractors delivered a zipped archive, collected their final milestone payment, and marked the project complete.

On the surface, the application looked finished. The UI was responsive and used a polished Tailwind dashboard theme.

The moment he invited 15 local business owners to test the beta, the wheels came off:

Competitors could see each other's financial invoices by changing the company ID number in the browser URL.
Credit cards were charged, but booking records vanished whenever a user closed their browser tab before the confirmation screen finished loading.
With only 30 active users testing the calendar, page loads crawled to 4.2 seconds because the database had zero table indexes.
There was not a single automated integration test or database migration script in the repository.
The founder paid us $6,000 to audit the codebase and make it work in production.

Here is the breakdown of what actually failed, where the rescue budget went, and what to verify before accepting a budget quote.

The Illusion of the Finished Frontend

When evaluating software, non-technical founders judge what they can see. If buttons click, modal windows open, and the layout looks clean on mobile, they assume the heavy engineering is done.

Low-cost agencies understand this dynamic. They spend almost all their billable hours skinning frontend templates, while skipping foundational backend architecture.

1. Authentication as a Client-Side Illusion

The agency verified user permissions by reading a flag in local storage. The backend accepted any incoming request and fetched records without verifying if the requesting user actually belonged to that organization. Overlooking server-side permission checks is among the most severe mistakes to avoid before developing your MVP, because tenant validation must always happen at the database query boundary.

2. Fragile Payment Architecture

Stripe payments were handled entirely on the client side. If a mobile user lost internet connection after submitting their card, Stripe processed the charge, but the backend never received the trigger to create the booking. Reliable financial transactions require server-verified asynchronous webhooks with idempotency keys rather than relying on browser redirects.

3. Unindexed Full-Table Scans

The database contained 14 tables with zero composite indexes on foreign keys. Simple calendar queries forced the database to scan thousands of rows sequentially, pinning CPU usage to 100%.

Where the $6,000 Rebuild Budget Went

Rescuing broken software is almost always slower and more expensive than building it clean from scratch. Our team had to reverse-engineer undocumented assumptions, patch security holes, and migrate tables without losing existing test data.

Here is the exact breakdown of the 80 hours required to stabilize the system:

Security & Tenant Isolation (24 hrs - $1,800): Enforced session-bound tenant validation across 18 API routes so no organization could view another's data.
Payment & Webhook Reliability (18 hrs - $1,350): Rebuilt the checkout pipeline with server-side webhook signature verification and database idempotency to eliminate ghost charges.
Database Optimization (14 hrs - $1,050): Created structured migration scripts, added composite indexes, and resolved table-locking bottlenecks (reducing response latency from 4,200ms down to 38ms).
Automated Integration Tests (16 hrs - $1,200): Wrote 42 end-to-end tests covering authentication, payments, and calendar scheduling following a structured mobile app testing checklist.
Production CI/CD & Deployment (8 hrs - $600): Automated container builds and secret management aligned with standard DevOps best practices for startups.

The Takeaway

An $800 quote for a full-stack SaaS is an uncollateralized loan with high interest that comes due during launch week. Estimating the realistic cost to build an MVP requires evaluating database design and transaction integrity, not just UI components.

Before signing off on any MVP development contract, ask for three specific deliverables:

1. Version-controlled database migrations instead of raw database dumps.
2. Server-enforced tenant isolation on all database queries.
3. Automated integration tests for authentication and payment flows.

What's One Thing You Wish Founders Understood About How Software Actually Gets Built?

Vrunda Chauhan — Fri, 18 Sep 2026 13:22:06 +0000

We get asked some version of "does it work?" from almost every founder we talk to. It's the wrong question, and we've never found a polite way to say that in a first call, so here's the honest version instead.

The question that actually decides whether a product survives isn't "does it work." It's "what happens when it doesn't?"

Founders are trained to expect success. Users aren't obligated to give it to them.

Most non-technical founders have spent their whole working life using software that already works. They open an app, it does the thing, they move on. Nothing in that experience trains a person to picture the ways it could have failed, because by the time it reaches them, someone already found and fixed those ways.

Building it is the opposite kind of work. A login screen isn't hard because handling a correct password is hard. It's the wrong password, the account that doesn't exist yet, the password reset nobody built, and the session that expires mid-form that actually take the time. A checkout flow isn't hard because charging a working card is hard. It's the declined card, the one that gets flagged after the page already said "success," and the promo code that collides with a discount nobody tested together that take the time. The part a founder sees in a demo is usually the easy 80%. The part that decides whether real strangers can trust the product with their time or their money is the 20% that never shows up unless you go looking for it on purpose.

The question that actually decides whether a product survives isn't "does it work." It's "what happens when it doesn't?"

Founders are trained to expect success. Users aren't obligated to give it to them.

This is exactly why demos lie a little, even honest ones

A demo is a controlled environment. You click the happy path because you already know where it is. Real users don't know where it is, and they won't follow it. They'll double-click a submit button, lose their wifi mid-upload, open the app on a second device, or type an email address with a typo in it, all in the first ten minutes. None of that is bad luck. It's just what a large enough group of ordinary people actually does, and most early products that stall don't fail because the idea was wrong. They fail because the failure paths were never built, and the first real user to wander off the happy path found that out before the founder did.

This gets worse, not better, with how fast products get built now. A one-sentence prompt into an AI app builder can produce something that looks completely finished in an afternoon, because the tools are genuinely good at the visible 80%. They're rarely asked to handle the invisible 20%, because nothing about a fast demo ever forces the question. The gap doesn't announce itself. It just waits for the first real user.

What we actually mean when we say something is "done"

This is close to the standard we hold at EnactOn before we call anything ready: not "does it work when I click it the right way," but "what does it do when someone clicks it the wrong way, on a bad connection, at 2am, using a card that gets declined." A real build process treats that question as part of the work, not as a nice-to-have you get to if there's time left, because there's rarely time left, and the founder is the one standing in front of the user when it shows up unhandled.

None of this means founders need to learn to code. It means the next time something "works" in a demo, the better question to ask isn't "did it work." It's "what did we never actually try to break." A real pre-launch check exists to ask exactly that, on purpose, before a stranger asks it for you.

So, genuinely: what's one thing you wish a founder understood about how software actually gets built?
A demo is a controlled environment. You click the happy path because you already know where it is. Real users don't know where it is, and they won't follow it. They'll double-click a submit button, lose their wifi mid-upload, open the app on a second device, or type an email address with a typo in it, all in the first ten minutes. None of that is bad luck. It's just what a large enough group of ordinary people actually does, and most early products that stall don't fail because the idea was wrong. They fail because the failure paths were never built, and the first real user to wander off the happy path found that out before the founder did.

What we actually mean when we say something is "done"

So, genuinely: what's one thing you wish a founder understood about how software actually gets built?