A product team runs a two-week embedded iPaaS trial. The senior engineer picks an integration from the vendor's getting-started guide, gets it working in a day, and demos it to the team. Everyone's impressed, and the contract is signed in due course.
Three months later, that same engineer is in a post-mortem. Among other things, the platform can't handle the data volume coming from their largest enterprise customer, and the security team has found PII in plain text in execution logs.
None of that showed up in the POC. It wasn't because the platform hid it, but because the team never looked for it.
Most POCs are designed to answer the question, "Can we build a working integration?" That's a reasonable starting point, but it doesn't give you a clear sense of whether the platform will work for your customers and your team five years from now.
So, how do you get to that answer? You need an embedded iPaaS that can support integrations as a scalable, customer-facing feature of your product (under real load, with real customer data, and managed by the cross-functional team that will own it).
But way too many POCs don't go deep into the important details. Here's why, and how to run one that does.
Trials can be designed to mislead
Many vendors optimize integration trial environments for a fast, satisfying experience. Onboarding flows, sandbox environments, and documentation are set up to make those first few days of development easy. It's not deceptive, as such. But the side effect is a trial environment that doesn't reflect real-world integrations.
Then, add another factor: the engineer running the POC has a week or two before a decision is needed. They're unlikely to go out of their way to stress-test specific rate limit behavior. And the product manager who scheduled the trial is interested in whether the trial resulted in a shippable integration.
The result is a POC that measures how easy a platform is to learn, and not how capable or durable it is for the long term. Every embedded iPaaS looks pretty good when you're building a clean integration in a sandbox. However, real-world integration scenarios don't just appear in a standard two-week trial. You must actively work them in.
Five common failures of an embedded iPaaS POC
Building a toy integration
A toy integration is a simple flow that bears little resemblance to your production requirements. Push a Salesforce contact to your product. Move a record from A to B. Clean input and clean output with exactly zero edge cases and no failures to handle.
Real integrations involve complexities such as branching logic triggered by field values that may be null. They transform data from a schema designed by someone who left the company three years ago. They fail partway through a batch and need to recover without duplicating records.
If your POC integration would never see production, you're not really evaluating the full platform. So, don't build a toy. Instead, grab a real integration request from your backlog, something that's been sitting there because it's complicated. Now, see what the platform can do.
Testing build speed exclusively
A platform that makes new integrations fast to build can still make integrations painful to own. Issues with versioning, rollback, debugging, and schema changes in live integrations don't appear when you're building something fresh in a trial. But those things do show up at the most inopportune time after you've gone live.
There could also be a resource problem. The engineer running your POC is probably your best dev. They may not be a representative user of the platform over time. DevX problems often appear with junior developers, inherited code, and teams under pressure – conditions that probably don't exist in a two-week trial.
So, test both build tracks in parallel. Have a non-technical stakeholder configure and deploy an integration using the low-code designer. At the same time, have a senior engineer ignore the designer entirely and build a custom component from their local IDE using the CLI and SDK. If the code-native approach doesn't support existing tooling or produces code that can't be unit tested or committed to Git, that's a significant (negative) finding.
Then deliberately introduce a failure. Break something on purpose and measure how long it takes someone who didn't build it to diagnose and fix it.
Simulating non-production conditions
Every embedded iPaaS looks similar at near-idle conditions. The architectural differences (how the platform handles things like queuing, rate limiting, and concurrent tenant load) only show up under pressure. A platform that performs cleanly in your sandbox can fall apart when you take it live in production for the first time.
Behavioral questions matter as much as raw throughput. Does the platform automatically retry failed steps? Does it handle partial batch failures – completing what it can while logging and displaying what it couldn't? What happens to in-flight data when an execution times out? Can a spike in one customer’s integration data degrade another customer's integration? Can your CS team replay a failed execution without relying on engineering?
Run a test with data volumes that reflect your 90th percentile customer. Deliberately attempt to pass malformed payloads through the interface. Trigger a rate limit and watch what the platform does with it. Will the platform let you know when there are issues, or will the notification come from your customer?
Treating security as a post-decision problem
Too often, security stakeholders get involved after a preferred vendor has already been identified, and that's not a good thing.
The SOC 2 badge is a starting point, not a security evaluation. It doesn't tell you how customer credentials are isolated per tenant, what appears in execution logs, whether sensitive field values might show up in debugging interfaces, or how the platform walls off a security incident so it doesn't affect other customers.
In a multi-tenant embedded iPaaS, your customers' API keys and OAuth tokens are managed by the platform. If the logging implementation is careless, sensitive values (PII, financial data, and auth tokens) can be persisted in plain text.
Bring your security team in at the beginning. Request the SOC 2 Type II report and review the exceptions, not just the cover page. Trigger an integration with sensitive-looking test data and verify what the logs really capture. Ask the vendor directly about per-tenant credential isolation, RBAC, audit logging, and VPC deployment options.
Having the wrong people in the room
An embedded integration platform isn't only an engineering decision. It's a product decision that engineering, CS, product, security, and sales all have a stake in (since they all need to interact with whatever platform you choose).
When only engineering does the POC, the perspective is too narrow. Later on, you discover that the monitoring tools don't support customer issues without a dev on every ticket, that sales has been promising a self-service marketplace that requires significant per-customer engineering to configure, or security flags credential issues that everyone assumed someone else had already reviewed and cleared.
Before the POC starts, map out who will own, build, support, and sell integrations after the platform is implemented. The question a POC needs to answer should never be "Can we build integrations?" but "Can our organization effectively and efficiently offer integrations as part of our product?"
Who should participate in the POC?
The POC must include stakeholders from across the company. And, it's important for each of them that they answer questions like the following:
- Engineering lead – What does it feel like to build, debug, and maintain integrations at scale and not just ship new ones in a sandbox?
- Security/compliance – How are credentials stored and isolated per tenant? What ends up in logs? Does the vendor's posture hold up under direct scrutiny?
- Product manager – What can we ship to customers, and what will require more engineering time than anyone is planning for?
- Customer success – Can we monitor, diagnose, and resolve integration issues without engineering?
- Sales – What can we credibly commit to prospects, and what does time-to-value look like when the platform's in place?
If any of these folks aren't part of the POC, you'll be handling issues after implementing the platform that could have been addressed before contract signing.
Embedded iPaaS POC evaluation checklist
A box you can't check tells you something, whether it's a gap in your evaluation process or a platform limitation worth calling out before you sign.
Build and developer experience
- Built at least one integration representative of real production complexity, not a happy-path demo.
- Tested the low-code path with a non-technical stakeholder and the code-native path with an engineer, in parallel.
- Deliberately triggered a failure; measured time-to-diagnosis for someone who didn't build it.
- Reviewed the versioning, rollback, and deployment workflow end-to-end.
- Confirmed CI/CD capabilities align with your existing engineering workflow.
Scale and operational resilience
- Tested with data volumes that represent your 90th-percentile customer.
- Passed malformed payloads through the integration and evaluated error handling.
- Triggered a rate limit or downstream API failure and observed the platform's response.
- Confirmed what happens to in-flight data on an execution timeout or mid-batch failure.
- Verified CS can replay a failed execution without engineering involvement.
- Reviewed alerting, execution log visibility, and depth of monitoring access.
Security and compliance
- Requested and reviewed the SOC 2 Type II report, including exceptions.
- Confirmed per-tenant credential isolation and encryption.
- Checked what appears in execution logs when sensitive data flows through an integration.
- Confirmed RBAC, SSO/SAML, audit logging, and data residency functionality.
- Involved the security team as active evaluators from the start.
Customer-facing experience
- Walked through the setup flow as the customer, not as an admin.
- Confirmed the scope of white-label and branding customization.
- Understood what customers see on failure and how much of that messaging you control.
- Defined realistic self-service capabilities versus CS tasks.
Stakeholder coverage
- Engineering evaluated the build, debug, and maintenance processes.
- Security reviewed credential handling, tenant isolation, and compliance.
- Customer success reviewed monitoring, alerting, and support tooling.
- Product reviewed customer-facing UX and the config experience.
- Sales confirmed what can be credibly committed to prospects.
Make the POC earn its answer
A well-run evaluation should produce one of two outcomes: a clear decision to move forward or to remove the platform from the evaluation. Both are useful outcomes.
Don't be satisfied with a false positive (what you get when you only test what you were pretty sure would work). The teams that learn the most from their evaluations treat the POC as a somewhat adversarial exercise. They're identifying the platform's weaknesses and shortcomings, what it takes to operate at scale, and whether it can support the integration roadmap over the coming years.
That's the POC worth running.
