DEV Community: Shruti Saraswat

Passkey rollout decision: 6 checks before replacing password-first sign-in

Shruti Saraswat — Wed, 15 Jul 2026 06:47:02 +0000

Passkeys are no longer a distant authentication idea.

Users are seeing them in mobile apps, browsers, password managers, enterprise tools, and consumer platforms. Identity providers are improving the settings that make passkey behavior more predictable across devices and ecosystems.

That does not mean every SaaS product should remove passwords immediately.

The better decision is more practical:

Where should passkeys sit in the sign-in flow, and what fallback should remain when they do not work for a user?

That is the useful signal from Keycloak 26.7.0.

What changed

Keycloak 26.7.0 added better passkey compatibility through new WebAuthn policy options.

The important change is the new Discoverable credential setting.

Instead of the older yes-or-no style option, Keycloak now supports values that match the current WebAuthn specification:

required
preferred
discouraged

This matters because passkeys depend on the server telling the browser whether it wants a discoverable credential, which is often stored on the user’s device or password manager.

Keycloak says this improves compatibility with passkey providers such as iCloud Keychain, Google Password Manager, and 1Password.

The older Require Discoverable Credential option is now deprecated and planned for removal in a future release.

This is a technical change, but the product consequence is bigger:

Passkey rollout is becoming less about whether the technology exists and more about how carefully the product handles the transition.

Why this matters for SaaS teams

Authentication is not only a security layer.

It is part of the product experience.

If sign-in is too weak, the product carries security risk.

If sign-in is too difficult, users abandon the workflow, contact support, or create account recovery problems.

Passkeys can improve phishing resistance and reduce password friction. But they also introduce product questions that teams should answer before making them the default.

A user may be on a shared device.

A customer may use an enterprise password manager.

A team member may lose access to a device.

A browser may not support the same flow.

An admin may need to recover access for a user.

A legacy customer may still rely on password plus MFA.

So the decision is not simply:

Should we support passkeys?

The better question is:

How do we introduce passkeys without breaking access, trust, or support workflows?

The 6-check passkey rollout decision

1. User fit

Start with who uses the product.

A passkey rollout for a consumer mobile app is different from a rollout for an enterprise SaaS product, internal admin portal, developer tool, or healthcare platform.

Ask:

Are users mostly on personal devices?
Do they use managed corporate devices?
Do they switch devices often?
Do admins need centralized recovery?
Are users technical or nontechnical?
Are accounts shared by teams?

Passkeys work best when the product understands the user context.

2. Compatibility path

Passkey behavior depends on the browser, device, identity provider, password manager, and WebAuthn settings.

A product team should test common environments before rollout:

iOS and macOS
Android
Windows
Chrome
Safari
Edge
Google Password Manager
iCloud Keychain
1Password or enterprise password managers

The point is not to test every possible setup.

The point is to avoid treating one successful flow as proof that the rollout is ready for all users.

3. Fallback and recovery

This is the most important product question.

What happens when passkey sign-in fails?

A safe rollout should define:

backup authentication method,
account recovery flow,
admin-assisted recovery,
lost-device handling,
new-device setup,
support escalation,
and identity verification steps.

A passkey feature is incomplete without recovery.

Users do not only judge authentication when it works. They judge it when they are locked out.

4. Rollout sequence

Passkeys do not need to replace passwords in one step.

A staged rollout can reduce risk:

Offer passkeys as an optional sign-in method.
Encourage enrollment after successful login.
Make passkeys the preferred method for lower-risk accounts.
Require passkeys for admins or high-risk roles.
Phase down passwords only after recovery and support data are strong.

The rollout should match risk and user readiness.

5. Security policy

Passkeys can reduce phishing risk, but they still need policy decisions.

Teams should decide:

which roles require passkeys,
whether passkeys replace or complement MFA,
what happens for shared accounts,
how admin accounts are protected,
whether device-bound or synced passkeys are allowed,
and how suspicious sign-in attempts are handled.

The security policy should be clear enough for product, support, and customer success teams to explain.

6. Measurement

Teams should measure passkey rollout like a product change, not only a security setting.

Useful metrics include:

passkey enrollment rate,
successful passkey sign-ins,
failed sign-in attempts,
account recovery requests,
password reset volume,
support tickets,
user drop-off during sign-in,
admin adoption,
and risky login patterns.

If passkeys reduce security risk but increase lockouts, the rollout needs adjustment.

When to move now

A SaaS product should consider moving now when:

users already use modern devices and browsers,
account security matters,
phishing risk is meaningful,
support can handle recovery,
the identity provider supports proper WebAuthn settings,
and the product can roll out gradually.

This is especially relevant for admin portals, financial workflows, developer tools, internal systems, customer dashboards, and high-value accounts.

When to move more carefully

Teams should slow down when:

many users share accounts,
recovery is weak,
mobile and desktop flows differ too much,
support teams are not prepared,
enterprise customers require specific identity policies,
or legacy authentication is deeply tied into the product.

Moving carefully does not mean ignoring passkeys.

It means introducing them with the right fallback and support model.

A simple rollout plan

A practical rollout can start like this:

Phase 1: Optional enrollment

Let users add a passkey after a successful password login.

Use this phase to test compatibility and support load.

Phase 2: Preferred sign-in

Promote passkeys on the login screen and reduce password reliance for users who enroll.

Measure completion rate and recovery friction.

Phase 3: Required for sensitive roles

Require passkeys for admins, finance roles, security roles, or high-risk workflows.

Keep a strong recovery path.

Phase 4: Password reduction

Only reduce password-first sign-in after the team has enough data on adoption, recovery, support, and customer readiness.

Founder takeaway

Passkeys are becoming more practical.

But the product decision is not only “turn them on.”

The decision is:

who should use them first,
which devices and providers must work,
what fallback remains,
who owns recovery,
and what data proves the rollout is working.

A stronger sign-in method should not create a weaker access experience.

The right passkey rollout improves security and keeps users able to complete the product workflow.

Sources

When a security issue becomes a cloud bill: 6 checks for compute hijacking

Shruti Saraswat — Tue, 14 Jul 2026 10:26:37 +0000

A cloud security issue does not always start by taking a product offline.

Sometimes it starts by spending money.

A compromised workload can run unwanted compute. A stolen role can change cloud resources. A modified container can inherit permissions the original workload already had. A public-facing service can become the entry point into a wider cloud environment.

That is why AWS’s June 2026 Threat Technique Catalog update matters.

AWS added and updated techniques around Amazon EKS, organization-level trust, and compute hijacking. One of the clearest cost signals is compute hijacking in EKS, where attackers deploy cryptocurrency mining or other compute-heavy workloads inside compromised clusters, consuming customer resources and creating unexpected cost.

For SaaS and software teams, the important point is simple:

Security cost is not only incident response. It can also be unauthorized cloud usage.

What changed

AWS’s June 2026 Threat Technique Catalog update highlights several patterns that security teams should review.

The update includes EKS workload modification, public-facing application exploitation in EKS, assume root into organization member accounts, EKS compute hijacking, and unknown organization invitations.

These are different techniques, but they share one important pattern:

The attacker often works through functionality that looks normal from a distance.

A workload modification may change an existing pod instead of creating a new obvious resource. A role assumption may use cloud trust relationships that already exist. Compute hijacking may run inside a cluster where workloads are expected to run.

That makes context important.

The question is not only whether something happened.

It is whether the action fits the expected workload, identity, timing, and cost pattern.

Why compute hijacking deserves attention

Compute hijacking is easy to underestimate because it may first appear as a usage spike.

The product may still function. Customers may not notice immediately. The infrastructure may not look broken. But the cloud bill, cluster capacity, and security posture can all be affected.

In Kubernetes and EKS environments, the risk can become more serious when:

workloads have too many permissions,
namespaces lack resource quotas,
container images are not verified,
public-facing services are exposed too broadly,
runtime behavior is not monitored,
Kubernetes audit logs are not reviewed,
and service accounts can reach sensitive cloud resources.

A single compromised workload can create more than one problem.

It may consume compute, open paths to cloud credentials, affect cluster performance, and trigger investigation work across engineering, security, finance, and product teams.

The hidden cost is not only the extra compute

The extra compute charge is visible.

The full cost can be wider.

A compute hijacking event can create cost in several places:

cloud spend from unauthorized workloads,
engineering time to investigate,
product disruption if cluster resources are consumed,
emergency infrastructure changes,
delayed roadmap work,
security tool tuning,
access reviews,
customer communication if service quality is affected,
and future prevention work.

That is why the useful metric is not only the unexpected bill.

It is the total cost of finding, stopping, explaining, and preventing the issue.

The 6-check compute hijacking playbook

1. Check workload identity

Start with the identity attached to the workload.

In Kubernetes, service accounts and IAM roles can quietly define what a workload can reach. If a compromised pod inherits a broad service account, the attacker may gain access to more than the container itself.

Review:

which service account each workload uses,
what IAM role is attached,
whether permissions are broader than needed,
whether sensitive workloads share identities,
and whether role assumption patterns are monitored.

A workload should not carry permissions it does not need.

Readiness question:

If this workload were compromised, what could its identity access?

2. Watch workload changes

AWS highlighted EKS workload modification as a technique where attackers alter existing workloads by changing images, injecting sidecars, or modifying pod specifications.

That matters because nothing new may appear in an obvious way.

The workload already exists.

The change is what matters.

Teams should monitor:

pod spec changes,
image changes,
sidecar additions,
deployment modifications,
unexpected namespace activity,
unsigned or unapproved images,
and changes made by unusual principals.

If the team only watches for new resources, it may miss important modifications.

Readiness question:

Would we notice if a running workload changed in a way the product team did not approve?

3. Set resource boundaries

Compute hijacking becomes more expensive when workloads can consume too much capacity.

Resource quotas and limit ranges help reduce the blast radius.

They are not a complete security control, but they can stop one compromised workload from consuming more cluster resources than expected.

Review:

namespace quotas,
CPU and memory limits,
GPU limits where relevant,
autoscaling behavior,
node pool boundaries,
and alerts for unusual compute consumption.

The goal is not to slow the product team.

The goal is to make unexpected compute usage easier to detect and contain.

Readiness question:

Can one compromised workload consume far more capacity than it should?

4. Restrict image sources

Attackers may use legitimate-looking container images from public registries.

