Back to journal
Project planningSeptember 17, 20263 min read

What shapes the cost of a web app?

Understand estimates, compare proposals, and spot the decisions that change the amount of work.

HTWords by Hanxio Team
What shapes the cost of a web app?

Two products can look similar in a screenshot and require very different amounts of work. A useful estimate explains the behaviour behind the screens, the assumptions being made, and what is included in the release.

User roles change the work behind a screen

A dashboard for one owner differs from a workspace with team invitations, restricted roles, shared records, and an administrator who resolves account problems. Each permission changes what people can see and do, and how those rules are tested.

List the roles before comparing prices. For each role, describe its main tasks and the data it must never access. That helps a developer estimate the product rather than only its page count.

Integrations bring their own requirements

Payments, calendars, email, and AI integrations involve more than connecting an API. The product may need to handle failed requests, duplicated notifications, expired access, and changes made in another system.

Ask which provider will be used and what happens when it is unavailable. Usage charges, subscriptions, and any approval process should be considered separately from development work.

Design readiness changes the starting point

An idea, rough sketches, and an approved interactive design are different starting points. An estimate should say whether user flows, copy, visual design, and responsive states are included.

Existing code also needs inspection before it is treated as a shortcut. Its quality, documentation, tests, and deployment process affect whether extending it will be straightforward.

Compare the same scope in every proposal

Give each team the same brief, then compare the deliverables, assumptions, review stages, and release responsibilities. Ask for clarification wherever the wording leaves room for different interpretations.

  • Which journeys and user roles are included?
  • What content, designs, access, or decisions must you provide?
  • How are changes to the agreed scope estimated?
  • What testing, deployment, documentation, and handover are included?
  • Which hosting, provider, and support costs continue after launch?

Reduce cost by narrowing the first release

If an estimate is beyond your budget, discuss a smaller complete journey. Removing an optional workflow usually creates a clearer reduction in work than asking for every feature with less time allocated to it.

Keep the requirements that protect the core experience: appropriate access, essential validation, testing, and a usable handover. A smaller product still needs to be something you can operate.

Share a budget range early

A range helps a team explain what is feasible and where the trade-offs are. If you do not know your budget yet, say so and ask which unknowns need resolving before a useful estimate is possible.

At Hanxio, the estimate follows a discussion of your goals and scope. Different product requirements need different estimates.

Continue reading

More ideas for the road ahead