Blog
/
Integrations

The best platforms for customer integrations when every customer needs their own

16 min read
Night landscape with a lit bridge crossing dark water.
Table of contents
Section oneSection two

There are two completely different problems hiding inside the phrase "customer integrations," and buying software for the wrong one wastes a year.

The first problem is productized: you want every customer to connect the same popular apps to your product, through a settings page, at self-serve scale. That is a product feature, it ships once for everyone, and a whole category of embedded integration tooling exists to serve it. This article is not about that problem.

The second problem is the one growing underneath the AI wave: integrations that exist for exactly one customer. Their ERP, configured the way only they configured it. Their data warehouse, their approval flow, their security review. Work like this cannot ship once for everyone, because its entire value is that it fits one environment precisely. It is built by forward deployed engineers, sales engineers, and solutions teams, one customer at a time, and demand for the people who do it has exploded: Business Insider reported Indeed postings for forward deployed engineers rose 543 percent between January and April 2025, and by April 2026 sat 5,230 percent above the January 2025 baseline.

The evidence says this second kind of integration is where AI deals are won or lost. MIT's Project NANDA found that 95 percent of enterprise generative AI pilots delivered no measurable P&L impact, and that the successful minority ran systems adapted to the customer's specific workflows. Adaptation is an integration problem. Generic connections are table stakes; customer-specific connections are the product working.

What is a customer-specific integration? A customer-specific integration is code built for exactly one customer: it connects a vendor's product to that customer's particular systems, data shapes, and workflows. Unlike productized integrations, which ship identically to every customer, customer-specific integrations are bespoke, carry that customer's credentials, and must be operated for as long as the customer stays.

What follows are the six real ways teams build and run this work, evaluated on the questions that decide outcomes: how fast can you ship one, where does it run, who holds the credentials, what happens when it breaks, and what happens when its author leaves. If those five questions sound familiar, they are the same five verbs we use to define the category in our guide to FDE ops platforms; this article is the integration-shaped view of the same territory.

The anatomy of one customer integration

Before comparing platforms, it helps to see the whole life of the thing being platformed, because most tooling decisions get made while looking at only the first third of it.

A customer-specific integration is born in the sales cycle: a prospect says "we would buy this if it talked to our system," and an engineer scopes what "talked to" means in their environment. Then comes the build, usually days, and the part nobody scopes: the customer's security review, which asks where the integration runs, what credentials it holds, and who can see them. Then launch, and the integration disappears from everyone's attention while doing its job.

The second two-thirds is where platforms earn their keep. The customer upgrades their system and the integration drifts. They request a change, and someone must find the current version, modify it safely, and redeploy without breaking the running copy. The engineer who built it changes territories. The customer's security team re-audits at renewal and asks the same credential questions again, expecting the same answers. Multiply by every customer on the books, and the real product being bought is not a build tool; it is a memory: where everything is, what version it is, and who can touch it.

Evaluate every option below against the whole lifecycle, not the demo-day third.

1. Archway: deployed customer integrations with organizational custody

Archway is the platform for forward deployed engineering teams: build and manage customer-specific code at scale. It treats the one-customer integration as its native unit of work, called a bridge: a serverless function that connects your product to one customer's systems.

Against the five questions, the answers are the product. Shipping is minutes, not sprints: no infrastructure ticket, no change to the core product, so the integration a customer asked for in Tuesday's call can be live before Friday's. Running is the platform's job. Credentials go into an AES-256 vault with zero-access custody, so the customer's API keys are referenced by code but never visible to engineers, which converts the scariest question in enterprise security review into a one-sentence answer. Every version is retained and owned by the organization, so "what changed" always has an answer. And when the engineer who built a customer's integrations moves on, the bridges stay org-owned: versions retained, credentials still vaulted, and the work reassigns to another engineer in the same org. Handoff here is that reassignment, plus a note, not a ceremony the customer has to sit through. There is AI-powered coding help in the editor to speed up each build, which is a nice feature on top of the part that matters, the operations underneath.

The pricing model matches the work's shape: two bridges free, then $45 per bridge per month, scaling with integrations rather than seats. For a team evaluating options, that means the test is concrete: put one real customer integration on it and compare the week you just had with the week you usually have.

Choose Archway when customer-specific integrations are a recurring motion, not an exception, and you want shipping speed for engineers with custody and continuity for the organization from day one.

2. Deliver code into the customer's infrastructure

The oldest answer in enterprise software: build the integration, then hand it over. The code runs in the customer's cloud, under the customer's credentials, operated by the customer's team. Your engineers write it; their engineers run it.

The genuine advantages are sovereignty-shaped. The customer's security team often prefers it, since credentials never leave their walls. Regulated industries sometimes require it. And your team carries no operational pager for it, in theory.

The honest costs surface within two quarters. Every deployment now moves at the speed of the customer's change-management process, which is the speed your FDE was hired to route around. Debugging happens over screen shares into environments you cannot touch. Versions fork silently: the copy you shipped and the copy they modified stop matching, and nobody is sure when. And the handoff problem doubles, because now a departure on either side orphans the integration. Teams that live this pattern describe the same arc: delivery day feels clean, month six feels like maintaining software through a keyhole.

