loading...
When ads stop working, the overlooked fix is browser-automation reselling – letting others distribute what you built through channels you'd never reach alone.
ENTRY ANGLES
Embed churn-reduction functionality into existing cloud products developers already use · Build revenue-expansion services that integrate into host products without being core functionality · Create embedded products that compete against custom build-from-scratch solutions
VERTICALS
CAPABILITIES
Understanding of cloud product ecosystems and developer workflows, Ability to identify genuine functionality gaps in established platforms, Integration and embedding technology expertise
Automating workflows that people currently execute manually on computers is a major trend. Within that trend, one approach involves tools that "sit on top of" existing platforms and simulate human behavior. Technologically, there are two main routes. Calling a platform's API is the cleaner approach – Zapier is the canonical example – but it requires the platform to expose a suitable API. When it doesn't, the alternative is mimicking a user: automatically moving the mouse, clicking, and typing in the UI. That approach spawned its own product category, Robotic Process Automation (RPA), with UiPath as the best-known tool.
The technical approach matters less than a more fundamental point: these automation tools have traditionally been standalone products, purpose-built for automation and distributed separately.
Estonian startup Askel decided to break that convention. It built a process automation platform that third-party developers can embed directly inside their own cloud products.
Once the functionality is in place, users of that cloud product can create multi-step automated workflows and execute them with a single click – no more walking through each step manually.
Askel put particular emphasis on making this accessible to non-technical users. Workflows can be built in a visual, drag-and-drop interface, or by describing the desired steps in plain language, which an embedded AI model then interprets and structures.
For developers integrating the platform, the setup is intentionally lightweight: two steps. First, upload your API spec along with authentication methods. Second, mark which API calls you want to expose to your users.
After that, those endpoints appear as pre-built components in the Askel visual builder – and users can start assembling their own automation workflows on the spot.
In practice, Askel prepares the entire automation UI. The developer's job is to populate it with their own API calls, instructions, and workflow templates – making it easier for end users to get started quickly.
Askel's thesis: embedding automation directly into a cloud product increases how effectively customers use it, which in turn lowers the probability they'll switch to a competitor.
Some industry analysts have argued that embedded automation should be a standard feature of every cloud product by 2025. If that's right, every SaaS developer will be looking for a faster path to it than building from scratch – which is exactly the proposition Askel is selling.
Early investors believed it: Askel raised an initial €380,000 at pre-seed.
Interestingly, Askel originally planned to go the conventional route. Its first version was a standalone automation tool that sat on top of other platforms – think automatically pulling a new contact from Salesforce, grabbing their email from HubSpot, generating an invoice in SAP, sending that invoice via Outlook, then pinging the sales rep in Slack.
The platform's intended differentiation was simplicity for non-technical users, with a visual builder and plain-language input.
But the founders apparently concluded that competing in the crowded standalone automation tool market was an uphill battle. So they adapted the same platform to be embedded inside other cloud products – automating sequences of actions within a specific service, not across many different ones.
Crucially, the automation becomes part of the host product rather than a separate thing users need to discover, install, and manage on their own.
That pivot reflects a broader shift toward embedded products – standalone-capable functionality that's intentionally distributed only through third-party integrations.
Buster ([reviewed here](/review/vsjo-budet-eshhjo-kruche)) took the same approach in analytics. Buster entered Y Combinator last December with a full-featured analytics platform described as comparable in functionality to Tableau – but designed exclusively for embedding inside other cloud products. Developers who want to give their users powerful data analysis tools can integrate Buster instead of building from scratch, at $599/month for 500 queries plus $10 per additional 50 queries, with unlimited end users. Volume pricing exists for larger-scale deployments.
Layer ([covered here](/review/kak-bystro-poluchit-100-tysjach-tjoplyh-klientov)), with $2.3 million raised, took the embedded approach to accounting – building a bookkeeping platform for small and mid-sized businesses that's distributed only through integration partners. Developers of other SMB tools embed Layer's accounting; their users get the functionality natively, and developers earn a revenue share alongside Layer.
Uprise ([reviewed here](/review/vygodnee-ne-iskat-klientov-samomu)), with $4.7 million raised, did the same for financial advisory services – a marketplace of financial advisors for small businesses, distributed only through embedding in other SMB cloud tools. Revenue is shared among the advisors, Uprise, and the developers who embed the marketplace.
Worth noting: these embedded platforms aren't just added tabs inside host products. They expose APIs that let developers weave specific functionality directly into their core workflows. A Shopify-style store builder that embeds an accounting platform, for instance, can automatically post a ledger entry after each sale and adjust inventory in real time – no manual export-import cycle required.
The broad opportunity direction: build embedded products rather than standalone ones.
The key is identifying which cloud product developers genuinely need additional functionality for – and why.
Adoption is typically driven by one of two motivations. Churn reduction: give existing users more reasons to stay – Askel and Buster both make this pitch, letting developers compare building equivalent functionality from scratch against integrating a ready-made platform. Revenue expansion: offer users a valuable service they'll pay for even if it's not central to the host product's core function – Layer and Uprise operate in this lane.
So – what would you embed, into which product, and why?