That means image scanning alone may not be enough.

Teams should decide which registries and image sources are allowed for production workloads.

Useful controls include:

approved registry lists,
signed images,
admission policies,
deployment review rules,
and alerts for unknown image sources.

If any public image can be pulled into a sensitive namespace, the cluster has a wider exposure surface.

Readiness question:

Can production workloads pull unapproved images?

5. Monitor cost as a security signal

Cloud cost monitoring is often treated as finance or FinOps work.

For compute hijacking, it becomes a security signal.

A sudden spike in compute usage, GPU use, node scaling, container restarts, or unusual workload duration can indicate more than ordinary traffic growth.

Security and cloud teams should share visibility into:

spend anomalies,
cluster utilization spikes,
new high-consumption workloads,
unexpected GPU usage,
unusual namespace-level cost,
and cost changes outside deployment windows.

A cloud bill can become an early warning signal.

Readiness question:

Would security teams see unusual compute spend quickly enough to act?

6. Define containment ownership

Finding unauthorized compute is not enough.

The response path should be clear before the issue happens.

A good runbook should answer:

who receives the alert,
who can isolate the workload,
who can revoke the role,
who can check cluster logs,
who can review cost impact,
who can restore the expected deployment,
and who updates prevention rules afterward.

This matters because compute hijacking crosses teams.

Security may find it. Platform may contain it. Product may see customer impact. Finance may notice the bill. Leadership may ask why usage changed.

The handoff should not be discovered during the incident.

Readiness question:

If unauthorized compute appeared today, who would stop it first?

A simple response workflow

When compute hijacking is suspected, use a clear order.

First 15 minutes

Identify the affected workload.
Check the service account and IAM role.
Stop or isolate the unauthorized workload.
Preserve enough logs for investigation.
Check whether the workload changed image, command, sidecar, or pod specification.
Review immediate cost and capacity impact.

First hour

Check Kubernetes audit logs.
Check AWS CloudTrail for related identity activity.
Review EKS, ECS, or container runtime alerts.
Look for related workloads in other namespaces.
Confirm whether credentials or tokens were accessed.
Notify the owning team.
Decide whether customer impact exists.

After containment

Tighten workload permissions.
Add or update resource quotas.
Review allowed image sources.
Strengthen admission controls.
Improve cost anomaly alerts.
Update the runbook.
Review whether similar workloads have the same weakness.

What founders should take from this

A founder does not need to manage every Kubernetes setting personally.

But they should understand the business pattern.

When cloud workloads are compromised, the impact may appear as cost, capacity loss, slower product paths, delayed delivery, or incident work before it becomes a full outage.

That is why cloud security and cloud economics should not be separated too cleanly.

A compute hijacking event asks both questions:

Who got access?

and

What did that access spend, change, or consume?

The strongest teams connect security monitoring, cost monitoring, workload ownership, and response ownership.

That is how an unexpected cloud bill becomes a fast investigation, not a long mystery.

Sources

GitHub secret scanning public monitoring: 7 checks for secret leaks outside your repos

Shruti Saraswat — Mon, 13 Jul 2026 07:16:40 +0000

Most secret-scanning programs start with the repositories a company owns.

That is a sensible starting point.

But it is not the full exposure surface anymore.

A company secret can appear in a personal fork. It can be pasted into a public issue. It can show up in a pull request comment. It can be committed by someone using a work email outside the company’s organization. It can be exposed during open source collaboration, debugging, support, or rushed incident work.

That is why GitHub’s Secret Scanning Public Monitoring matters.

The update points to a larger security lesson for software teams:

Secret exposure should be monitored by identity and ownership, not only by repository boundary.

What changed

On July 1, 2026, GitHub announced Secret Scanning Public Monitoring for enterprises.

GitHub says the feature monitors the public surface of github.com for leaked secrets and attributes findings back to an enterprise. The attribution can happen through two main routes:

Enterprise membership: the committer belongs to the enterprise.
Verified domain matching: the committer email matches a domain verified by the enterprise, even if the account is not directly linked to the enterprise.

GitHub says the feature covers public content across github.com, including git content, pull request comments, and GitHub issues.

GitHub Docs also explain that public monitoring is available for GitHub Enterprise Cloud customers with GitHub Advanced Security or GitHub Secret Protection enabled. The docs state that it is not available for GitHub Enterprise Cloud with data residency at the moment.

The practical point is simple:

GitHub is helping security teams see leaked credentials that appear outside the repositories they directly own.

Why this matters

A secret is not harmless because it leaked outside the company repository.

If the credential still opens a useful system, the business risk remains.

That risk can include:

cloud access,
database access,
third-party API access,
production service tokens,
package registry credentials,
internal tools,
CI/CD access,
customer data workflows,
or AI service keys.

For SaaS teams, the important boundary is not “where was the secret leaked?”

The important boundary is:

What can this credential access, and who owns the response?

That is where secret exposure becomes an operating problem, not just a code-scanning problem.

The 7-check secret exposure playbook

1. Check owned repositories first

This is still the base layer.

Teams should scan their owned repositories, full git history, branches, pull requests, and protected repositories for exposed secrets.

A secret committed once and deleted later can still remain in history.

A readiness check should answer:

Are all active repositories scanned?
Is history included?
Are pull requests checked?
Are test and internal repositories included?
Are alerts routed to someone who can act?

Repository scanning is necessary, but it should not be the only line of visibility.

2. Watch public GitHub surfaces

Secrets often appear in collaboration spaces, not only in committed code.

That includes:

public issues,
pull request comments,
discussions,
personal forks,
copied logs,
debugging snippets,
open source contributions,
and public repositories outside the company organization.

GitHub Public Monitoring is designed for this wider surface.

For teams using GitHub Enterprise Cloud with the right security plan, this is a useful control to review.

3. Verify company domains

Verified domain matching matters because not every developer account belongs to the enterprise organization.

A developer may contribute from a personal account using a work email.

A contractor may accidentally expose a token during open source work.

A support engineer may paste a log into a public issue from an account outside the company’s managed organization.

If the enterprise has verified domains, GitHub can use that signal to attribute some public leaks back to the company.

A readiness check should ask:

Are company email domains verified?
Are contractor and subsidiary domains included where appropriate?
Are old or unused domains removed?
Is the security team watching domain-based findings?

Domain verification becomes part of the secret visibility layer.

4. Map each secret to the system it opens

Finding a secret is only half of the response.

The team also needs to know what the credential can access.

A useful alert should lead to questions like:

Is the token still active?
Which system does it open?
Is it production or staging?
What permissions does it carry?
Which customer or tenant data could it reach?
Which team owns rotation?
Are logs available to check use after exposure?

This is where many teams slow down.

They find the credential, but the ownership path is unclear.

5. Rotate first, investigate next

When a secret is exposed publicly, speed matters.

The safest operating pattern is usually:

Revoke or rotate the credential.
Replace it in the correct secret store.
Confirm the application still works.
Review access logs.
Scope possible impact.
Document the cause.
Prevent the same path from repeating.

This order prevents teams from spending too long debating exposure while the credential remains usable.

The investigation is important.

But the active credential should not wait for a perfect report.

6. Close the non-GitHub gaps

GitHub Public Monitoring is useful, but it does not cover every leak path.

Independent analysis from StepSecurity points out that public GitHub monitoring does not replace controls for places like CI environments, developer machines, workflow artifacts, build logs, or attacker-controlled destinations.

That matters because secrets can leave the company through many routes:

CI logs,
build artifacts,
local developer machines,
chat tools,
tickets,
screenshots,
shared documents,
AI tool prompts,
and third-party integrations.

The right model is layered.

Use GitHub public monitoring for public GitHub exposure. Use CI controls, secret stores, egress controls, endpoint protection, and internal scanning for the rest.

7. Assign response ownership

Secret exposure becomes chaotic when nobody owns the next step.

A good runbook should answer:

Who receives the alert?
Who validates the finding?
Who rotates the secret?
Who updates the app configuration?
Who checks logs?
Who informs customers if needed?
Who updates the prevention rule?

This is especially important for small software teams where the same person may handle code, infrastructure, support, and customer communication.

Ownership does not need to be complicated.

It needs to be visible.

A simple response workflow

When a public secret alert appears, use this order:

First 15 minutes

Confirm whether the secret matches your organization.
Identify the system or provider.
Check whether the secret is still active.
Rotate or revoke the credential.
Replace it in the correct secret store.
Confirm affected services still function.

First hour

Check logs for use after exposure.
Identify the leak surface.
Find related secrets or copied snippets.
Notify the owning team.
Record the incident in the security tracker.
Decide whether any customer communication is needed.

After containment

Review why the secret was exposed.
Add pre-commit or push protection if missing.
Improve issue and pull request hygiene.
Adjust developer guidance.
Review domain verification and public monitoring coverage.
Update the runbook.

What founders should take from this

Secret scanning is not only a developer tool.

It is part of product resilience.

If a SaaS product depends on cloud APIs, payment providers, AI services, databases, internal tools, and automation keys, then exposed credentials can become product risk quickly.

GitHub’s new public monitoring makes one thing clearer:

The company boundary is wider than the repos it owns.

A founder does not need to configure every scanner personally.

But they should know whether the team can answer these questions:

Where can our secrets appear?
How quickly would we know?
Who rotates them?
What system did the secret open?
How do we prevent the same path next time?

That is the difference between finding a leaked secret and handling it well.

Sources

The Cloud Readiness Checklist: 6 checks before scale gets expensive

Shruti Saraswat — Fri, 10 Jul 2026 06:18:32 +0000

Cloud problems rarely start as one obvious failure.

-> Sometimes the bill improves, but nobody can explain which product benefited.

-> Sometimes GPUs are reserved, but the workload is not ready for the window.

-> Sometimes caching makes the product faster, but nobody owns refresh.

-> Sometimes the provider looks available, but users in one region still feel slow paths.

These are not separate problems. They point to the same operating question:

Is the cloud setup ready for customer usage, cost pressure, and changing product needs?

That is what this checklist is for.

It is not a replacement for cloud architecture reviews, incident response plans, FinOps tooling, or provider documentation. It is a practical field checklist for SaaS teams that need to connect cloud decisions to product outcomes.

Why cloud readiness needs more than uptime

Cloud readiness is often discussed through infrastructure terms: regions, instances, reservations, cache layers, monitoring, and networking.

