{
  "version": "2",
  "id": "https://freelancenews.online/news/a-developer-s-account-of-keeping-ai-generated-project-estimates-tied-da4d80e1",
  "title": "A developer's account of keeping AI-generated project estimates tied to a fixed pricing catalog",
  "summary": "In a dev.to build story, a developer describes Project Blueprint, an estimator that lets a language model propose architecture and scope while a separate calculation engine, driven by the same rules object as the pricing page, produces the price range.",
  "body": "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.\n\nThe 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.\n\nA 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.\n\nThe 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.\n\nA 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.\n\nAdditional 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.\n\nThat 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.\n\nWhen 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.\n\nTo 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.\n\nThe 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.\n\nFor 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.\n\nThe 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.\n\nSeveral 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.\n\nThe 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.",
  "category": "dev",
  "language": "en",
  "datePublished": "2026-10-01T07:17:54.756Z",
  "dateModified": "2026-10-01T07:17:54.756Z",
  "eventDate": null,
  "sourcePublicationDate": "2026-10-01T04:58:03.000Z",
  "source": {
    "name": "dev.to",
    "url": "https://dev.to/edwardamirain/building-an-ai-project-estimator-with-prices-the-model-cannot-invent-53o9",
    "kind": "community"
  },
  "practicalImpact": "Editorial interpretation: for freelancers and small studios building client-facing estimators, the described pattern separates the model's role (proposing scope) from the number that becomes a quote, which is a testable architecture choice rather than a guarantee of better estimates. The author's own caveat means the benefit depends on a human actually reviewing the proposed selections.",
  "limitations": "This is a single first-person community post about one internal tool. No accuracy data, pricing, availability, user numbers or independent verification are provided. The post does not describe the calculation engine's rules, how the shared rules object is maintained, or how often sanitization changes model output. Nothing here indicates the approach was tested against alternatives.",
  "keyPoints": [
    "The author says Project Blueprint's price range comes from a separate calculation engine using the same rules as the pricing page, not from the language model.",
    "The model proposes selections from a pricing catalog; a sanitizer removes unknown identifiers and supplies defaults for missing required single-choice fields.",
    "The prompt catalog, schema allowed values and sanitizer allowlist are said to come from one shared rules object.",
    "When a quote is requested, the author says the server recalculates the estimate and ignores numbers supplied by the browser.",
    "The author states that validation only confirms an input is permitted and does not determine whether a recommendation suits the user."
  ],
  "review": {
    "status": "source-reviewed",
    "checkedAt": "2026-10-01T07:17:54.756Z",
    "method": "Automated comparison against retrieved source text; not independent fact-checking.",
    "correctionNote": null
  },
  "sources": [
    {
      "id": 1,
      "url": "https://dev.to/edwardamirain/building-an-ai-project-estimator-with-prices-the-model-cannot-invent-53o9",
      "publisher": "dev.to",
      "title": "Building an AI project estimator with prices the model cannot invent",
      "publishedAt": 1790830683000,
      "fetchedAt": 1790839060728,
      "hash": "0b8d77e6d4091a1385bee1e3405b3395025114f2c96a9352683386520ce2d97d",
      "kind": "community"
    }
  ],
  "claims": [
    {
      "claim": "The author says the price range in Project Blueprint is produced by a separate calculation engine using the same rules as the pricing page, not by the language model.",
      "source": 1,
      "id": "claim-1",
      "url": "https://freelancenews.online/news/a-developer-s-account-of-keeping-ai-generated-project-estimates-tied-da4d80e1#claim-1"
    },
    {
      "claim": "Before pricing runs, a sanitizer removes unknown identifiers and supplies defaults for missing required single-choice fields.",
      "source": 1,
      "id": "claim-2",
      "url": "https://freelancenews.online/news/a-developer-s-account-of-keeping-ai-generated-project-estimates-tied-da4d80e1#claim-2"
    },
    {
      "claim": "The prompt catalog, schema allowed values and sanitizer allowlist are said to derive from one shared rules object.",
      "source": 1,
      "id": "claim-3",
      "url": "https://freelancenews.online/news/a-developer-s-account-of-keeping-ai-generated-project-estimates-tied-da4d80e1#claim-3"
    },
    {
      "claim": "The author states that validation confirms whether an input is permitted but does not determine whether a recommendation suits the user.",
      "source": 1,
      "id": "claim-4",
      "url": "https://freelancenews.online/news/a-developer-s-account-of-keeping-ai-generated-project-estimates-tied-da4d80e1#claim-4"
    },
    {
      "claim": "When a visitor requests a quote, the author says the server validates, sanitizes and recalculates, ignoring numbers supplied by the browser.",
      "source": 1,
      "id": "claim-5",
      "url": "https://freelancenews.online/news/a-developer-s-account-of-keeping-ai-generated-project-estimates-tied-da4d80e1#claim-5"
    },
    {
      "claim": "Hand-authored reference blueprints used when generation is unavailable still run their estimates through the calculation engine.",
      "source": 1,
      "id": "claim-6",
      "url": "https://freelancenews.online/news/a-developer-s-account-of-keeping-ai-generated-project-estimates-tied-da4d80e1#claim-6"
    }
  ],
  "formats": {
    "html": "https://freelancenews.online/news/a-developer-s-account-of-keeping-ai-generated-project-estimates-tied-da4d80e1",
    "markdown": "https://freelancenews.online/news/a-developer-s-account-of-keeping-ai-generated-project-estimates-tied-da4d80e1.md",
    "json": "https://freelancenews.online/news/a-developer-s-account-of-keeping-ai-generated-project-estimates-tied-da4d80e1.json"
  }
}