Choose customer-side delivery when the customer's regulatory or sovereignty requirements genuinely mandate it, and price in the support motion honestly rather than discovering it.

3. Build middleware in your own cloud

The default for product-led engineering organizations: stand up a customer-integrations service inside your existing infrastructure. One multi-tenant codebase, per-customer configuration, deployed through your normal pipelines.

When it works, it works because integrations turned out to be less bespoke than feared: ten customers needed the same three connectors with different settings, and middleware productized them. That is a good outcome, and worth testing for.

The failure mode is quieter. Truly bespoke work does not fit a multi-tenant service, so each new customer adds branches, feature flags, and special cases to shared code. Deploys now ride the product release train, which means an urgent one-customer fix waits on everyone's regression suite. The roadmap tax appears: product engineers pulled into customer-of-the-week work, which is precisely the resource the company was protecting. And because the service is shared, one customer's peculiar failure can degrade another's, which turns bespoke work into a reliability liability. The pattern that pushed companies toward forward deployed teams in the first place was exactly this collision between one-customer speed and all-customer safety; a platform that lets customer code ship without touching the core product exists to end that collision, not relocate it.

Choose middleware when your customer integrations are genuinely convergent, a catalog wearing custom clothing, and be ruthless about moving work out the moment it stops converging.

4. Stretch the core product: config, flags, and professional services hours

Some organizations refuse the premise: no customer-specific code, only configuration. Product management holds the line, custom requests become feature flags, and a professional services team clicks the product into shape per customer.

The discipline is admirable and sometimes correct. A single codebase stays clean, every customization is upgrade-safe, and nothing exists outside the product's security model. If your market's requests genuinely cluster, configuration is the cheapest custody there is: nothing bespoke exists, so nothing bespoke can be orphaned.

The cost is deals. The moment a strategic customer needs the thing configuration cannot express, this model offers two answers, no or roadmap, and both lose. "No" sends the deal to a competitor whose engineer said yes. "Roadmap" means the whole company's engineering queue prices one customer's requirement, which is how a $200K deal ends up bidding against the quarter's plan. The rise of the FDE role is, in large part, the market pricing this dead end: Bloomberry counted the title growing 1,165 percent year over year because companies decided the right answer to bespoke demand is a person plus a lane for bespoke work, not a harder no.

Choose product-stretch when your segment's needs truly converge and your win rate proves it, with a pre-decided escape lane for the strategic exceptions.

5. Hire the integration out: systems integrators and agencies

When the team is underwater, the classic move is to buy capacity: a systems integrator, a boutique consultancy, or a contractor builds the customer integration.

Bought capacity is real. Good integrators arrive with pattern knowledge from a hundred similar projects, and for a one-time migration with a defined end state, renting expertise beats growing it. The economics and the tradeoffs of that route, including when it genuinely wins, get a full treatment in our guide to AI implementation consultants versus FDEs.

For recurring customer-specific work, though, three structural problems compound. The knowledge leaves: everything learned about your product and your customer's environment walks out at contract end. The artifacts scatter: code, credentials, and context end up wherever the contractor's process left them, which your security team discovers during an audit, not before. And the economics invert at volume: consultants price per engagement, so integration fifty costs what integration five did, while an in-house motion on a platform gets cheaper per build as the estate grows. Outsourcing the work without owning the operational layer means renting the muscle and losing the memory.

Choose the integrator route for bounded, one-time projects with a real end state, and insist the deliverables land in infrastructure you own, not in the contractor's drive.

6. Build an internal integrations platform

At sufficient scale, companies stop choosing between the options above and build their own: an internal platform team that gives customer-facing engineers golden paths for shipping one-customer work. The famous forward deployed organizations grew exactly this way, over years.

Everything said in the FDE ops platform guide about internal builds applies with one integration-specific addition: the connector library. Internal platforms succeed when they compound, and integration work compounds through reusable connectors, shared authentication handling, and per-customer scaffolding. That compounding requires dedicated staffing forever, and its scope is deceptive: deploy paths, hosting, credential custody, version retention, and transfer workflows, each a product in itself. Priced against $45 per bridge per month, the internal build has to clear a high bar to beat renting the same machinery, and the bar rises every quarter the vendor platform ships.

Choose the internal build when customer integrations are your business's core motion at a scale where owning the machinery is strategy, not preference, and you can fund the team indefinitely.

The gate everyone forgets: the customer's security review

Whatever you pick, one moment tests it: the customer's security team asks how their credentials are handled. Customer-specific integrations are, by definition, holders of customer secrets: API keys, database access, service accounts. Enterprise security reviews now routinely ask three questions about them. Where are our credentials stored? Who at your company can read them? What is your process when someone with access leaves?