Those terms matter.

But founders and product teams usually need a different view:

Can customers complete the workflow?
Can we explain the bill?
Can we reuse work safely?
Can we use reserved capacity well?
Can we see regional impact?
Can we respond when the preferred path slows down?

A cloud system can look technically sound while still creating cost confusion, slow customer paths, stale responses, or capacity waste.

That is why a readiness checklist should cover both infrastructure and product consequences.

The 6-check cloud readiness framework

1. Cost attribution

Cloud savings are useful only when the company can explain who benefited.

Shared discounts, committed use discounts, savings plans, credits, reservations, and platform-level infrastructure can reduce the total bill. But if those savings are pooled across projects, products, or workloads, the reporting model needs to stay clear.

A SaaS team should be able to answer:

Which workload created the usage?
Which product received the discount benefit?
Which project absorbed uncovered usage?
Which team owns renewal or adjustment?
Does the dashboard show allocated savings, or only total spend?

This matters because product decisions depend on interpretable numbers.

If an AI workload appears cheaper, the team needs to know whether it became more efficient or was covered by shared discount capacity.

If a product line looks profitable, the team needs to know whether infrastructure costs are being allocated in a way that matches usage.

Readiness check:
Cloud savings need attribution, not only a lower total.

2. Capacity timing

Reserved capacity can be valuable when work is prepared for the window.

It can become expensive when the team books capacity before the workload is ready.

This matters most for AI and ML workloads, batch processing, evaluation runs, high-volume migrations, and compute-heavy jobs that need specific capacity during a specific period.

Before reserving capacity, check:

What job is the capacity supporting?
When does the work need to run?
What must be ready before the window starts?
What utilization would justify the spend?
What happens if the workload slips?
Who owns the capacity decision?
How will success be measured?

The question is not only whether the compute is affordable.

The question is whether the work can use the window well.

Readiness check:
Capacity planning should follow workload readiness, not only pricing pressure.

3. Cache freshness

Caching can reduce latency and repeated compute work.

But caching also creates a freshness question.

A response that is safe to reuse can improve performance and cost. A response that should have changed can damage trust.

Before caching a product path, define:

What response is being cached?
Who sees that response?
What makes it change?
How long can it be reused?
Who owns purge or refresh?
What should never be cached?
What will be measured besides speed?

Public documentation pages may be safe to cache. Product pages may need refresh rules. Tenant-specific experiences need boundaries. Pricing, permissions, account state, and billing workflows need careful handling.

Caching should not start with “can we make this faster?”

It should start with “can this safely stay the same?”

Readiness check:
Cache strategy needs freshness ownership before broad rollout.

4. Customer-path monitoring

Provider status is useful, but it is not the full picture.

A provider may be available while customers in a specific region experience latency, packet loss, routing issues, or degraded workflow completion.

Teams should monitor more than infrastructure health.

They should monitor customer paths:

login,
dashboard load,
file upload,
search,
report generation,
API response,
AI workflow,
checkout,
support submission,
and any workflow tied to revenue or trust.

Global averages can hide local issues. A product can look healthy in aggregate while one customer region feels slow.

This is especially important when the company serves users across cities, countries, networks, or enterprise environments.

Readiness check:
Monitor the workflow from the places customers use it.

5. Fallback planning

Cloud readiness needs a plan for degraded paths.

Not every slowdown should produce the same user experience.

Some workflows can be queued. Some can show cached information. Some can switch to a lighter path. Some can retry in the background. Some need a clear status message. Some should pause until the system can respond safely.

Fallback is not an excuse to hide problems.

It is a way to keep customers guided when the ideal path is degraded.

A good fallback plan answers:

What can be delayed?
What can be queued?
What can be simplified?
What can use an alternate path?
What needs a human checkpoint?
What should the user see?
Who decides when fallback mode starts?

Readiness check:
The product should have a next path when the best path slows down.

6. Ownership map

Most cloud issues become harder when ownership is unclear.

Someone may own the cloud account. Someone else may own the product. Another person may own support. Finance may review cost. Engineering may manage incident response. Product may decide customer impact.

That can work if the handoffs are clear.

It becomes messy when nobody knows who owns the next step.

A cloud ownership map should answer:

Who owns cost attribution?
Who owns capacity reservations?
Who owns cache refresh?
Who owns regional monitoring?
Who owns fallback activation?
Who communicates customer impact?
Who reviews the incident afterward?

This does not need to become bureaucracy.

It needs enough clarity that the team does not discover ownership during an incident.

Readiness check:
A cloud decision is not ready until the handoff is named.

A practical cloud readiness scorecard

Use this as a lightweight review before a major cloud decision, AI workload, cache rollout, scaling plan, or infrastructure change.

Cost attribution

Can we explain which product, project, or workload benefits from discounts, credits, or shared infrastructure?

Score:

0: Total bill only
1: Usage is visible
2: Usage and savings are attributed
3: Ownership and renewal decisions are defined

Capacity timing

Can we match reserved capacity to prepared work?

Score:

0: Capacity is booked before the workload is clear
1: Workload is named
2: Window and prerequisites are defined
3: Utilization target and fallback are defined

Cache freshness

Can we reuse responses without confusing customers?

Score:

0: No freshness rules
1: Cacheable paths are identified
2: Change triggers and TTLs are defined
3: Refresh ownership and measurement are defined

Customer-path monitoring

Can we see whether customers can complete important workflows?

Score:

0: Provider status only
1: Infrastructure metrics
2: Workflow checks
3: Regional workflow checks and alerting

Fallback planning

Can the product guide customers when the preferred path is degraded?

Score:

0: No fallback
1: Manual response only
2: Basic fallback for important workflows
3: Fallback behavior, trigger, and owner are defined

Ownership map

Can the team name who owns each handoff?

Score:

0: Ownership unclear
1: Owners known informally
2: Owners documented for key workflows
3: Owners, triggers, and review process are documented

A scorecard like this is not meant to create ceremony.

It helps teams see which cloud decision is technically possible but operationally weak.

When to use this checklist

Use it before:

buying or renewing cloud commitments,
reserving AI compute capacity,
adding caching to customer-facing paths,
expanding to another region,
launching a new product workflow,
changing CDN or routing behavior,
introducing a high-volume AI workload,
or reviewing an incident that affected customer experience.

The checklist is most useful when cloud cost, performance, and product experience are starting to overlap.

That is where many SaaS teams begin to feel cloud complexity.

The useful takeaway

Cloud readiness is not only about provider choice, instance type, or uptime.

It is about whether the team can explain cost, use capacity well, keep data fresh, monitor customer paths, prepare fallback, and name ownership.

A cloud system becomes more dependable when the team can answer:

What does this cost?
Who benefits?
What must stay fresh?
Where do customers feel impact?
What happens when the preferred path slows down?
Who owns the handoff?

That is the difference between cloud infrastructure that works and cloud infrastructure that supports the product clearly.

Sources

When your cloud is up but users still feel slow: a 7-check cloud latency playbook

Shruti Saraswat — Thu, 09 Jul 2026 05:17:58 +0000

Cloud incidents are not always simple outages.

Sometimes the service is available. The status page may not show a full platform failure. The app may still load for many users.

But a specific region, network path, provider route, or customer segment may feel the impact.

That kind of issue is harder for SaaS teams because it does not always look like a clean “up or down” problem. It can appear as slower pages, timeouts, dropped connections, API retries, delayed uploads, support complaints, or unusual behavior from one geography.

That is the useful lesson from Google Cloud’s June 2026 India network traffic incident.

Google Cloud’s status page says traffic originating from Delhi, Chennai, Mumbai, and surrounding areas experienced intermittent elevated latency and possible packet loss. Reuters reported that the incident followed a fire at a third-party facility, which led to an emergency power shutdown and reduced network capacity around Delhi.

For founders and engineering teams, the lesson is not to blame the provider.

The useful lesson is this:

Cloud health is not only provider status. It is also customer path health.

If customers feel latency, the product still has to respond.

Why this matters for SaaS teams

A SaaS product can depend on many layers before a user sees one screen:

user network,
local ISP,
DNS,
CDN,
edge routing,
cloud region,
internal APIs,
database paths,
queues,
storage,
third-party services,
and frontend performance.

When one layer is degraded, the product may still be technically available, but the customer experience may suffer.

That is why founders should not ask only:

Is the cloud provider up?

A better question is:

Can our customers complete the important workflow from the places where they actually use the product?

That is the question this checklist helps answer.

The 7-check cloud latency playbook

1. Separate provider status from customer path status

A provider status page is useful, but it is not enough.

It tells you whether the provider has reported an incident. It does not always tell you whether your specific users, routes, regions, APIs, and workflows are being affected.

Your team should maintain its own customer-path checks.

That means testing the actual product paths that customers use:

login,
dashboard load,
file upload,
checkout,
search,
report generation,
API response,
AI workflow,
support submission,
and any workflow tied to revenue or trust.

The goal is not to duplicate the cloud provider’s monitoring.

The goal is to know whether customers can complete the important actions.

Readiness question:

Which customer workflows do we monitor from outside our own infrastructure?

2. Monitor by region, not only globally

Global averages can hide regional pain.

A product may look healthy in aggregate while users in one city, country, or route experience latency. This is especially important for SaaS teams serving multiple geographies or customers with regional concentration.

Set up monitoring that checks from multiple locations, especially where your users, customers, or revenue are concentrated.

A simple regional view can show:

response time by location,
error rate by location,
packet loss indicators,
DNS resolution time,
API availability,
CDN behavior,
and route-specific slowdowns.

If your largest customer base is in India, Southeast Asia, the EU, or the US, the product should not be judged only from one monitoring region.

Readiness question:

Can we see latency by geography, or only one global average?

3. Watch the customer workflow, not only infrastructure metrics

Infrastructure dashboards can look acceptable while users still struggle.

CPU may be fine. Memory may be fine. Database health may be fine. But a customer path may still be slow because of routing, DNS, CDN behavior, third-party latency, or frontend bottlenecks.

That is why teams need synthetic checks and product-level measurements.

A good monitoring plan should include:

infrastructure metrics,
application metrics,
frontend performance,
synthetic journey checks,
API timing,
queue delay,
and user-facing workflow completion.

If the product’s important workflow slows down, the team should know before support tickets pile up.

Readiness question:

