[adameasterling]

So, we aren't quite ready to show screencaps (or other marketing material) to the whole world just yet. But I'll for sure make an HN post when that changes.

If you're cool with a text description though:

Basically, the core emotional impetus of this project for me begins with unfulfilled product enhancements for Perkville. Like, imagine a random 1-location Yoga studio wants to award bonus points on a member's 1 year anniversary. Sounds easy, right?

Well, saying "yes" to that customer means significant coding time, to store and update the membership start date, to handle edge case logic, to update all existing integrations to store the start date (and membership systems all store that in different ways, sometimes really obtuse and complicated ways), and then we need to build out interfaces for setting up the bonus. And what if a business wanted to award on the 6th month anniversary and not annually? Or for only certain membership types? And we need to QA, and add unit tests, and do code reviews, and on and on.

And we have hundreds of requests like that in the queue, with more coming in all the time. It's... too much.

Me and my engineers felt buried, for one. And our customers get unhappy too, that we just can't deliver fast enough for them. I really, really hate disappointing a customer. It hurts me, that this rewards platform we've been working on for years isn't doing what they want it to do. That we can't keep up with their imagination.

So, that was my emotional state 3 years ago when I sat my own boss down, and the product manager at the time, and was like, look, you need to let me solve this problem in a different way. We can't productize every single request that comes down. We need to figure out a way to build features for customers in a much more flexible way.

We looked at a bunch of tools in this space, like Zapier for example. But none of the tools were good enough. Zapier doesn't have the integrations we need (how long has their MindBody integration been in "in construction"?) and besides, it doesn't have the two-tier tenancy that we need. (We need to keep our customer's data all separate from each-other, with the ability to handle GDPR stuff on it as well.) And Zapier's (and all the others) tools for support really suck. You can't look up a user and see all the logic that's been executed for them. (People write into support all the time asking about their points.) Oh and on top of all that, the developer portal in Zapier really is not great. You have to download their SDK, become intimately familiar with it, and it is real complicated. (To their credit I think they've worked on this.) OH -- and Zapier is crazy expensive at the scale we need. We push a lot of events, and my estimate for putting everyone on Zapier came up to some insane number, like 50% of our revenue.

So, we decided. Let's just build our own and solve all of those problems. And so... we did. We got a v1 out pretty quick. We're able to hammer out integrations and updates to those integrations very quickly. Support can make features that we used to need engineering help on. There's still a ton of work to be done, but it's doing well enough that we've snagged some significant customers in the Fitness space. And it's really worked out for Perkville.

Anyways, that was quite the essay. That's the product. We're excited about it.

[tiuPapa]

So I am still confused with the connectors and connections bit. Is it zapier but you can write a python script to automate a task? 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? Maybe a better question would be who are the target customers for this?

[adameasterling]

Going backwards in the questions here:

> 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/

[tiuPapa]

That was pretty informational. Thanks for the detailed explanation. Sounds really cool.

[jmatthews]

That is excellent. I've had to tackle a similar issue at my current place, except I am chaining long data pipelines with external repositories together. My solve was an api gateway that was verbose but highly configurable.

I wonder if you've felt the pressure of implementing or embedding a scripting language client side? You're already developing a DSL, whether it's text or graphical is not 100% the point.

[adameasterling]

Nice!

> I wonder if you've felt the pressure of implementing or embedding a scripting language client side? You're already developing a DSL, whether it's text or graphical is not 100% the point

So, yes.

Right now, there's a clear division of labor: Python goes in the "developer" half of the app, and is used to make data sources or "steps" that can be used in the VPL.

The visual scripting language only exists in the "account" side of the app.

So far, this division of labor is working, but we have encountered a few times where it would be convenient to just put Python code directly into the account side of the app.

About the part where you said, "whether it's text or graphical is not 100% the point" - I do think a graphical scripting interface is absolutely key, actually. Sometimes I forget how much of a wall an actual programming language is for folks. I've been blown away by how productive our support staff has been in our VPL.