$ cat ./for-product-teams.md
ship automation as a feature.
not a 6-quarter platform.
your PMs already know workflow automation is the sticky moat. Flowget lets your team ship the feature — without staffing the team that builds the platform underneath.
weeks, not quarters.
the orchestrator, the queue, the durable state machine, the audit hooks — already shipped. the visual builder and AI authoring agent are in alpha. your engineers add typed TypeScript functions to a catalog; you ship the feature.
metered usage, wire it once.
opt-in per-node cost on successful executions — LLM tokens, API calls, compute, storage. the cost event feeds straight into metered billing — Stripe metered, Lago, Orb — you subscribe once and forward, no bespoke metering pipeline. or hide costs entirely — your call.
the moat compounds.
customer-authored workflows are switching costs. every automation your customer builds inside your product is one they don't want to rebuild somewhere else. and because the agent (in alpha) composes from your catalog, the value of your integrations compounds with the depth of your catalog.
answer 'where does the data live?'
your customer's data never leaves your VPC. GDPR, HIPAA, regional regulators — they all care where data sits. with BYO worker you answer "in your VPC" — and, with the payload codec wired, encrypted on the wire — and you land enterprise procurement instead of bouncing off it.
the shape of a launch
what shifts when your customers describe the workflow and your engineers ship the catalog
- before: every integration ask becomes a roadmap item. eng quotes 6–8 weeks. half of them die before they reach beta.
- after: the agent (in alpha) composes the workflow from your catalog in chat. you ship integrations by adding nodes to the catalog, not by writing one-off product surfaces.
- side effect: the per-node cost event is emitted from launch — forward it to Stripe, Lago, or Orb and usage shows up as a per-execution line item, no bespoke metering pipeline to build.
- and the moat: every workflow your customer builds is anchored to your catalog. moving off your product means rebuilding their automations from scratch.
where flowget loses
we will lose to a better-suited tool if any of these are true.
- you want a Zapier-killer for internal ops. Flowget exists to be embedded in the product you sell. if there's no end-customer in the picture and your team just needs to glue SaaS APIs together, Zapier or n8n will be cheaper and faster.
- your automation doesn't touch customer data. the whole architecture is built around "data stays in your VPC." if your workflows only move data between vendor APIs you already own end-to-end, you're paying for a boundary you don't need.
- you already operate a platform team. we're the team you would have hired. if you've already got engineers shipping the queue, the orchestrator, the billing layer, the audit trail — our pitch collapses to "AI authoring on top," which is useful but not a category bet.
automation that lives inside your product.
not next to it.
small cohort, onboarded by hand. tell us what we're shipping together and we'll start the conversation.