Do our alerts follow the customer journey or only the cloud resources behind it?

4. Define fallback for degraded paths

When latency rises, the product should not always behave the same way.

Some workflows need speed.

Some can be delayed.

Some can be queued.

Some can show partial results.

Some can switch to a lighter path.

Some should tell the user that the task is being processed.

For example:

show cached data temporarily,
queue a report instead of forcing an immediate result,
reduce expensive background work,
switch to a lighter API response,
pause non-critical syncs,
route through an alternate endpoint,
or show a clear status message for affected workflows.

Fallback does not mean hiding the issue.

It means giving the user a usable path when the best path is degraded.

Readiness question:

Which workflows can degrade gracefully instead of simply becoming slow?

5. Decide what customers should be told

Communication is part of reliability.

If users are affected, the product should not leave them guessing whether their internet is failing, the app is broken, or their data is at risk.

A clear customer message can reduce confusion:

what is affected,
which region or workflow is impacted,
whether data is safe,
whether users should retry,
whether the task is queued,
and when the next update will come.

The message does not need to be dramatic. It needs to be clear.

A founder should know whether the team has a customer communication path before an incident.

Readiness question:

If one region becomes slow, who updates customers and what do we say?

6. Review dependency concentration

A regional network issue can expose hidden concentration.

A company may believe it is resilient because it uses cloud infrastructure, but still rely heavily on one region, one CDN path, one provider route, one API gateway, or one third-party service.

That does not mean every SaaS company needs an expensive multi-cloud architecture.

It means teams should know where concentration exists.

Review:

primary cloud region,
failover region,
CDN configuration,
DNS setup,
critical third parties,
database replication,
queue dependencies,
support tooling,
and payment or authentication paths.

The goal is to know which dependencies matter most when one path is degraded.

Readiness question:

Which single path would create the most customer pain if it became slow?

7. Run a post-incident learning loop

After a regional latency event, do not stop at “provider issue.”

That conclusion may be factually true, but it is not operationally complete.

The team should ask:

How did we detect it?
How long did detection take?
Which users were affected?
Which workflows slowed down?
Did alerts fire properly?
Did support have the right language?
Did fallback paths work?
Did the status page help or lag behind user reports?
What should change before the next event?

A post-incident review does not need blame. It needs learning.

Readiness question:

What did this incident teach us about our own product path?

A simple cloud latency response checklist

Use this when users report slowness but the provider is not fully down.

First 15 minutes

Check provider status pages.
Check regional monitoring.
Check synthetic user journeys.
Compare affected and unaffected locations.
Review API timing and frontend performance.
Look for unusual retry or timeout patterns.
Confirm whether one workflow or many are affected.

First 60 minutes

Identify affected geographies or customer segments.
Decide whether to trigger fallback behavior.
Prepare customer-facing language if impact is meaningful.
Reduce non-critical background work if it worsens congestion.
Watch support channels for repeated symptoms.
Capture metrics for the incident review.

After stabilization

Review detection time.
Review alert quality.
Review customer communication.
Review fallback decisions.
Review dependency concentration.
Update the runbook.
Add missing regional or workflow checks.

The founder takeaway

Cloud reliability is not only about whether the provider reports an outage.

It is about whether customers can complete the workflows that matter.

A regional network issue, routing degradation, or packet loss event can still affect the product even when much of the platform remains available.

For SaaS teams, that means resilience should include:

regional monitoring,
customer-path checks,
fallback behavior,
dependency mapping,
customer communication,
and incident learning.

The useful question is not only:

Is the cloud up?

It is:

Can customers complete the workflow from where they are?

That is the difference between infrastructure status and product readiness.

Sources

Cloudflare Workers Cache changes the caching decision for server-rendered apps

Shruti Saraswat — Wed, 08 Jul 2026 15:07:50 +0000

Caching is usually treated like a performance improvement.

Make the page faster.
Reduce repeated work.
Lower compute usage.

That is true, but incomplete. For server-rendered apps, caching is also a product decision.

A cached response can make an app faster, but only when the team knows what is safe to reuse, what must stay fresh, and who owns invalidation when something changes.

That is the useful signal behind Cloudflare Workers Cache.

Cloudflare launched Workers Cache as a regionally tiered cache that sits in front of a Worker. When a cacheable request is fresh in cache, Cloudflare can return the response directly without running the Worker. On a miss, the Worker runs, and the response can be stored for the next request.

That changes the decision for teams building on serverless or edge platforms.

The question is not only:

Should we add caching?

The better question is:

Which parts of this application can safely be reused without confusing users or hiding changes?

What changed

Cloudflare Workers originally fit a pattern where the Worker often sat in front of cache and origin infrastructure.

That made sense when Workers were used to transform, route, or filter requests before they reached an origin.

But many modern apps now use Workers as the origin itself. Frameworks and server-rendered applications can run directly as Workers. In that model, every request may trigger code execution, even when the response is identical to the previous one.

Workers Cache changes that pattern.

It places a cache directly in front of the Worker. Cloudflare says it can be enabled through Wrangler configuration and controlled with familiar HTTP caching headers such as Cache-Control. It also supports cache tags and programmatic purging through ctx.cache.purge.

The important shift is that the cache follows the Worker, not the zone.

That means the caching decision is closer to the application code and the team that owns the Worker.

Why this matters for SaaS teams

SaaS products often have pages or endpoints that look dynamic but are not equally dynamic.

Some responses change constantly.

Some change every few minutes.

Some change only when product, pricing, docs, catalog, or account configuration changes.

Some should never be cached because they are personalized, permission-based, or sensitive.

If the team treats all server-rendered output as uncached, the product may spend more CPU and latency than needed.

If the team caches too broadly, users may see outdated information or the wrong version of a page.

The decision is not simply technical.

It touches product experience, cost, freshness, and customer trust.

The hidden decision

The useful decision is not:

Cache everything or cache nothing.

The better decision is:

Where should freshness matter more than speed, and where should reuse matter more than rerendering?

That question helps a team avoid two common mistakes.

The first mistake is ignoring caching because the application feels dynamic.

The second mistake is adding cache rules without clear ownership of freshness.

A good caching strategy needs both.

Build, use the platform, test, or wait?

Cloudflare Workers Cache makes the decision more practical, but it does not remove the need for judgment.

Use the platform cache when the response is safely reusable

The clearest fit is content that many users request and that does not change on every request.

Examples include:

public product pages,
documentation pages,
pricing explanation pages,
catalog-style pages,
marketing pages,
read-heavy public content,
stable API responses,
and computed responses that are expensive to generate but safe to reuse briefly.

In these cases, a cache in front of the Worker can reduce repeated rendering, improve response time, and lower CPU work.

Build custom logic when the cache key is business-specific

Some products need more control.

For example, a SaaS platform may need caching by tenant, plan, region, feature flag, locale, device type, or permission group.

Cloudflare’s model gives developers cache key control through request structure, headers, and Worker-side logic, but the team still needs to design the business rules.

If caching depends on product meaning, do not treat it as an infrastructure-only decision.

Test when freshness rules are not yet clear

Some teams should not go straight from no caching to broad caching.

A safer step is to test caching on a narrow path:

one public route,
one API response,
one documentation section,
one catalog category,
or one expensive read-only operation.

Then measure:

cache hit rate,
latency change,
CPU usage,
stale response incidents,
purge behavior,
and user-facing correctness.

A small test can reveal whether the cache strategy is helping or creating confusion.

Wait when the product cannot define invalidation

If nobody can answer when cached content should be purged, the team is not ready to cache that path.

Waiting can be the right answer when:

user permissions affect the response,
customer-specific data is mixed into public output,
pricing changes need instant visibility,
legal or compliance content must stay current,
product state changes frequently,
or ownership of purge logic is unclear.

Caching without invalidation ownership is not optimization.

It is uncertainty moved closer to the user.

A cache-readiness checklist

Before putting cache in front of a Worker, answer these questions.

1. What response are we caching?

Name the exact route, endpoint, or entrypoint.

Do not make the decision at the whole-application level unless the whole app has the same freshness profile.

2. Who sees this response?

Public visitors, logged-in users, tenants, admins, or internal tools may need different rules.

A response that is safe for one audience may not be safe for another.

3. What makes the response change?

List the events that should make the cached output stale.

Examples:

content update,
product change,
price update,
inventory change,
tenant setting change,
user permission change,
feature flag update,
deployment,
or API result change.

If the team cannot list change triggers, it cannot define purge rules.

4. How long can the response be reused?

Some responses can be cached for hours.

Some for minutes.

Some for only a short stale-while-revalidate window.

Some should not be cached at all.

A good TTL is not a guess. It reflects product tolerance for freshness.

5. Who owns invalidation?

This is the most important operational question.

If the product team updates pricing, who makes sure the cached page is refreshed?

If a tenant changes settings, who purges tenant-scoped output?

If a content item changes, what tag or path gets invalidated?

Cache ownership should be visible before launch.

6. How will success be measured?

Do not measure only speed.

Measure:

cache hit rate,
CPU usage,
response latency,
stale response issues,
purge accuracy,
support questions,
and cost impact.

If caching improves one number but creates user confusion, the team has not solved the right problem.

The founder takeaway

For founders, Workers Cache is not only a developer feature.

It is a reminder that cloud cost and product experience are connected.

A faster page is helpful.

A cheaper request is helpful.

But neither matters if the user sees outdated or incorrect information.

The decision should be:

cache public, stable, repeated responses,
avoid caching personalized or sensitive responses,
test uncertain paths narrowly,
define invalidation ownership,
and measure both performance and correctness.

Caching is powerful when the team knows what can safely be reused.

It becomes risky when the team only sees speed and forgets freshness.

Sources

AI compute cost is a capacity window, not just a GPU price

Shruti Saraswat — Tue, 07 Jul 2026 06:12:34 +0000

AI compute pricing is easy to compare on a table.

The harder part is knowing whether the team will use the capacity well.

That is the useful signal behind AWS’s latest EC2 Capacity Blocks for ML pricing update.

Capacity Blocks help teams reserve accelerator capacity for machine learning workloads. That can be valuable when a team needs high-powered AI compute at a planned time and does not want the work delayed by capacity limits.

But for founders and product teams building AI features, the pricing update points to a broader question:

Are we budgeting for GPU hours, or are we planning the capacity window around the work?

