Planning your first release
How much does a web app cost? Start with the scope.
Understand web app development cost through a client-portal scope example: roles, workflows, integrations, exclusions and ongoing operating costs.
A screen count is not a scope
Two applications can have the same number of screens and very different development costs. One may display existing records; another must enforce permissions, process payments and synchronize several systems. The visible interface is only part of the work.
A useful estimate starts with who uses the product, the job they must complete and what the system must do when something goes wrong. Aevlorn gives a fixed price for an agreed scope before development. This guide explains the inputs to that scope; it is not a price list or a quote.
An illustrative client-portal release
Imagine a founder building a portal for a small service business. The first release lets a client submit a request and see its status, while the team can review and assign it. The table separates the initial workflow from plausible additions.
| Area | First release | Separate scope decision |
|---|---|---|
| Users | Client and team roles | Multiple organizations, custom roles and enterprise sign-on |
| Requests | Create, assign and update status | Complex approval chains and automated service-level rules |
| Notifications | A defined set of email updates | Multiple channels and per-user preferences |
| Files | Include only if essential; define size and access rules | Large imports, advanced search and document processing |
| Payments | Exclude if the initial workflow does not require billing | Subscriptions, refunds, tax handling and usage billing |
| Reporting | Operational status view | Custom reports and data exports |
What changes the estimate
Permissions affect how every record is read and changed. Integrations require access, sample data and a clear response to API failures. Migrating old records requires validation and a plan for incomplete data. These requirements should be visible in the estimate rather than discovered halfway through development.
- Number of distinct user roles and workflows
- Data quality, migration and retention requirements
- Third-party APIs, permissions and reliability
- Billing rules and administrative controls
- Accessibility, testing and release acceptance criteria
- Design maturity and decisions still waiting for user feedback
Separate the build from ongoing costs
Ask for recurring services to be listed separately: hosting, databases, email, file storage, workflow tools and any model/API usage. Define who owns the accounts and who is responsible for backups, monitoring and updates.
Release support and long-term maintenance are different commitments. A proposal should explain what is included at launch, what happens when an external service changes and how future work is agreed. A low build quote is hard to compare if these responsibilities are missing.
Bring a brief that can be estimated
Write a short description of the target user and the core journey. Add sketches or an existing prototype if available. List required integrations and flag decisions that are still uncertain. A deadline is useful, but also explain what drives it so the release can be prioritized intelligently.
- What must the user be able to finish on day one?
- What can be handled manually during the first release?
- What is explicitly outside this phase?
- Which accounts, designs and data are already available?
- Who approves the scope and reviews the build?
Compare the same release
Compare quotes against the same acceptance criteria and exclusions. Ask each team to identify assumptions, dependencies, recurring costs and the process for a change request. A phased approach can make sense when learning from the first release will change the next one.
The goal is a price attached to a usable outcome. Share the workflow and constraints with us, and we can discuss what needs to be clarified before an estimate is responsible.
Put the plan into practice
A useful first conversation
Let’s define what to build first.
Bring the problem, your users and the constraints. We’ll discuss the next step and what needs to be scoped.