Pricing & Proposals

We price projects based on the actual scope, complexity and technical requirements rather than using a single fixed price for every website or software project.

Factors that can affect pricing include:

• number and complexity of pages or workflows

• custom design requirements

• e-commerce functionality

• third-party integrations

• content or data migration

• user roles and permissions

• administration requirements

• custom development

• testing and launch requirements

For clearly defined projects, we generally prefer a project-based proposal so the client understands what is included before development begins.

Always.

Creafter provides project proposals free of charge.

After reviewing your project requirements, we can prepare a proposal outlining the recommended approach, scope, estimated timeline, pricing, and key deliverables.

Often, yes.

You do not necessarily need a detailed technical specification before contacting us.

If the project is relatively straightforward, information about your goals, required functionality, current website or system and expected scope may be enough for us to prepare a proposal.

For more complex software or integration-heavy projects, some discovery may be necessary before we can provide a reliable fixed scope and price.

We prefer to clarify uncertainty rather than give an attractive estimate that changes significantly once development starts.

The most useful information usually includes:

• what you want to build or improve

• the business goal behind the project

• your current website or system, if applicable

• required pages or functionality

• integrations

• content or migration requirements

• examples or references

• preferred launch timeline

• approximate budget range

You do not need to make technical decisions for us.

The purpose of the early conversation is to understand the project well enough to define an appropriate solution and scope.

When a project has a sufficiently clear scope, the proposal may use a fixed project price for the agreed deliverables.

That does not mean unlimited work is included.

The price is based on the scope described in the proposal.

If the client later requests significant functionality, integrations or changes that were not included, we will identify that separately before performing the additional work.

For projects where the requirements cannot reasonably be fixed in advance, another commercial model may be more appropriate.

It depends on the type of work.

Clearly defined new projects are often easier to manage with a project-based proposal.

Hourly or time-based work may be more appropriate for:

• troubleshooting

• small improvements

• existing-system investigation

• ongoing development

• changing requirements

• technical support

• work where the scope cannot reasonably be predicted in advance

The commercial model should match the nature of the work rather than forcing every project into the same pricing structure.

Payment structure depends on the size and duration of the project.

A project may be divided into an initial payment and one or more milestone payments rather than requiring the entire amount at completion.

For larger projects, milestones can be aligned with meaningful stages of delivery.

The exact schedule is defined in the proposal so both sides understand when payments are due before work begins.

Third-party costs such as hosting, software licenses or external services may be handled separately where applicable.

Not automatically.

Some projects depend on third-party services such as:

• hosting

• domain registration

• premium plugins

• SaaS subscriptions

• payment providers

• email services

• external APIs

• stock assets

• licensed software

If a required third-party cost is known during planning, it should be identified in the proposal.

Where practical, we prefer important recurring services and accounts to be owned directly by the client rather than hidden inside a development fee.

This makes ongoing costs and ownership clearer.

Small clarifications within the agreed scope are normal.

A significant new requirement is different.

For example, adding a new integration, customer portal or major workflow after development begins can affect both cost and timeline.

When a requested change falls outside the original scope, we first explain the impact and agree on how it should be handled.

That may involve:

• a separate estimate

• an additional project phase

• replacing a lower-priority feature

• postponing the change until after launch

We do not want clients to discover unexpected charges after the work has already been completed.