Those are not the same thing.

What changed

AWS updated reservation prices for Amazon EC2 Capacity Blocks for ML, effective July 1, 2026.

AWS says Capacity Blocks reservation prices are updated periodically based on supply and demand. AWS also explains that the reservation fee is charged upfront when the reservation is scheduled, and the customer is charged the rate that applies at the time of purchase, even if the block starts later.

Business Insider reported the update as roughly a 20% increase for the affected AI cloud purchasing option and noted that AWS positioned this as one purchasing path among other alternatives.

The key point for teams is not only that one price changed.

The key point is that AI compute planning has to account for capacity timing, workload readiness, and usage quality.

Why this matters for SaaS and AI teams

AI compute is not like every other cloud cost.

A web service can often scale up and down around user demand.

A training run, fine-tuning job, batch evaluation, or large inference experiment may need the right capacity during a specific time window.

That makes the cost model more sensitive to timing.

If the workload is ready, the data is prepared, the model path is clear, and the team can use the reserved window well, the reservation may support delivery.

If the workload slips, the data is late, evaluation takes longer than expected, or the team books capacity before the work is ready, the economics can change quickly.

The pricing table does not show that.

The schedule does.

The hidden cost is mismatch

A capacity reservation can create value when it matches a committed workload.

It can create waste when the reservation window and the work do not line up.

That mismatch usually appears in four ways.

1. The workload is not ready

The team reserves compute, but the dataset is still being cleaned.

The architecture is still changing.

The evaluation plan is still unclear.

The team has capacity, but not enough prepared work to run through it.

2. The workload is too uncertain

Some AI work is exploratory.

The team may not know whether the next run needs a small evaluation, a larger fine-tuning job, or a different model path entirely.

In that situation, reserving capacity too early can turn uncertainty into fixed spend.

3. The reserved window is too narrow

A model job may take longer than expected.

A fine-tuning run may need extra evaluation.

A batch workload may need more retries.

If the reserved window is too tight, the team may still need additional capacity through another path.

4. The team has no fallback

If the reserved option becomes expensive or unavailable for the needed window, the team needs alternatives.

That might mean on-demand capacity, smaller model runs, lower-scale evaluation, different regions, different instance families, or a phased workload plan.

Without a fallback, the team has fewer choices when cost or availability changes.

The better question

Instead of asking only:

What is the GPU rate?

Ask:

How confident are we that this capacity window will be used well?

That question changes the cloud economics conversation.

It moves the team from price comparison to workload planning.

A practical AI compute planning checklist

Before reserving expensive AI compute capacity, teams should answer seven questions.

1. What job is the capacity supporting?

Name the workload clearly.

Is it training, fine-tuning, evaluation, batch inference, synthetic data generation, model migration, or customer-facing inference preparation?

If the job is vague, the reservation will be hard to defend later.

2. When does the work need to run?

A reservation is tied to time.

The team should know the preferred window, the backup window, and the deadline.

If the launch date can move, the capacity plan should reflect that uncertainty.

3. What must be ready before the window starts?

List the prerequisites:

dataset prepared,
prompts or evaluation set approved,
model path selected,
training or inference scripts tested,
storage and networking ready,
observability in place,
review team available.

If these are not ready, the reservation may be ahead of the work.

4. What utilization would make the reservation worth it?

A lower rate is not enough.

The reserved capacity needs useful work during the booked window.

The team should define the expected utilization level and the minimum acceptable usage before purchase.

5. What happens if the workload slips?

This is where many budgets become fragile.

If the work is delayed, can the workload be resized?

Can the run be split?

Can a smaller test happen instead?

Can the team switch to another purchase option?

Do not wait for the delay to answer this.

6. Who owns the capacity decision?

AI compute often involves product, engineering, finance, and platform teams.

Someone should own the decision.

That owner should understand both the technical need and the business cost.

Without ownership, a reservation can become a line item everyone notices only after the bill arrives.

7. How will success be measured?

Do not measure only whether the reservation was purchased.

Measure whether it helped the team complete useful work.

Useful measures include:

workload completed,
capacity utilization,
cost per successful run,
schedule fit,
retry volume,
evaluation output,
delivery impact,
and whether the next reservation can be forecast more accurately.

When reserved AI capacity can make sense

A reservation path can make sense when:

the workload has a clear schedule,
the team needs accelerator capacity at a specific time,
the job size is understood,
prerequisites are ready,
utilization is likely to be strong,
and the cost owner can explain the business reason.

For example, a company preparing a planned fine-tuning cycle may know when data is ready, how long the job should run, and what outcome the team needs.

That is a better fit than a team still deciding whether the workload should run at all.

When teams should be more cautious

Teams should slow down when:

the data pipeline is not ready,
the workload scope keeps changing,
the model plan is unsettled,
the run window is uncertain,
review or evaluation capacity is missing,
the cost owner is unclear,
or the team cannot explain what success looks like.

In those cases, the first step may be a smaller run, a pilot workload, or a better schedule plan.

Not every AI workload needs reserved capacity on day one.

The founder takeaway

AI compute cost is not only a cloud pricing problem.

It is a capacity planning problem.

For founders, the useful question is not only:

Can we afford the GPUs?

It is:

Can we use the capacity window well enough to justify reserving it?

That is where AI cloud economics becomes more practical.

A GPU reservation can support a high-value AI workload.

But only when the work, the timing, the owner, and the fallback are clear.

Sources

Your cloud discount may no longer belong to one project

Shruti Saraswat — Mon, 06 Jul 2026 14:51:15 +0000

Cloud discounts look simple from a distance.

Commit usage.
Get a lower rate.
Reduce the cloud bill.

That is the easy version.

The harder version starts when one discount applies across multiple teams, products, projects, or environments.

That is why Google Cloud’s June 2026 committed use discount change matters.

It is not only a billing setting.

It changes how teams should think about cloud discount ownership.

What changed

Google Cloud changed the default scope for resource-based Committed Use Discounts, also called CUDs.

Before this change, the default scope was Project.

After the change, the default for most Cloud Billing accounts is Billing account, with CUD sharing enabled.

That means a resource-based commitment can apply across eligible usage from all projects linked to the same Cloud Billing account, instead of only the project where the commitment was purchased.

Google Cloud describes the change this way:

Cloud Billing accounts created on or after June 16, 2026 default to Billing account scope.
Existing Cloud Billing accounts with no active resource-based commitments on June 16, 2026 were changed to Billing account scope.
Existing Cloud Billing accounts with active resource-based commitments kept their existing configuration.

At a high level, this can improve discount utilization.

If one project’s usage drops and another project’s usage rises, a shared commitment has a better chance of being used across the account.

That is useful.

But it also creates a new responsibility:

If the discount is shared, the ownership model needs to be clear.

Why this matters for SaaS teams

Many SaaS companies split cloud infrastructure into projects.

That split may reflect:

product environments,
customers,
regions,
internal teams,
development and production,
AI workloads,
data pipelines,
platform services,
or separate business units.

A project boundary often becomes a reporting boundary.

The founder or finance team may ask:

Which product is profitable?
Which team caused the spend?
Which customer segment is expensive to serve?
Which environment is overbuilt?
Which team should receive the benefit of a discount?

When commitments are shared across projects, those questions become more important.

The cloud bill may go down overall.

But the internal view of who used the discount can become less obvious.

That is why this is not only a FinOps detail.

It affects product economics.

The useful signal

The signal is not “CUD sharing is good” or “CUD sharing is bad.”

That would be too blunt.

The useful signal is:

Cloud savings are becoming more pooled, but product accountability still needs to stay visible.

A shared discount can help a growing company avoid unused commitments.

It can also blur the connection between usage, savings, and ownership if the team has not defined attribution.

Both things can be true.

What can go wrong without ownership rules

1. One product receives the discount another product paid for

If commitments are purchased centrally and applied across projects, one product may receive more benefit than expected.

That may be fine if the company wants pooled infrastructure economics.

It may be confusing if product profitability is reviewed separately.

2. Teams may lose visibility into unit economics

A SaaS founder might track cost per customer, cost per workspace, cost per document, cost per AI task, or cost per active account.

If shared commitments are not attributed clearly, those numbers may become harder to explain.

The company may know total cloud spend improved, but not which product workflow improved.

3. Chargeback can become noisy

For teams that use chargeback or showback, shared discounts need clear allocation rules.

Otherwise, teams may argue over whether the discount belongs to the team that purchased the commitment, the team that consumed the resources, or the platform group that planned the commitment.

4. Buying decisions may become too centralized

A central platform team may purchase commitments for efficiency.

That is often sensible.

But if product teams do not understand the commitment model, they may scale workloads without seeing how their usage affects shared commitments, uncovered usage, or future purchasing decisions.

5. Future commitments may be based on blended signals

If multiple projects consume one shared pool, renewal decisions need better data.

Otherwise, teams may overcommit because aggregate usage looked stable, while individual workloads were actually shifting.

When billing-account sharing helps

Billing-account CUD sharing is often useful when:

usage is predictable in aggregate,
individual projects fluctuate,
teams share the same cloud billing account,
workloads move between projects,
the company wants better commitment utilization,
and finance reviews cloud spend at the company or platform level.

For example, a SaaS company may have separate projects for staging, production, background jobs, analytics, and AI workloads.

Each project may fluctuate.

But together, the company may have a stable base level of Compute Engine usage.

In that case, sharing can reduce the chance that a project-scoped commitment sits underused while another project pays on-demand rates.

When project scope may still matter

Project-level boundaries can still be useful when:

each project maps to a customer contract,
regulated workloads need strict cost separation,
business units manage their own budgets,
product teams are measured separately,
internal chargeback needs clean attribution,
or one project should not subsidize another.

This does not mean CUD sharing should be avoided.

It means the company should decide whether efficiency or isolation matters more for that part of the business.

What developers should know

Even though this looks like billing, engineering teams are affected.

A cloud cost model is shaped by technical choices:

machine families,
regions,
environments,
autoscaling behavior,
batch jobs,
AI workloads,
idle capacity,
and migration paths.

If a team changes machine types, moves workloads, or scales a background service, it can affect how shared commitments are consumed.

Developers do not need to manage the entire commitment strategy.

But they should know whether their workloads are covered by shared commitments, on-demand usage, or separate project-level rules.

That helps prevent surprises.

A practical review checklist

