Web design for businesses in Lisbon.
Build a website your team can keep useful after launch. HeadPills designs and implements sites for businesses in Lisbon, with a clear offer, reusable content structures and an agreed route to enquiry. We coordinate remotely in English from Wrocław and plan Portuguese content with your reviewer.
- Launch
- A complete customer journey
- Maintain
- Edit the agreed content
- Improve
- Use actual customer questions
Choose a first release that explains a complete offer
A first release should be smaller than the entire business roadmap but complete enough for a customer to act. Define the offer, the audience and the action you want to support. A request for a demonstration, a service estimate and an online purchase need different information. We use that distinction to decide the pages and interactions for launch. Features without an owner or a clear purpose stay separate until their requirements become concrete.
A company website
For a company website, start with the services that the business can deliver now. Show who they suit, the relevant work and the information needed for an estimate. Do not create a page for every aspirational service merely to make the company appear larger. A short, understandable catalogue of genuine offers is easier to maintain and more credible than a broad navigation whose detail disappears after the first click.
A product marketing site
Lisbon City Council describes an ecosystem of startups, technology businesses and entrepreneurial support. For a product team in that setting, it can be useful to separate the marketing site from the application itself. The marketing site explains use cases and brings suitable people to a trial or demonstration; accounts, subscriptions and product behaviour are a separate functional scope. The distinction helps set an achievable launch without disguising a software build as a simple website.
Explain what exists today and what the buyer can verify
- A concrete use case
- Write the offer in terms of a task the customer recognises. Instead of starting with a list of technologies, explain the situation, the part your service handles and the information required to begin. Include the boundaries. If a particular integration or language is not available, do not let a visual suggest otherwise. Your team should be able to confirm every capability described on the public site.
- An honest demonstration
- Use screenshots, project material or a short demonstration to support important claims. Clearly distinguish a working product from a proposed interface or illustrative scenario. A recorded example should state what it demonstrates without implying a live connection. Where results have not been measured, describe the delivered function or process. This makes the site useful to buyers without relying on invented customer logos, growth percentages or quotations.
- A relevant next step
- Choose the next step that matches the stage of the offer. A mature service can invite a brief; an unfamiliar product may benefit from a demonstration; a limited launch may need a clearly explained expression of interest. Tell the visitor what happens after the action. A waitlist submission does not establish access, and an enquiry is not a confirmed booking. The confirmation and internal handling must reflect the real process.
Design the content your team will publish repeatedly
Name the content types
Identify repeated content such as projects, articles, team members or product updates. Define the fields and the relationship between them before designing their templates. A project may need a role, images and a delivered scope; an article needs a useful structure and supporting sources where appropriate. Keep navigation and content relationships explicit so that a new entry does not become an isolated page that readers cannot find.
Test the difficult entry
Populate the first template with realistic material, including a long title, a missing optional image and a complex example. Check whether editors can make those changes without inventing a new layout. A reusable system should allow meaningful variation while preserving reading order and visual coherence. If each new case requires the developer to rebuild the page, that should be an agreed maintenance model rather than a surprise after launch.
Assign approval and maintenance
Give every content type an owner and a review path. Decide who checks factual claims, translations and publication dates. An editing interface cannot compensate for unclear responsibility. At handover, test common tasks with the appointed editor and document the steps they will repeat. If the team changes later, the instructions and account structure should allow another person to take over without relying on the original project conversation.
Coordinate English and Portuguese without doubling confusion
English project coordination does not automatically mean an English-only website. Choose languages according to the customers you can serve and the content you can maintain. A second version should cover the complete relevant journey, including forms and confirmation. Where the two audiences need different explanations, agree that distinction intentionally instead of translating every sentence mechanically or allowing the versions to drift without oversight.
An international audience
For an international audience, introduce local details that may otherwise be assumed: where a service takes place, what the customer needs to prepare and how remote delivery works. Keep the offer precise. An English page for a Lisbon business does not need to imitate a global corporation. It needs to give a suitable buyer enough information to decide whether the company can help and how to start a conversation.
Customers using Portuguese
For Portuguese content, appoint someone who understands both the language and your offer. Review names, accents, terminology and the tone of requests. Confirm which version is authoritative for shared factual information and how updates are coordinated. HeadPills implements the agreed content and language structure; native copywriting, specialist review and translations should be identified explicitly in the proposal rather than assumed to come with every website.
Match the implementation to the team’s routine
Editing and ownership
Compare Webflow, WordPress or a coded implementation through the work the team must do. A CMS can be valuable for regular articles and projects, while a stable presentation may not need an elaborate editor. Agree account ownership, permissions, subscriptions and the content that can be changed safely. A low initial build price is incomplete information if the team cannot perform its expected updates without unplanned support.
Custom interactions
If the website requires an individual visual experience or integration, specify its behaviour with a realistic example. Custom code and AI-assisted development can help produce that implementation, but they still need testing, documentation and maintenance. Keep essential content accessible when an animation or external service is unavailable. A decorative effect should not prevent someone reading the offer or reaching the agreed contact route.
Quality of the published result
Inspect actual pages on mobile, including long headings, image captions, navigation and form errors. Provide appropriate text alternatives for informative images; a purely decorative image does not need an invented description. Measure the delivered site instead of relying on the platform’s reputation. Search visibility depends on several factors, and neither frequent publishing nor the use of AI guarantees that Google will rank the new pages.
What to include in the first project discussion
Define the release your team can operate
Send the present site or product explanation, the offer for the first release and the material you can publish now. List required languages, existing tools, content owners and the action a visitor should take. If there is a launch event, identify the pages that must be ready and the dependencies that could affect approval. We can then distinguish a complete first release from useful later additions.
Published starting scopes are €500 for a simple coded website, €1,000 for custom website design and €2,000 for an online store. Your proposal sets the specific deliverables, content responsibilities, integrations and review stages. External subscriptions, translation and continuing maintenance need defined ownership and pricing. Work is delivered remotely from Wrocław through shared previews; we do not present a Lisbon office or claim local client outcomes that have not been verified.
See the scope in published projects
Examples from our portfolio in Poland and other markets, selected for the type of work. Each case describes the scope we delivered.
Scope and starting prices
- A simple website built in code
- from €500
- Custom website design
- from €1 000
- An online store
- from €2 000
These are HeadPills starting prices. The final amount covers the agreed scope; content, translation, production and third-party costs must be identified in the proposal.
Full pricingQuestions
Before starting your project
Do we need Portuguese pages for an English-speaking audience?
That depends on the customers you want to serve. We can launch an English-first site and plan Portuguese content separately. We do not promise local-language search visibility from English pages alone.
Is HeadPills based in Lisbon?
HeadPills is based in Wrocław, Poland. We work remotely through a written brief, shared previews and agreed approvals. Any in-person meeting would be arranged in Wrocław.
How are the price and delivery date agreed?
First we agree the deliverables, functions and approval stages. The proposal states the scope, price, content dependencies and delivery date. Additional languages, licences and platform fees are identified separately.
Tell us what you want to build.
For an initial estimate, include:
- Your offer, audience and current website or identity
- Launch materials, languages and who reviews the local copy
- Required integrations or editable templates, deadline and decision-maker
An outline is enough. We do not need passwords or your customers’ personal records.