Apps in Amazon Quick vs. App Studio vs. a custom build

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

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: 1. 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 -> qsight: it is just a number on a screen
• quick -> qconn: identity propagated per connector
• quick -> qkv: app state
• appstudio -> asreg: data sovereignty blocker
• amplify -> ddb: data + authorization
• amplify -> cicd: controlled promotion

Decision matrix

Apps in Amazon Quick

Pros

• Near-zero marginal cost when the seats already exist
• Native Quick Sight embeds plus spaces and knowledge-base integration
• The process owner builds and iterates with no IT queue
• It is the strategic direction: BYOI pulls the Q Business index inside

Cons

• Seats are expensive for occasional users; $250/account floor on Pro and Enterprise
• RBAC/SSO and data sovereignty only appear on Enterprise
• Conversational iteration burns agent hours ($3/h overage)
• High exit cost: logic and state stay in the workspace

Verdict: Best choice when the population already holds Quick seats and the app is read-mostly.

AWS App Studio

Pros

• $0.25/user-hour is unbeatable for sporadic, long-tail usage
• Free builder environment and 250 free user-hours to trial
• Reach into 200+ AWS services and third parties via API/OpenAPI connectors

Cons

• Oregon and Ireland only, a non-starter for data that must stay in Brazil
• No new Regions since the November 2024 GA
• Needs a technical person driving, not business self-service

Verdict: Wins on cost per occasional user, loses on regional footprint and product trajectory.

Custom build (Amplify/AppSync)

Pros

• Diff, PR, test and rollback: audit evidence by construction
• Row-level entitlement and idempotency under your control
• Any Region, including sa-east-1; low exit cost

Cons

• Weeks of engineering competing with the product roadmap
• You inherit operations, patching and on-call for one more internal app

Verdict: Reserve it for anything that writes to a system of record or becomes regulated evidence.

Build no app (Quick Sight + Flows)

Pros

• Zero incremental cost and minimal risk surface
• Reuses dataset lineage and permissions that are already audited
• Ships in hours and dies painlessly when it stops being useful

Cons

• Covers neither data entry nor approval workflow
• Frustrates whoever asked for an "app" and got a chart

Verdict: The default option. Only leave it when there is real data entry or a real workflow.

"Respects your access policies", what that means and what it does not

That line from the announcement is true and insufficient. What the documentation describes is identity propagation at the connector boundary: the Salesforce or ServiceNow integration carries the user's identity, and what they cannot see there, they do not see here. That is good, and it is different from row-level entitlement inside the app. If the app joins Salesforce pipeline with warehouse cost and returns margin per customer, the authorization of that combined result is a new property no single connector guarantees.

The test I require before publishing is not functional, it is negative: take a user with no access to account X in the CRM, open the published app and prove they cannot see account X, not in the table, not in the total, not in the output of the inference block. Aggregates leak. Foundation-model summarisation leaks elegantly.

Then come the operational questions, worth more than any demo: is there a diff between today's version of the generated app and March's? Who approves promotion? What signal reaches CloudTrail and your SIEM when an action connector writes into a system of record? What is the failure behaviour of that connector, retry, idempotency, partial write?

And there is the licensing layer turning into an architectural constraint: the pricing page places RBAC/SSO and data sovereignty on Enterprise. In a regulated institution, identity federation is not optional, so the real price is not $20, it is $40 plus the $250 infrastructure fee. Decide the tier during architecture, not at renewal.

The real break-even is not technical: A $40 Enterprise seat equals 160 user-hours on App Studio, nearly a full working month inside the app. So, on a per-app basis, App Studio almost always wins on cost. Quick only wins when the seat was already bought for another reason (chat, research, BI). The platform decision therefore precedes the app decision: if Quick is already the company workspace, building outside it means paying twice. If it is not, one app does not justify adopting it.

How this goes wrong in production

• One-click publishing "to the entire organization" under a seat model, distribution becomes a cost event, not an adoption event.
• Treating the conversational app as a disposable spreadsheet, then discovering at close that a regulated number comes from an artefact with no version and no owner.
• Confusing connector-level identity propagation with authorization of the aggregated result, and never running the negative test.
• Enabling write-capable action connectors before defining retry, idempotency and the signal reaching the SIEM when the app mutates a system of record.
• Choosing App Studio for data that must stay in Brazil, ignoring that it exists only in Oregon and Ireland.
• Letting a hundred people iterate apps conversationally without knowing whether the included agent hours are per user or per account.

A Well-Architected reading

• security: Inherited identity is a starting point, not a conclusion. Require a negative test per persona, review write-capable action connectors as changes to a system of record, and treat the licence tier (RBAC/SSO on Enterprise) as a security requirement, not a procurement one.
• reliability: The app depends on third-party systems through connectors. Define the expected behaviour when Salesforce or ServiceNow degrades: visibly stale data, explicit failure, or queued writes with idempotency.

Three questions that always come up

Does this replace AWS App Studio?

Formally no: App Studio does not appear in the March 2026 service availability update and remains GA. In practice it has not gained a Region since November 2024 and still runs only in Oregon and Ireland, while Quick is receiving BYOI, Bedrock knowledge bases and now apps. I read that as investment direction and plan accordingly.

Can I build apps on the Free tier?

The announcement says app building is available to Plus, Professional and Enterprise starting September 1, 2026, while the pricing page lists "no-code apps" among Free features. The two pages are not aligned, confirm with your account team before planning a rollout on top of Free.

What is the first app I would let someone build?

One that only reads, has fewer than twenty named users, replaces an existing spreadsheet, and produces no number that enters an external report. If it survives a quarter of real usage, then I will discuss a write connector.

What I would do on Monday: I would not open app building to the whole company; I would open it to a two-process pilot with a named owner and a 90-day review date. The lesson that cost me came from elsewhere: at a bank we killed a critical spreadsheet by replacing it with a better internal tool, and six months later found the risk team back on the spreadsheet, because the tool could not show how March's number had been calculated. The ability to reproduce the past is worth more than the speed of building the present. So my bar for any conversational app is a single question: if the auditor asks for the difference between today's version and the one from three months ago, can I show it? If the answer is no, the app may exist, but it cannot be the source of an official number.

Recommendation

If your company already pays for Amazon Quick seats, Apps in Quick is the right choice for read-mostly apps: near-zero marginal cost, Quick Sight embeds, identity already handled at the connector boundary, and alignment with where the product is going (BYOI, Bedrock knowledge bases). If you are not a subscriber, one app does not justify $40/user plus $250/account: App Studio delivers the same outcome at $0.25 per user-hour: provided the data can live in Oregon or Ireland, which rules out a good share of regulated Brazilian cases. For anything that writes to a system of record or backs an externally reported number, stay with the custom build: you are buying diff, rollback and evidence, not technology. And before all of that, test the cheap hypothesis, half these requests die with a Quick Sight dashboard and a Quick Flow, and that is the most elegant architecture of the four.

Rating: Adote com piloto controlado / Adopt with

References

• AWS What's New: Amazon Quick now lets you build custom apps with natural language (Sep 1, 2026)
• Amazon Quick User Guide: Build web applications with apps in Amazon Quick
• Amazon Quick User Guide: Work with integrations (action connectors, knowledge bases, BYOI)
• Amazon Quick: Pricing (Free / Plus / Professional / Enterprise, agent hours, index storage)
• AWS App Studio: Pricing ($0.25 per user hour, free builder environment)
• AWS App Studio: FAQs (target users, Regions, connectors)
• AWS Service Availability Updates (March 31, 2026), services moving to maintenance

Originally published at fernando.moretes.com. By Fernando F. Azevedo: Senior Solutions Architect.