Before buying or renewing resource-based commitments, teams should answer these questions.

1. What is the current CUD scope?

Check whether the Cloud Billing account is using Project scope or Billing account scope.

Do not assume the old default still applies.

2. Which projects consume eligible usage?

List the projects linked to the billing account and identify which workloads may consume the shared commitment.

3. Who should receive the discount benefit?

Decide whether savings should be allocated proportionally, prioritized to specific projects, or treated as a central platform benefit.

4. Which workloads are stable enough to commit?

A discount is only useful when the underlying usage is predictable enough.

Review usage by machine family, region, and workload before purchasing.

5. What happens when usage shifts?

If a product team migrates, downsizes, changes regions, or rewrites a workload, does the commitment still make sense?

6. How will teams see their share?

Dashboards should show both usage and allocated discount impact.

A team should not only see a reduced bill. It should understand why the bill changed.

7. Who owns renewal decisions?

Commitments should not renew only because they existed before.

Someone should own the decision based on current usage, forecasted usage, attribution needs, and product priorities.

The founder takeaway

Cloud discounts are not only procurement decisions.

They are infrastructure ownership decisions.

A shared commitment can be the right move when the company wants higher utilization and broader savings.

But founders should still ask:

Which projects are covered?
Which product benefits?
Which team owns the commitment?
How is the discount attributed?
What happens when usage shifts?
Will this help us understand product margins, or make them harder to read?

The cloud bill may become lower.

The cloud story still needs to stay explainable.

Sources

The AI feature readiness review: 7 checks before AI reaches customers

Shruti Saraswat — Fri, 03 Jul 2026 05:07:36 +0000

A working AI demo can be misleading. Not because the demo is fake.

Because the demo usually proves only one thing:

The model can produce a useful output under controlled conditions.

That is not the same as proving the feature is ready for customers.

A customer-facing AI feature has to survive different inputs, repeated usage, cost pressure, slow responses, blocked requests, unclear outputs, human review, changing model availability, and users who start depending on it.

That is where many AI features become product work.

Not prompt work.

Not model selection alone.

Product work.

This is why teams need an AI feature readiness review before shipping.

The review does not need to be heavy. It should not slow the team for the sake of process. But it should force one clear question:

Can this AI workflow be trusted when real users depend on it?

Why this matters now

The AI product surface is getting more complex.

Recent model releases give teams more choices across capability, speed, cost, and reasoning depth. That is useful, but it also means the team has to decide which tasks deserve which model path.

Prompt caching can reduce cost and latency when repeated context is structured well, but it needs stable prompt design and measurement. A feature that sends changing context every time may not benefit much.

AI coding agents are moving closer to the way software gets shipped, from IDEs to pull requests and command-line workflows. That can help teams move faster, but only when review remains visible.

AI traffic controls are also becoming more specific. Search, user-directed agents, and training crawlers create different consequences for websites and product content.

Together, these changes point to the same pattern:

AI is no longer only a capability layer.

It is becoming part of the product operating system.

That means the readiness review matters.

The seven checks

1. Task fit

Start with the task, not the model.

A good readiness review asks:

What exact job is the AI feature doing?
Is the task repetitive, judgment-heavy, sensitive, or customer-facing?
Does the AI output make a decision, suggest a decision, or prepare work for a human?
What happens if the output is incomplete or wrong?

This matters because not all AI tasks have the same risk.

A short summary of a support note is different from a pricing recommendation.

A draft reply is different from an automatic account action.

A code suggestion is different from a production change.

If the task is unclear, the feature is not ready.

The first readiness rule is simple:

Define the job before choosing the intelligence.

2. Model routing

The next question is not “Which model is best?”

It is:

Which model path is right for which task?

Some work can run on a fast lower-cost model. Some work needs stronger reasoning. Some work should be routed to a human before the output becomes visible.

A useful product does not need the strongest model for every request.

It needs routing.

A simple routing model can look like this:

Routine task: fast model
Complex task: stronger reasoning model
Sensitive task: review required
Unclear task: ask for more context
Failed task: fallback path

This prevents two common mistakes.

The first mistake is overusing the strongest model and creating unnecessary cost.

The second mistake is using a cheaper model for a task where weak reasoning creates retries, support work, or trust issues.

The right product question is:

What is the cheapest reliable path for this task?

3. Cost by workflow

AI cost should not be measured only by API call.

Measure cost by successful task.

A task may include:

one model call,
repeated context,
retries,
output correction,
review,
escalation,
support,
and fallback.

If the first output is cheap but often needs rework, the workflow is not cheap.

A readiness review should define:

expected input size,
expected output size,
retry rate,
review rate,
escalation rate,
cache hit rate,
cost per successful task,
and cost at higher usage.

A small pilot can hide this. Ten internal tests may look affordable. Ten thousand customer actions may expose the real shape of the workflow.

Before launch, model cost at three levels:

Pilot usage
Normal usage
Growth usage

The feature does not need perfect numbers.

It needs realistic assumptions.

4. Context and caching

Many AI features send the same context again and again.

That may include:

product rules,
customer policies,
help center content,
system instructions,
tool definitions,
examples,
and account-level configuration.

If that context repeats, caching may help reduce cost and latency. But caching only works well when repeated content is stable and structured in a way the system can reuse.

The readiness review should ask:

Which parts of the prompt are stable?
Which parts change per user?
Is repeated context placed consistently?
Are cache hits measured?
What happens when the cache is missed?
Does caching change latency enough for users to notice?

This is where prompt design becomes architecture.

A production prompt should not be one large block of text that changes every time.

It should separate stable context from variable input.

5. Human review

Some AI features can show output directly.

Others should not.

A readiness review should define where human review belongs.

Ask:

Does the output affect a customer decision?
Could it create legal, financial, security, or product risk?
Does it write to a system of record?
Does it change customer-facing data?
Does it touch code, access, billing, identity, or support outcomes?
Can the reviewer understand why the output was produced?

Review should not be treated as a vague safety net.

It should be designed.

For example:

AI drafts, human approves.
AI classifies, human reviews edge cases.
AI suggests, product logic decides.
AI investigates, engineer validates.
AI summarizes, customer chooses.

The key is ownership.

If nobody owns the review point, the workflow is not ready.

6. Fallback behavior

A production AI feature needs a fallback.

Not because the model will always fail.

Because real workflows have edge cases.

The model may be unavailable.

The output may be low confidence.

A safety rule may block the response.

The request may be too ambiguous.

The cost may exceed a limit.

The task may need more information.

The user may ask for something outside scope.

A readiness review should define what the product does in these moments.

Good fallback behavior might include:

ask a clarifying question,
return a narrower answer,
route to human review,
queue the task,
use a lower-capability path,
use a stronger model only when justified,
or explain why the request cannot be completed.

Bad fallback behavior looks like silence, vague errors, confusing refusal text, or a broken-feeling experience.

The user should not need to guess whether the AI failed or the product made a deliberate decision.

7. Access and boundaries

AI features need access rules.

This applies inside the product and outside it.

Inside the product, the team should define:

what data the AI can read,
what tools it can call,
what actions it can take,
what actions require approval,
what logs are kept,
and what data should never enter the model.

Outside the product, the team should define:

what public content AI crawlers can access,
what documentation should remain discoverable,
what training access should be limited,
and what user-directed agents can fetch.

This is no longer only an SEO issue.

It is a product access issue.

A founder does not need to personally configure every rule. But the founder should know the principle behind the rules.

AI should not have undefined access.

A readiness review template

Before launching a customer-facing AI feature, answer these questions.

Task

What job is the AI doing?

What is the user trying to finish?

What would count as a successful outcome?

Model path

Which tasks use a fast model?
Which tasks need stronger reasoning?
Which tasks should be reviewed before output reaches the user?

Cost

What is the cost per successful task?
What happens at 10x usage?
Where do retries, review, and escalation add cost?

Context

Which prompt content repeats?
Which content changes per request?
Are cache hits measured?

Review

Who reviews high-impact outputs?
What must be checked?
What stays human-owned?

Fallback

What happens when the AI cannot complete the task?
Does the user see a clear next step?

Access

What can the AI read?
What can it write?
Which pages, flows, tools, and data are off limits?

What makes the feature ready

An AI feature is not ready because the model works once.

It is closer to ready when the team can explain:

the user task,
the model path,
the workflow cost,
the review point,
the fallback behavior,
the access rules,
and the success metric.

That is what turns an AI demo into a product workflow.

The strongest AI feature is rarely the one with the most impressive model label.

It is the one that keeps working when customers use it in real life.

Sources

Cloudflare’s new AI crawler controls turn visibility into an access-policy decision

Shruti Saraswat — Thu, 02 Jul 2026 05:22:50 +0000

For years, website traffic was easier to reason about.

Search engines crawled your site.
They indexed your pages.
Some users came back through search results.

That deal was never perfect, but it was understandable.

AI traffic has made the picture more complicated.

A crawler might index your page for search.
An agent might fetch your page because a user asked it to complete a task.
A training crawler might collect your content to improve a model.
A mixed-purpose crawler might do more than one of those things.

Those are not the same kind of visit.

Cloudflare’s latest AI traffic controls matter because they make that difference more visible.

The founder consequence is not only technical. It is strategic:

AI visibility is becoming an access-policy decision, not just an SEO decision.

What Cloudflare changed

Cloudflare announced new AI traffic options for all customers on July 1, 2026.

The important shift is that AI traffic is no longer treated as one broad category.

Cloudflare is allowing site owners to manage AI traffic by three major use cases:

Search: bots that collect or index content so it can later appear in search or answer experiences.
Agent: user-directed agents visiting a site to complete a task in real time.
Training: crawlers collecting content to train or fine-tune models.

Cloudflare also said that on September 15, 2026, it will set new defaults for these classifications. For new domains onboarding to Cloudflare, Training and Agent categories will be blocked by default on pages that display ads, while Search will remain allowed by default.

That matters because it separates three things that many teams have been treating as one:

discoverability,
user-directed automation,
and long-term model training.

Why this matters for SaaS and software founders

A SaaS company does not need to be a media publisher for this to matter.

Most software companies have public web assets that create business value:

product pages,
documentation,
pricing pages,
changelogs,
help centers,
comparison pages,
technical guides,
API docs,
templates,
case studies,
and knowledge-base articles.

These pages are not just “content.”

