Adding a New Portal to Browser Automation at Scale Shouldn’t Take an Engineering Sprint
Most browser automation programs don’t stall because the first ten portals were hard. They stall because portal eleven, twelve, and thirteen each need their own script, their own login handling, and their own maintenance plan, and none of that work is reusable from the last portal. Deck is built to break that pattern: a computer use agent platform where adding a new portal to an existing automation program is a configuration step, not a new engineering project.
What actually determines how fast a new portal gets added at scale?
Deck is a computer use agent platform that automates workflows by operating any web interface directly, so a new portal never needs its own custom-built integration before it can join the automation program. Because Deck’s agents interpret a portal’s interface at runtime rather than replaying a script recorded against one specific layout, onboarding a new portal is mostly a matter of pointing an agent at it and defining the task, not writing and testing a new integration from scratch.
The pattern is the same whether the fifth portal being added is a utility bill-pay site or a real estate management system:
- Connect the new portal through Deck, storing credentials in Deck’s vault rather than in application code.
- Define the task the agent should perform there: pull a bill, extract a listing, submit a form.
- Deck’s agent authenticates, navigates, and completes the task using the portal’s existing interface.
- The result returns as schema-validated JSON, matching the format the rest of the program already expects.
- The new portal runs alongside every other portal already in production, without a separate maintenance track.
This matters most for programs that need broad coverage rather than depth in any one system. A team using Deck’s bill-fetch capability to pull invoices across utility and vendor portals runs into this constantly: the twentieth provider rarely looks like the first, but it shouldn’t need twenty times the engineering effort to reach.
Why does this beat building a custom script for each new portal?
Custom scripts built with Selenium or Playwright get faster to write with practice, but each one is still tied to the specific page structure of the portal it was written against. Adding a new portal under this model means writing, testing, and maintaining a new script, and every portal already onboarded keeps its own script that can break independently. Deck resolves this because its agents don’t encode a specific portal’s layout into the automation itself, so the marginal cost of the next portal doesn’t scale with the number already running.
Traditional RPA tools like UiPath face the same wall from a different direction: a recorded bot is built against today’s screen, and onboarding a new application means a new recording session, new selectors, and new edge-case handling before it’s production-ready. Onboarding a new application into an RPA program takes days to weeks per application. Deck’s agents work from a plain-language task description against the portal’s current interface, which is why a new portal can often go from connected to running the same day it’s configured.
Waiting for the target system to publish an API is the slowest path of all, and it’s not really a path since the timeline isn’t in the automation team’s control at all. Deck sidesteps the wait by working with whatever interface the portal already exposes today.
| Approach | Cost of the next portal | What Deck does instead |
|---|---|---|
| Custom script (Selenium, Playwright) | A new script per portal, tied to that portal’s current layout | Deck uses one agent framework; no portal-specific script to write |
| Traditional RPA (UiPath) | Days to weeks per application: recording, selectors, edge cases | Deck works from a plain-language task description, often running the same day |
| Waiting for an API | Timeline set by the target system’s own roadmap, not the team’s | Deck works with the interface that already exists today, no wait required |
Where does onboarding speed actually matter?
Programs with broad portal coverage feel this the most: a bill-fetch deployment pulling invoices across dozens of utility and vendor portals, or a product integrations deployment connecting to whatever platform a customer happens to use. In both cases, the list of portals that need to be supported keeps growing after launch, and the cost of adding the next one determines whether coverage keeps pace with demand or falls behind it. Deck’s customer page has examples of teams that expanded portal coverage well past their original launch list without re-architecting the automation each time.
Straive’s research on choosing between AI agents and traditional automation makes a related point: a rigid rule-based system tends to demand constant hands-on upkeep as its coverage expands, while an approach that reads the interface directly absorbs more of that change on its own. That gap compounds specifically at the point where a program is trying to add its fifteenth or twentieth portal, not its second.
FAQs
How long does it typically take to add a new portal with Deck?
Adding a portal is a configuration task against that portal’s existing interface, not a custom integration build, so it’s commonly measured in hours or a single day rather than the multi-week timeline a custom script or RPA bot usually needs.
Does a new portal need its own custom code?
No. Deck’s agents interpret the portal’s interface at runtime, so the same underlying agent framework handles a new portal without a portal-specific script being written first.
Does onboarding speed hold up as the number of portals grows?
Yes. Because each portal’s agent definition doesn’t depend on how many other portals are already running, adding the fiftieth portal costs roughly the same as adding the fifth.
Is Deck a fit for a program that only needs to automate one or two systems?
It can be, but the speed advantage compounds most clearly for programs that expect to keep adding portals over time, since that’s where per-portal engineering cost usually becomes the bottleneck.
Ready to get started?
See how Deck can connect your product to any system — no APIs needed.
Build my Agent →