DEV Community: Prem Peswani

Make generation quotas safe to retry

Prem Peswani — Sat, 17 Oct 2026 05:22:19 +0000

Any web action that calls a slower service has to handle a familiar failure: the server may finish the work, but the response can disappear before the browser receives it.

If a user retries and the backend treats the retry as a new operation, the same request may consume quota twice or create duplicate output. A button being clicked once does not guarantee one request reached the server.

A useful design pattern is to give each intended operation a stable idempotency key. The server records that key before starting expensive work. A repeated request with the same key returns the existing operation state instead of starting another one.

One possible state model is:

reserved -> completed
         -> failed

The reservation should be scoped to the user and the intended operation. A separate operation ID can let the client ask for status after a timeout. The UI can then show “still processing,” “completed,” or “failed” based on the server’s recorded state instead of guessing from the button click.

The tricky case is an upstream timeout. A timeout does not always mean the provider did no work. Before releasing a reservation or creating a new provider request, check whether the original operation can be found or safely retried with the same idempotency key. Otherwise a timeout can turn into duplicate work.

This is a design pattern, not a claim about any particular product implementation. The right quota rule depends on the product promise: whether a failed attempt is charged, whether pending work reserves capacity, and how long an operation may remain unresolved. Make those choices explicit, then test concurrent starts, browser retries, provider timeouts, and delayed responses.

I’m Prem, founder of Zextha. This post was prepared with AI assistance.

Four Better Questions Before an AI System Map

Prem Peswani — Fri, 16 Oct 2026 03:36:56 +0000

A good idea often arrives as one sentence. A useful map needs more context, but asking every person the same four questions about budget, goal, timeline, and audience misses the point. The questions should follow the idea.

For example, “I want to build a learning companion for students” suggests different unknowns than “I want to launch a creator channel.” The first may need to ask about age group, teacher involvement, connectivity, and what happens when an explanation is wrong. The second may need to ask about format, publishing capacity, audience, and how to learn from early feedback.

A practical question-selection pattern

Extract the idea’s actors and environment. Who is affected? Where will the idea operate?
Find consequential unknowns. Prefer a missing answer that changes the design over a generic fact that only fills a form.
Choose four non-overlapping questions. Each should expose a different decision or constraint.
Give usable options without trapping the user. Suggested answers can speed up the flow, but an “other” path should preserve nuance.
Carry those answers into the map. A question is useful only if the resulting nodes, risks, or next steps change.

The key distinction: four questions are a limit on friction, not a fixed checklist.

A map is a hypothesis, not a verdict

After clarification, a map can surface relationships among the central idea, dependencies, constraints, risks, and next experiments. It should make assumptions visible and leave room for correction. It should not imply that a model has validated demand, safety, or feasibility. Those require evidence outside the map.

At Zextha, the starting flow asks four questions tailored to the idea and turns the answers into a system map. I think the useful standard for this kind of tool is simple: did it help someone identify a better first test?

Try it with your own idea: https://www.zextha.space/

If you have built an idea-discovery flow, how do you decide which question is worth one of the four slots?

From a vague idea to a system map: the workflow behind Zextha

Prem Peswani — Thu, 15 Oct 2026 04:51:07 +0000

I’m building Zextha, a visual workspace for exploring the system around an idea. This is a short walkthrough of the product workflow and the decisions behind it.

The problem: a prompt leaves things unsaid

“I want to build a learning companion” describes an intention. It does not tell us who will use it, what environment it needs to work in, or how we will know it helps. Starting implementation immediately can hide those unknowns inside the design.

Zextha gives the early thinking a visible structure:

Describe the idea in your own words.
Answer four questions tailored to that idea.
Explore a map of perspectives and their relationships.
Use the map to decide what to investigate or try next.

Four questions should earn their place

A fixed budget–goal–timeline checklist is convenient, but it can miss the questions that matter for a particular project.

For a learning companion, device access and the learner’s context may be important. For a content creator, the audience and a sustainable format may matter more. These are examples of useful questions, not a promise that every generated session uses the same wording.

The goal is to collect context that can change the map, while keeping the interaction short.

A map is an interface for investigation

A useful node should give you something to examine: a dependency, constraint, risk, choice, or next action. Connections help show why one decision affects another.

For example, choosing an offline-first experience affects storage, synchronization, content updates, and how failures are explained. Treating “offline support” as a single checkbox would hide much of that work.

The output still needs human review. A generated map is not an exhaustive architecture review or evidence that an idea will work. It is a way to make the next discussion more concrete.

Reading and references have different jobs

Zextha’s Notes area contains original field books with chapters that can be read inside the workspace. Documents helps readers understand why a reference matters and follow it to the original source.

Keeping those experiences distinct matters: reading a chapter and evaluating a source are different tasks.

An optional perspective for agents

Zextha also exposes an MCP connection for compatible clients. An agent can request a read-only perspective on an idea, an approach, or next steps. It does not automatically inspect your files or take control of your project; the client supplies the context.

The connection details are available in the MCP workspace.

Try it with a real uncertainty

If you explore Zextha, try an idea you are still unsure about. Look for one useful connection, then verify it against the real requirements.

I’d welcome feedback from builders: what information would make a system map useful before you start implementation?

Disclosure: I’m Zextha’s founder. This post was prepared with AI assistance.