Discovery / technical review
A short phase to understand the process, architecture, integrations and a sensible first-version scope.
TRANSPARENT ESTIMATION
SCOPE BEFORE PRICETwo projects both called a ‘website’ can differ several-fold in effort. We first define the problem, data, integrations and the boundaries of version one, then provide a price.
We do not publish a fictional ‘starting at’ number. After a short review, you get an estimate with explicit assumptions and a defined scope.
ASH STUDIO ≠ ASH PLATFORM
This page applies to custom ASH Studio projects. ASH Platform is a separate subscription product. Commercial Platform pricing will be published separately after approval.
ENGAGEMENT MODELS
A short phase to understand the process, architecture, integrations and a sensible first-version scope.
We define a concrete outcome, boundaries, milestones and price before implementation begins.
We deliver working stages and revisit priorities after each reviewable result.
WHAT DRIVES COST
Authentication, permissions, portals, states, approvals and non-standard business rules.
Data modelling, migrations, search, history, files and integrity requirements.
CRM, Telegram, payments, external APIs, webhooks, retries and third-party limits.
Number of workflows, models, validation, human review and usage controls.
Whether the project needs a new visual system, complex UI, illustration, copy or localization.
Observability, audit, security, recovery and requirements around critical operations.
HOW AI COST IS STRUCTURED
We do not publish a fictional fixed price for an AI Receptionist or Custom Agent. The workflow, integrations and expected usage come first.
Discovery, behavior design, knowledge, integrations, permissions, validation, QA and launch for the specific workflow.
Workflow changes, monitoring, knowledge updates, provider changes and ongoing improvement after launch.
Model/API, messaging and other third-party costs depend on the providers selected and actual usage.
BEFORE IMPLEMENTATION
What is included in version one and what is intentionally outside it.
Which assumptions the estimate depends on and what could change the price.
Which milestones can be reviewed independently and what counts as done.
Which external services and recurring costs will remain after launch.
Who owns the code and data and how the product can evolve later.
Because we do not want to sell a fictional number. A landing page, a multilingual corporate site and a product with CRM can all be called a website, but they are different projects. Scope comes first, price comes second.
Yes. That is usually preferable: identify the smallest useful vertical slice, launch it, then expand only after seeing real usage.
Budget is an architectural constraint. If the whole problem does not fit, we can reduce scope, split the work into stages or use an existing product where custom development is not justified.
WANT A REALISTIC RANGE?
The form asks for a budget range, timing and project type. That is enough to start a practical scope discussion.
Get a scope estimate