They support acquisition, onboarding, support, trust, and product adoption.

When AI systems begin discovering, summarizing, reusing, or acting on that content, founders need to decide what kind of access they actually want.

The old question was:

“Can search engines find us?”

The new question is:

“Which automated systems should be allowed to use which parts of our site, and for what purpose?”

That is a much better question.

Not all AI traffic has the same business value

The key mistake is treating all AI bot traffic as either good or bad.

That is too simple.

Search traffic can help discovery

Search-oriented crawling can help users find your product, documentation, or expertise.

For many SaaS teams, blocking all search-like crawling would be risky because it could reduce discoverability.

This matters even more when users increasingly find answers through AI-powered search experiences.

If your public pages are blocked too aggressively, the product may become harder to find or harder to explain in answer engines.

Agent traffic can help users complete tasks

Agent traffic is different.

An AI agent might visit your pricing page to compare plans for a user.
It might read your API docs to help a developer integrate your product.
It might fetch your help center so it can walk a customer through a support problem.

That can be useful.

But it also creates product and trust questions:

Is the agent seeing the right page?
Is the information current?
Can it access content meant only for humans?
Is the interaction creating load without user value?
Should some agent workflows require authentication?
Should transactional flows be rate-limited or gated?

Agent access is not only a traffic decision. It can become a product-experience decision.

Training traffic has a different consequence

Training access is different again.

If a crawler uses your public pages to train or fine-tune a model, the business value is less direct.

The content may help improve a model, but it may not send a user back to your site, improve product adoption, or create a measurable business outcome.

Some companies may be comfortable with that.

Others may not be.

The point is not that one answer fits every founder.

The point is that founders now need a more specific policy.

Why this becomes an implementation issue

A policy is only useful if it can be implemented clearly.

For software teams, AI traffic control touches several parts of the stack:

robots.txt and content signals,
CDN or edge rules,
bot management settings,
authentication boundaries,
API rate limits,
paid or gated content,
public documentation,
support content,
analytics,
and monitoring.

The danger is not only “bad bots.”

The danger is unclear access.

If a team does not separate traffic by purpose, it may make blunt decisions:

block too much and lose useful visibility,
allow too much and lose control,
rely only on robots.txt without enforcement,
or measure traffic without understanding what the crawler was trying to do.

Cloudflare’s move reflects a more practical direction: classify the automated traffic by behavior and use case before deciding what to allow.

A founder-friendly access policy

A simple starting policy can look like this.

1. Allow useful discovery

Public product pages, educational content, and help content may need to remain discoverable.

For most SaaS companies, this includes:

homepage,
product pages,
documentation,
pricing summary pages,
release notes,
comparison pages,
and public guides.

The goal is to keep the product findable.

2. Separate agent access from search access

A user-directed AI agent is not always the same as a search indexer.

If the agent is helping a real user evaluate or use the product, access may be valuable.

But the team should still define boundaries:

Which pages can agents fetch?
Which workflows need authentication?
Which actions should agents not perform automatically?
Which endpoints should be protected from automated misuse?
What rate limits apply?

This matters more for SaaS products with dashboards, forms, checkout flows, account pages, or support workflows.

3. Decide whether training access creates value

Training access should not be assumed.

A founder can ask:

Does allowing training help our distribution?
Does it create meaningful referral or brand value?
Does it expose content we invest heavily in?
Is the content already widely available elsewhere?
Would we prefer licensing, blocking, or limited access?

The right answer depends on the business model.

A documentation-heavy developer tool may think differently from a paid research platform, a marketplace, a SaaS help center, or a content-led company.

4. Track what happens

Access policy should not be set once and forgotten.

Teams should review:

crawler categories,
traffic volume,
referral quality,
server load,
bot behavior,
search visibility,
support impact,
and pages receiving heavy automated traffic.

The goal is not to obsess over every bot.

The goal is to notice when automated access affects discoverability, cost, customer experience, or content value.

The practical consequence

The web is moving from a simple crawl-and-referral model to a more complex AI access model.

That does not mean founders should block everything.

It also does not mean they should allow everything.

The more useful response is to decide what each kind of automated visitor is allowed to do.

For a SaaS founder, the access decision might become:

Search crawlers can index public product and documentation pages.
User-directed agents can access public support and documentation content.
Training crawlers may be blocked, limited, or handled through a licensing path.
Authenticated product areas stay protected.
High-value or monetized content gets stricter rules.
Analytics are reviewed monthly to see what automated traffic is actually doing.

That is a calmer and more useful policy than “block AI bots” or “allow AI bots.”

What teams should do now

If your company relies on public content for discovery, onboarding, or customer support, review these five areas:

Public pages
Which pages should remain discoverable by search and answer engines?
Documentation and help content
Which pages should AI agents be able to fetch for user-directed support?
Training access
Which content should not be used for model training without permission or compensation?
Authenticated flows
Which product areas, forms, or actions should never be open to unauthenticated automation?
Measurement
Can the team see which bots are visiting, what they are doing, and whether they create value?

The important part is not adopting one vendor’s setting blindly.

The important part is understanding the consequence.

AI traffic is no longer one thing.

Search, agent, and training access create different business outcomes.

Founders should manage them differently.

Sources

GitHub Copilot agents changed the build-or-buy decision for AI coding workflows

Shruti Saraswat — Wed, 01 Jul 2026 06:47:34 +0000

AI coding tools used to be easier to categorize.

There was autocomplete.
There was chat.
There was code review.
There were standalone coding agents.

Now the lines are less clean.

GitHub’s recent Copilot updates show where the market is moving: coding agents are becoming a workflow layer across the IDE, CLI, GitHub issues, pull requests, model selection, budget controls, and team governance.

That changes the decision for software teams.

The question is no longer only:

“Should we use an AI coding tool?”

The better question is:

“Where should an AI coding agent sit inside our delivery workflow, and what should it be allowed to do?”

That is a much more useful decision.

What changed

GitHub announced several recent Copilot updates that matter together.

Claude Sonnet 5 is now generally available in GitHub Copilot, giving developers another model option across surfaces such as Visual Studio Code, Visual Studio, Copilot CLI, the GitHub Copilot cloud agent, the Copilot app, github.com, GitHub Mobile, JetBrains, Xcode, and Eclipse.

GitHub also announced that Copilot Agent is now available in JetBrains AI Assistant. Inside JetBrains, developers can select GitHub Copilot as an active agent, choose supported Copilot models, tune reasoning depth, and hand off multistep coding tasks.

Alongside the model and IDE updates, GitHub added per-user AI credit budgets for cost centers. Enterprise admins can now define AI usage budgets by cost center, so different teams can have different per-user limits without configuring every user manually.

These are not isolated feature updates.

Together, they point to a bigger shift:

AI coding agents are becoming something teams need to route, budget, govern, and review.

Why this matters for developers and founders

A coding agent is not only a smarter autocomplete box.

Once it can investigate issues, modify files, run commands, open pull requests, and work across tools, it becomes part of the engineering process.

That process has business consequences:

how quickly work moves from issue to pull request,
how much review time is needed,
how consistently standards are applied,
how much AI usage costs by team,
how safely agents touch code and tools,
and how easily a founder can understand what changed before it ships.

This is why the decision should not start with the model picker.

The model matters. The workflow boundary matters more.

The new decision surface

When a team evaluates GitHub Copilot agents, Claude Code, Codex, Cursor, Devin, or any similar tool, the decision has at least five layers.

1. Task fit

Not every coding task deserves an agent.

Some tasks are good candidates:

small bug fixes,
test updates,
documentation changes,
dependency upgrades,
simple refactors,
repetitive pull request feedback,
and first-pass investigation.

Some tasks need more caution:

security-sensitive code,
payment logic,
authentication changes,
data migration,
multi-service architecture changes,
and product behavior that affects customers directly.

A useful adoption plan should classify tasks before assigning tools.

2. Workflow location

The same AI capability feels different depending on where it lives.

An agent inside the IDE helps during active development.

An agent inside GitHub issues or pull requests helps with backlog movement and review loops.

An agent in the CLI helps when the developer wants terminal-level control.

An agent app or cloud session helps when work can continue in the background.

The choice is not only which agent is better. It is which surface matches the way the team already ships.

3. Control boundary

The agent needs clear boundaries.

Can it create branches?

Can it edit tests?

Can it run commands?

Can it access internal tools?

Can it use MCP servers?

Can it open pull requests?

Can it approve or merge anything?

Can it touch production configuration?

These questions should be answered before the tool becomes normal team behavior.

If the control boundary is vague, the team will either underuse the agent or trust it too broadly.

Neither is ideal.

4. Review path

AI coding agents should not remove review.

They should change what review focuses on.

Instead of reviewing every line as if it came from a junior developer, teams may need to review:

whether the agent understood the task,
whether the plan matched the product intent,
whether the changed files were the right files,
whether tests covered the risk,
whether the pull request introduced hidden complexity,
and whether the output is maintainable after the demo works.

This is where many AI coding workflows become more mature.

The review path becomes part of the product engineering system.

5. Cost and budget ownership

Usage-based billing changes how AI coding tools should be managed.

If one team uses agents for small documentation tasks and another uses frontier models for long multistep refactors, their cost profiles will look very different.

That does not mean teams should avoid advanced agents.

It means budgets should map to the kind of work each team is doing.

A platform engineering team may need higher AI usage because it handles deeper infrastructure work. A smaller product team may need a lower limit, clearer routing, or more specific allowed tasks.

The important part is not restriction for its own sake.

It is visibility.

Build, buy, integrate, test, or wait

For founders and engineering leads, the decision can be framed more clearly.

Buy when the existing workflow is already GitHub-centered

If the team already works through GitHub issues, pull requests, Actions, code review, and Copilot, buying into the existing Copilot agent layer may be the simplest path.

The advantage is workflow fit.

The agent can operate close to where work already moves.

This makes sense when the team wants fewer disconnected tools and more centralized governance.

Integrate when the team needs multiple specialized agents

Some teams will not want one agent for everything.

They may want one model or tool for documentation, another for bug investigation, another for code review, and another for exploratory refactors.

In that case, the decision becomes integration.

The team needs a shared policy for where agents can operate, how work is routed, and how output is reviewed.

GitHub’s Agent Finder direction is relevant here because it points toward task-based discovery of capabilities rather than manually connecting every tool to every workflow.

