This guide helps you prepare a budget conversation. It does not present fixed packages or public prices, because a number is only useful when it matches the real problem, scope, and responsibilities of the project.
Cost starts with the website's purpose
A website that presents a company can need very different work from a platform with a private area, payments, or data that changes every day. Before discussing technology, define what the website should help people do.
- Present the company and make enquiries easy.
- Explain services, products, projects, or locations clearly.
- Receive requests, bookings, or registrations through a defined flow.
- Publish information that a team can update.
- Connect the website to other tools or an internal process.
The factors that change scope most
Two websites can have the same number of pages and require very different work. Scope should be considered as a whole, because one feature can affect design, content, development, testing, and maintenance.
- Content structure and volume, including more than one language.
- Custom design, reusable components, and mobile adaptation.
- Forms, search, filters, private areas, or business rules.
- Integrations with email, payments, CRM, billing, or other platforms.
- Content migration, redirects, technical SEO, and launch preparation.
- Maintenance, hosting, updates, and support after publication.
Not every project needs the same complexity
It is possible to start with a well-structured public presence and evolve later. The right choice is not the largest solution; it is the smallest solution that solves the problem without blocking the next step.
- An institutional website may be enough when content is public and stable.
- A catalogue may need search and data organisation without being an online store.
- A private area or status-based process may justify a web application.
- An online store has its own decisions around products, payments, operations, and customer support.
What a clear proposal should explain
A useful proposal lets you compare the work included, not only the final number. It should explain what will be delivered, what depends on client information, and what can be left for a later phase.
- The goal, audience, and proposed structure.
- Content, design, development, and testing deliverables.
- Integrations, migrations, and each party's responsibilities.
- What is excluded and may be assessed as a later improvement.
- Maintenance, hosting, domain, and post-launch support conditions.
How to prepare before asking for a budget
You do not need to have every text ready or know the technology. It is more useful to explain the context, the people involved, and the expected result. That information separates real needs from features that are only being imagined.
- Describe what is not working today or what needs to improve.
- Explain who will use, edit, or approve information.
- Collect website, brand, or workflow examples that clarify the direction.
- List existing tools that the project must work with.
- Define what must be ready in the first phase.
Why there is no public price table
eluis.pt does not publish fixed website prices. The aim is to avoid an entry figure hiding content, integrations, maintenance, or decisions that only appear later. Each proposal is built from confirmed scope and can be organised in phases when that is useful.