> Maybe a better question would be who are the target customers for this?

So far, our customers are software companies (and one brick and mortar company) in the fitness space. (That is to say, customers like ourselves: Perkville is such a company, a loyalty/rewards SaaS mostly in fitness.)

Long term, the target customers are any software companies that need to connect their product to a ton (hundreds or thousands) of different (large and small, diverse, needy) businesses.

> Or its more like a platform that manages user data and other services can use it as a store which executes a particular script when the state of the store changes?

You've anticipated a key differentiator: The data store. Other IPaaS systems don't keep around data that they've processed. They're entirely event driven. We needed the ability to look back in time (customers often want to do things like, oh, if it's the tenth gym check-in in a month, give the user some bonus points); we needed the ability to diff a new record against an old version of that record (customers often want to trigger rewards based on a membership status change for example); we needed the ability to bulk execute a workflow against a bunch of already stored data (we sometimes need to "back sync" a reward rule).

The visual scripts ("workflows") that our support team write are basically functions. How they get triggered is up to them. They can trigger a workflow automatically when a record is created or updated, or they can trigger them manually, or they can trigger them on a schedule, or they can trigger one from inside another. (On the roadmap is the ability to trigger a workflow from an API call, in a synchronous, atomic manner -- this is the final piece to totally replace Perkville's old hard coded integration system with Middle; automated point redemption.)

> Is it zapier but you can write a python script to automate a task?

So, as with Zapier, there are two halves of the app.

The first half is the "accounts" site. That's where all of a customer's own customers live, as separate accounts. Each account has workflows (this is the VPL), workflow triggers, a data store, and reporting screens. Python isn't written here. This is designed for our support team to go in and fulfill feature requests for customers.

The second half is the "developers" site. This is where programmers can create data sources and actions that then can be used on the account side. The goal here for us was to keep the interface as simple as possible. I wanted it so a programmer just needs to fill in a Python function, in an in-browser code editor. For a data source, they just need to handle, let's say, an input date range and an authentication dictionary, and then return (or yield ) records that match.

...

Hopefully that was informational? If you want to sign up for news, there's a sign-up form on our site: https://middle.app/