Test when the workflow is promising but not yet trusted

This is likely the right path for many growing teams.

Pick a narrow class of tasks.

For example:

update tests for a known change,
draft documentation from merged code,
investigate a non-critical bug,
apply a repeated lint or migration pattern,
or respond to simple pull request feedback.

Then measure the result.

Do not start with the hardest task.

Start where the team can learn safely.

Wait when the team has no review capacity

Waiting is reasonable when the team cannot review agent output properly.

An AI coding agent can produce more code faster.

That is not always helpful if the bottleneck is product judgment, test coverage, architecture ownership, or review quality.

If the team is already struggling to review normal pull requests, adding background agents may increase throughput without increasing confidence.

In that situation, the first step may be better review rules, not more automation.

Build only when the workflow is truly proprietary

Most teams should not build their own coding agent from scratch.

Building may make sense when the company has a very specific internal workflow, strict security model, unique domain language, custom toolchain, or product-specific agent behavior that existing tools cannot support.

Even then, the team should usually start by integrating existing tools before building the entire layer.

A custom agent is not only a model wrapper.

It needs task routing, tool permissions, context management, evaluation, logging, review handoff, and failure handling.

That is real product work.

A practical evaluation checklist

Before adopting an AI coding agent more broadly, ask:

Which task types are allowed?
Which repositories can it touch?
Which files or systems are out of scope?
Who reviews agent-created pull requests?
What tests must pass before human review?
Which model is allowed for which kind of task?
What usage budget applies by team?
What happens when the agent is uncertain?
How do we measure successful work?
What gets logged so the team can learn?

The strongest signal is not that a tool can write code.

The useful signal is that the team can decide where the tool belongs.

What to measure after adoption

A good pilot should measure more than “did it save time?”

Track:

accepted pull requests,
rejected pull requests,
review time,
correction rate,
test failures,
reopened issues,
cost by task type,
human comments per agent-created PR,
time from issue to reviewed PR,
and whether maintainers trust the output more after repeated use.

The point is not to prove that AI agents are good or bad.

The point is to find the tasks where they improve delivery without lowering confidence.

The takeaway

GitHub’s recent Copilot updates make the decision clearer.

AI coding agents are becoming part of the delivery workflow, not just another developer tool.

That means teams should evaluate them by workflow fit:

Where does the agent work?
Which tasks should it handle?
Which model should it use?
How is cost controlled?
How does review stay visible?
What should remain human-owned?

The right answer is not always “adopt everything.”

It is also not “wait until the market settles.”

The better answer is to test the narrow path where the agent can help, the risk is visible, and the team knows exactly how the output will be reviewed.

That is where AI coding agents become useful.

Not when they write more code.

When they help the team ship better-reviewed work through the right path.

Sources

GPT-5.6 pricing: the cheaper model is not always the cheaper AI workflow

Shruti Saraswat — Tue, 30 Jun 2026 12:17:33 +0000

A pricing table is useful.

It is also easy to overread.

When a new model family arrives with clearer tiers, faster options, and lower-cost paths, the first instinct is to compare input and output prices. That makes sense. Founders need to know whether a feature can survive real usage.

But the price per million tokens is only the first layer of AI cost.

The real product cost usually appears one step later:

Which tasks use which model?
How much output does the workflow generate?
How often does the same context repeat?
How many retries happen when the first answer is not good enough?
How much human review still sits around the AI step?
What happens when users depend on the feature every day?

This is why GPT-5.6 is interesting from an economics angle, not only a capability angle.

The model lineup gives teams more pricing choice. The product still needs a cost system.

What changed

OpenAI introduced GPT-5.6 with three model tiers:

Sol: the strongest model, priced at $5 input and $30 output per one million tokens.
Terra: a balanced model, priced at $2.50 input and $15 output per one million tokens.
Luna: a faster and lower-cost model, priced at $1 input and $6 output per one million tokens.

OpenAI also introduced more predictable prompt caching for GPT-5.6 and later models, including explicit cache breakpoints and a 30-minute minimum cache life. Cache writes are billed at 1.25x the model’s uncached input rate, while cache reads receive a 90 percent cached-input discount.

That creates a practical question for teams building AI into SaaS products:

Should cost planning start with the model tier, or with the workflow?

The safer answer is workflow.

Why model price is not the full cost

A lower-cost model helps when the task fits it.

It does not automatically make the full product cheaper.

For example, imagine two AI workflows:

A support-tagging workflow that classifies customer messages into a few categories.
A technical review workflow that reads long context, reasons through multiple constraints, and produces a detailed recommendation.

The first workflow may work well with a fast, lower-cost model.

The second may need a stronger model, or at least a careful routing rule that sends only the hard cases to the stronger path.

If both workflows use the same model by default, one of two things usually happens:

The simple workflow becomes more expensive than necessary.
The complex workflow becomes cheaper at first, but creates review work, retries, or user corrections later.

Both are cost problems.

One is visible on the invoice.

The other hides inside operations.

The four cost layers founders should model

A founder does not need to turn every AI feature into a finance spreadsheet before testing it.

But once the feature moves toward customer-facing usage, four cost layers should be visible.

1. Model tier cost

This is the obvious one.

Input tokens, output tokens, reasoning effort, model tier, and provider pricing all matter.

But teams should not stop here. The cheapest model for one task may become expensive if it produces answers that require extra review, retries, or longer prompts.

2. Output shape

Output tokens are often where costs grow quietly.

A product that returns short classifications, status labels, or structured fields has a different cost profile from a product that generates long explanations, drafts, recommendations, or reports.

If a feature always asks for a long answer, the bill grows with every user action.

A better pattern is to design the output around the user decision:

Does the user need a short answer?
Does the user need a draft?
Does the user need a reasoned explanation?
Does the system need a structured object instead of prose?
Can the full explanation appear only when requested?

The output format is not only UX. It is cost design.

3. Repeated context and caching

Prompt caching becomes valuable when a workflow sends the same large context repeatedly.

That may include:

System instructions.
Product rules.
Policy text.
Tool definitions.
Reusable examples.
Account-level configuration.
Long documents or knowledge context that remains stable across requests.

Caching is not magic. It depends on reuse.

If the prompt changes constantly, the cache hit rate stays low. If static content is placed at the beginning and dynamic user content appears later, the chance of a useful cache hit improves.

This changes prompt design.

A production prompt should not be treated as one big text block. It should be structured so repeated content remains stable, measurable, and cacheable where the provider supports it.

4. Review, retry, and fallback cost

This is the layer many early AI demos miss.

The first API call may be cheap.

The full workflow may not be.

A customer-facing feature can create extra cost through:

retries after weak answers,
review queues,
escalation to a stronger model,
fallback paths,
support tickets,
manual correction,
reprocessing failed jobs,
longer latency windows,
and customer confusion when the output is not clear.

Those costs do not always appear as tokens.

They appear as engineering time, support load, product complexity, and lower trust.

A better cost model for AI features

Instead of asking, “Which model is cheapest?” ask:

What is the cheapest reliable path for this workflow?

That question leads to a more useful structure.

Routine path

Use this for low-risk, repeatable tasks.

Examples:

classification,
extraction,
short summaries,
simple rewriting,
intent detection,
formatting,
routing,
and lightweight support assistance.

The goal is speed and predictability.

Escalation path

Use this for tasks where stronger reasoning changes the outcome.

Examples:

complex code review,
multi-step product analysis,
policy-sensitive work,
security review,
technical planning,
and decisions that affect customers or operations.

The goal is quality, not default low cost.

Cached path

Use this when long context repeats.

Examples:

documentation assistant,
policy review,
product onboarding assistant,
internal knowledge workflows,
support copilots with stable business rules,
and agent workflows with repeated tool definitions.

The goal is to avoid paying full input cost for the same context again and again.

Human-review path

Use this when the output has meaningful business impact.

Examples:

legal-sensitive drafts,
financial recommendations,
healthcare-adjacent content,
security-sensitive workflows,
customer-facing automation,
and high-value account decisions.

The goal is confidence, not automation for its own sake.

What developers should measure

A production AI feature should not be measured only by total API spend.

It should track cost by workflow.

Useful metrics include:

Cost per successful task
Not cost per API call. A task may require multiple calls.
Output tokens per task type
Some prompts look cheap until the output becomes long.
Cache hit rate
If caching is expected to reduce cost, measure whether it is actually being hit.
Retry rate
A cheaper model that triggers more retries may not be cheaper.
Escalation rate
How often does the workflow move from a low-cost model to a higher-capability model?
Human correction rate
Manual edits, rejected outputs, or support follow-ups are part of the cost.
Latency by path
A low-cost path that feels slow can still hurt the product experience.
Cost by customer segment
Heavy users may behave very differently from the average demo user.

These metrics make the cost real.

Without them, the team is only guessing from the pricing page.

What founders should decide before launch

Before turning an AI workflow into a customer-facing promise, founders should model three usage levels:

1. Pilot usage

A small number of users.

The goal is to learn whether the workflow is useful and where quality breaks.

2. Normal usage

Expected steady product usage.

The goal is to see whether cost fits pricing, support capacity, and margin.

3. Growth usage

Higher adoption after the feature becomes popular.

The goal is to check whether the system still makes sense when customers actually use it.

This is where many AI features become clearer.

A workflow that looks affordable for 20 users may need routing, caching, batching, or limits before it works for 2,000 users.

The practical takeaway

GPT-5.6 gives teams more choices across capability, speed, and cost.

That is useful.

But the economics of an AI product will not be solved by picking the lowest-priced model.

The better move is to design the workflow around:

task complexity,
output length,
repeated context,
cache behavior,
retry rate,
review requirements,
fallback paths,
and customer dependency.

The cheapest model is not always the cheapest workflow.

The cheapest reliable workflow is the one that routes the right task to the right path, measures what happens after launch, and avoids turning every customer action into the most expensive possible AI call.

Founder action checklist

Before shipping an AI feature, ask:

Which parts of this workflow are routine?
Which parts need stronger reasoning?
Which context repeats often enough to cache?
What is the expected output length?
What happens when the answer is not good enough?
How often will a user trigger this workflow?
What is the cost per successful task, not just per API call?
Does the pricing still work at 10x usage?

That is where AI cost planning becomes useful.

Not at the pricing table alone.

At the workflow.