Every company I have worked with carries the same invisible debt: somewhere between thirty and three hundred spreadsheets nobody versions, fed by manual exports from four different systems, and yet feeding credit decisions, capacity plans and the monthly close.
The September 1, 2026 announcement — building apps in Amazon Quick by describing them in natural language — aims squarely at that debt.
The risk is trading an ungoverned spreadsheet for an ungoverned app, now with a write connector and an AWS invoice attached.
So I did not write a feature review: I wrote the bake-off I would run before approving the first app, across the four routes that genuinely compete for this work.
What the September 1 GA actually ships The Apps in Quick documentation says more than the announcement does.
Seven capabilities matter architecturally: conversational authoring (the agent writes the code while you watch), live Quick Sight visual embeds inside the app, action connectors that call external APIs, built-in foundation-model inference for summarisation and classification, reading documents from spaces, persistent key-value storage across sessions, and one-click publishing under Quick's SSO.
Read that combination again: action connectors plus persistent key-value storage.
This is not a prettier dashboard.
It is an application with its own state and a write path into third-party systems, authored by conversation and published with one click.
In a financial-grade environment, that is precisely the class of artefact a change board expects to see with an owner, a version and a rollback.
Positioning matters too.
Quick is the agentic-workspace evolution of QuickSight, and the docs already offer BYOI — Bring Your Own Amazon Q Business Index plus attaching managed Bedrock knowledge bases.
AWS is stitching the Q Business index and Bedrock knowledge into Quick.
If your company has invested in either, the lowest-friction route now runs through Quick — and that weighs more in the decision than any "minutes to first app" benchmark.
The four routes that actually compete Comparing Apps in Quick against "low-code" in the abstract helps nobody.
In practice, when someone asks me for an internal tracker, there are four possible destinations.
Apps in Amazon Quick.
Authored by the business user, inside the workspace where they already chat, research and consume BI.
Seat-based pricing.
Available to Plus, Professional and Enterprise since September 1,
2026.
AWS App Studio.
AWS's other natural-language builder, GA since November 2024, aimed at the "technical professional" — IT project manager, data engineer, architect.
Connects to 200+ AWS services and to third parties through API/OpenAPI connectors.
Charges $0.25 per user-hour of the published app; the builder environment is free.
A custom build.
Amplify/AppSync + Lambda + DynamoDB + Cognito, code in a repo, PRs, tests, pipeline.
Expensive in engineering, cheap in audit.
No app at all.
A Quick Sight dashboard plus a Quick Flow.
Half the "internal app" requests I receive are really one number on a screen and an email fired when it crosses a threshold.
That route has to be on the table, or the comparison degenerates into a contest between builders when the right answer was to not build.
Head-to-head: the dimensions that decide Criterion Apps in Amazon Quick AWS App Studio Custom build No app (Quick Sight + Flows) Who builds it The business user, conversationally Technical professional (IT, data, architecture) An engineering team with a backlog and priorities A BI analyst, in hours rather than weeks Billing unit Seat/month ($20 Plus and Pro; $40 Enterprise) $0.25 per user-hour of the published app Service consumption plus engineering cost Already covered by the existing Quick seat Fixed floor $250/account/month infrastructure fee on Pro and Enterprise None; the builder environment is free Low on services, high on people No additional floor Where the code lives Generated and hosted inside Quick Generated and operated by App Studio In your Git, with diff and rollback There is no application code Identity and authorization Inherited from Quick; RBAC/SSO listed as Enterprise-tier App Studio's own model layered over connectors Cognito/IAM with row-level entitlement if you write it Quick Sight dataset rules, already audited Writes into a system of record Yes, via conversationally authored action connectors Yes, via API/OpenAPI connectors Yes, with idempotency and retry you control No; read and notify only Audit evidence To be confirmed: diff between generated app versions Builder versioning, no repository of your own Commit, PR, pipeline — evidence by construction Dataset lineage; minimal surface Regional footprint Follows the Quick subscription Region US West (Oregon) and Europe (Ireland) only Any Region, including sa-east-1 Follows the Quick subscription Region Time to v1 Minutes, by the process owner Hours to days, with a technical person driving Weeks, competing with the roadmap Hours Exit cost High: logic and state locked to the workspace High: no portable artefact of the app Low: it is your code Low: SQL and datasets are portable The arithmetic almost nobody runs: seat versus user-hour The two AWS routes bill in incomparable units, and that is where the decision becomes FinOps.
A Quick Enterprise seat costs $40/user/month; App Studio charges $0.25 per user-hour.
The break-even is plain arithmetic: $40 ÷ $0.25 = 160 user-hours per month.
A full working month is roughly 168 hours.
So if the app is the only reason to buy the seat, App Studio only loses when the person lives inside the app full time.
The realistic scenario is the opposite.
Forty occasional users at 3 hours a month each: 120 user-hours — $30/month on App Studio.
The same forty on Enterprise cost 40 × 40 plus the $250 infrastructure fee = $1,850/month, or $22.2k a year.
Sixty times more for the same app.
Now invert it: if 250 users already hold Quick seats because they use chat, research and BI, the marginal cost of the app trends to zero and App Studio becomes a new line on the invoice.
The right question is not which service is cheaper — it is whether the seat is already bought.
Two hidden details.
First, the $250/account/month fee on Professional and Enterprise is a floor: at 10 users the effective rate jumps to $65/user.
Second, the pricing page meters agent hours — 4 h/month on Professional, 8 h on Enterprise, $3 per overage agent hour.
Iterating an app by conversation consumes exactly that resource.
Confirm with your account team whether those hours are per user or per account before turning a hundred people loose to "describe whatever they want".
Triage: three questions before you pick a builder The common mistake is starting from the tool.
I start from what the app actually does — writes, evidence and usage profile — and let the tool fall out of the three answers. 🧭 Triagem / Triage Escreve no SoR? / Writes to SoR?
Salesforce, ServiceNow, ERP (security) Vira evidência? / Regulated evidence? fechamento, risco, auditoria (security) Usuários × horas / Users × hours break-even: 160 h/user/month (compute) 🟧 Apps in Amazon Quick — seat-based Apps in Quick conversational authoring, 1-click publish (ai) Action connectors + knowledge bases MCP, S3, Drive, OneDrive (external) Key-value storage state across sessions (storage) 🟦 AWS App Studio — user-hour App Studio $0.25 / user-hour (compute) Oregon + Ireland only no sa-east-1 (network) 🟩 Custom build — engineering owns it Amplify / AppSync + Lambda code in Git, PR, tests (frontend) DynamoDB + Cognito row-level entitlement (data) CI/CD pipeline diff, rollback, evidence (ci) 📊 No app — the cheapest route Quick Sight + Quick Flows dashboard + automation (data) Flows req -> q1:
- nature of the action q1 -> q2: read-only q1 -> amplify: writes to SoR → engineering q2 -> q3: not regulated evidence q2 -> cicd: is evidence → needs diff and rollback q3 -> quick: users already hold Quick seats q3 -> appstudio: many occasional users q3 ->