Run the six options through those three questions and the field separates fast. Customer-side delivery answers well by giving up the work entirely: the credentials stay home, along with your ability to operate anything. Middleware and roll-your-own answer with policy: credentials sit in a secrets store, readable by whichever engineers deploy, governed by IAM discipline you must document and defend per audit. The integrator route often answers worst, because nobody scoped where the contractor kept things until the audit asked. Product-stretch answers cleanly but only inside the product's boundaries, which is why it loses the deals that need boundaries crossed.

A zero-access vault answers architecturally: credentials are stored encrypted with AES-256, engineers reference them in code but cannot read the values, and departures change nothing about exposure because there was none. That is a one-sentence answer to all three questions, and one-sentence answers are what pass reviews on the first round instead of the third. Security teams do not fear custom code; they fear custom code with unaccountable keys.

Ten questions to ask any platform on your shortlist

Mapped to the five operating questions, in the order they bite:

  1. How long from working code to running code for one customer, measured in minutes or in meetings?

  2. Can a customer-specific change ship without touching the core product or its release train?

  3. Where does each integration run, and who is paged when it stops?

  4. Can an engineer ship a build without ever seeing the customer's credential values?

  5. What would we show a customer's auditor about credential access, and how long would it take to produce?

  6. Is every version of every integration retained, and can we diff and roll back per customer?

  7. Can anyone list, today, every integration running for a given customer?

  8. What is the transfer procedure when an engineer leaves, and how long does it take?

  9. Does cost scale with integrations, seats, or usage, and what does customer fifty cost versus customer five?

  10. What compounds? Does the eleventh build get faster because of the first ten, or start from zero?

Any option that answers eight of ten cleanly will serve you. Most answer three.

When both problems live in one company

Most vendors past a certain size discover they have the productized problem and the bespoke problem at once: a connector catalog every customer uses, plus a growing pile of one-customer work the catalog will never absorb. The mistake is forcing one lane to carry both. Catalog tooling turned on bespoke work produces the middleware failure mode from entry three; bespoke tooling turned on catalog work rebuilds the same connector forty times.

The routing rule that keeps both lanes healthy is a single question asked at intake: will a second customer ever use this exactly as built? If yes, it is product work: it goes to the catalog, ships through the release train, and earns roadmap discussion. If no, it is forward deployed work: it goes to the bespoke lane, ships in minutes on the per-customer platform, and never bids against the roadmap at all. The lane assignment matters more than either lane's tooling, because misrouted work poisons whichever lane received it: bespoke requests stall roadmaps, and productizable requests get built as snowflakes forty times.

Teams that run both lanes report the same second-order effect: the bespoke lane becomes reconnaissance for the catalog. When five customers' one-off bridges converge on the same shape, that is the strongest product signal a roadmap can get, with working reference implementations attached. The lanes are not rivals; the bespoke lane is where the catalog discovers its next entry.

How to choose in one meeting

Put the five operating questions on a whiteboard: ship speed, runtime, credentials, versions, departures. Then be honest about two axes.

Axis one: does your customer work converge or diverge? Convergent work (same connectors, different settings) rewards middleware and configuration. Divergent work (every customer a snowflake) punishes both and rewards a per-customer platform. Most teams discover they have both, which argues for a lane for each rather than one tool forced to do two jobs.

Axis two: who must survive a departure? If the answer is "the customer relationship, the code, and the credentials, all of them," then whatever you choose must make organizational custody structural. Two of the six options above make custody an architecture: Archway, where vaulted credentials and org-owned versions are the design, and the internal platform, where you build that design yourself. The other four make custody a discipline, and disciplines erode under deadline pressure. If a departure this quarter would hurt, read what to do when an FDE leaves before you shortlist anything, because the reading will change the shortlist. The operating manual for the team that has to survive those departures is how to run an FDE team.

A note on migrating between options, because most readers are not choosing fresh. Teams rarely adopt a platform on an empty estate; they adopt it with forty builds already running somewhere worse. The migration rule that avoids customer-facing breakage is parallel running: move one integration at a time, run old and new side by side for a full business cycle of that integration (a week for a daily sync, a month for a month-end job), compare outputs, then cut over and retire the old copy explicitly. Never migrate by big-bang cutover, and never leave the old copy running unowned after the new one takes over, because a forgotten duplicate integration is a future incident with two possible causes. Sequence the migration by the same heat map used everywhere in this corpus: highest-revenue accounts with the worst custody first, the long tail as capacity allows. A migration run this way takes a quarter of background effort and zero customer noise, and every migrated integration immediately starts answering the ten questions above correctly, which means the security-review posture improves account by account rather than someday.

For most teams whose customer-specific work is growing, the sequence that works is unglamorous: put the next real customer integration on Archway, free for the first two bridges, and let the comparison with your current week make the decision. Speed for the people who ship. Custody and control for your organization.

Sources and notes

A long list of live bridges: approval rules, usage reports, data migrations, SLA alerts, reconciliation, provisioning and compliance exports

Deliver hyper-personalized software at scale

Start free

Product

ProductSecurityPricing

Legal

Terms of UsePrivacy PolicyPurchase Terms

© 2026 Archway. All rights reserved.