Writing on dev.to, a developer explained the design of an AI project estimator named Project Blueprint, which was built at Vaynerov Technologies, in such a way that the price is never produced by the language model itself. The tool, per the author's account, accepts a product description and then proposes a team, a delivery plan and an architecture, whereas a separate calculation engine generates the price range by applying the same rules found on the company's pricing page. Refocused on that boundary between model output and application authority, the post adapts an earlier build story.
The author frames the separation as a design decision that shapes the entire feature rather than a single implementation detail. Because pricing sits outside the model, the author writes, the design must define what the model is allowed to return, how that output is checked, what the browser may submit, and what the server will store. Those four questions are presented as consequences of the same boundary, not as independent choices.
A bounded vocabulary is where the mechanism the author describes starts. Rather than free-form numbers, the model proposes selections from the pricing catalog, including platforms, features and other scope choices. A sanitizer checks those selections prior to the pricing run: unknown identifiers are removed, and defaults are given to required single-choice fields when missing. One shared rules object is said to be the source of the catalog embedded in the prompt, the allowed values in the schema, and the sanitizer's allowlist, which the author says prevents maintaining three separate definitions of what the product supports.
The resulting flow, as described, runs from a product description to a proposed architecture and scope, then to validated and sanitized selections, then to the calculation engine, and finally to an estimate. The author is explicit that this does not make the estimate independent of model output, because the model still influences the proposed scope. What the design does, in the author's framing, is make that influence explicit and inspectable, with review of the selected features remaining part of reviewing the estimate.
A distinction the author draws is meant to apply beyond this product: a constrained selection may still amount to a poor recommendation. In this account, validation establishes only whether an input is permitted; whether the recommendation suits the user is not settled by it. As a reason to keep human review in the loop even when the model's choices are technically valid, that is presented.
Additional checks beyond JSON shape are described by the author. Structured output is used by Blueprint, and the parsed result is then validated and sanitized. Duplicate identifiers, self-loops and edges pointing to missing nodes are removed by a graph sanitizer, and phase references are repaired so the diagram stays coherent. The author's point: valid JSON can still be a response that describes an unusable graph, so checks reflecting what its renderer and downstream functions actually require are needed in the application.
That lesson is generalized by the author to other products: instead, the checks might cover supported combinations of options, valid references between records, or bounds on a generated plan. What assumptions the next function will make about the data it receives is the question the author poses. As a way to decide which validations matter, rather than as a fixed checklist, this is presented.
When a result becomes a record is a second boundary. According to the author, when a visitor requests a quote, the request is validated by the server, the selections are sanitized, and the estimate is calculated again, with numbers supplied by the browser ignored. What the author calls an authoritative calculation point is thereby given to the stored quote. Convenient for an interactive preview but unsuitable for defining the value that becomes a business record is how browser state is described.
To discounts, entitlements and usage charges, the author extends the same review question: which component is allowed to make that decision, and where does a displayed suggestion become an authoritative value? A general answer is not provided by the post, but the reusable part of the design is treated as the question.
The author also describes a fallback path. Blueprint includes hand-authored reference blueprints for use when generation is unavailable, and their estimates still run through the calculation engine. The stated benefit is twofold: the fallback remains useful for exploring the product's planning and pricing behavior, and an example does not establish a different set of expectations than the full flow.
For freelancers, designers and developers who build or buy estimating tools, the account suggests a concrete pattern: let a model propose scope, but keep the number that reaches a client or a contract produced by a deterministic component with a single source of rules. The author's own caveat is that this does not remove model influence, only makes it visible, so the practical value depends on whether someone actually reviews the proposed selections.
The post is a first-person build story published on a community platform, not an independent evaluation. The author does not report accuracy figures, error rates, pricing, availability, or any comparison against alternative approaches, and no third party is described as having verified the described behavior. Claims about how the system works should be read as the author's account of their own implementation.
Several questions remain open in the supplied material. The post does not state what the calculation engine's rules contain, how the shared rules object is versioned or updated, how often sanitization removes model selections in practice, or what happens when a sanitized selection set is technically valid but commercially unsuitable. It also does not describe how the reference blueprints are maintained alongside the catalog.
The author closes by asking where the boundary should be drawn between a model's recommendation and an application's authority to act on it. The build story offers one answer for pricing, but leaves the broader question open, which is consistent with the post's framing of the boundary as a design decision to be made per feature rather than a solved problem.