[ayewo]

I thought I understood what you do but with your itemized example, I'm somewhat confused.

1. OK

2. Dev uses the `airplane` CLI as opposed to running `npm`, `python` etc locally?

3. Dev runs `airplane deploy` as opposed to deploying to Heroku?

I think it would be nicer for us if you explained your value proposition in terms of what tools/steps I'd be replacing if I choose to adopt Airplane.

[raviparikh]

To add on to what Josh said, the main value of Airplane is that we automate a lot of things that would normally require you to write a lot more additional code. So for example, if you build an admin panel using Airplane instead of doing so from scratch, we'll provide the following for you:

* A rich React component library that's optimized for internal tooling (tables, charts, etc) * Permissions, audit logs, and approval flows that are easily configurable * Integrations into various systems that an internal tool would normally have to integrate with (e.g. identity providers like Okta, Slack for notifications, etc)

So if you'd expect building that admin panel to take a few days or weeks of work, ideally with Airplane we can reduce that down to a few hours instead.

[sjcoles]

Part of what bothers me with the current webdev approach is irreducible complexity.

How many layers of 'magic' to facilitate devs deploying do we really need and is it wise to depend on so many?

[joshma]

2 - correct, depending on the task type we still call through to node etc. But the CLI also provides a dev UI and other niceties specific to Airplane.

3 - correct, the code is built and pushed to us, similar to Heroku.

Our value prop ultimately is that 1) you can build tools like admin dashboards, data migration scripts, one off devops operations, etc, into production grade web apps and 2) you can do this using code!