Web design for businesses in Madrid.
A clear website for a Madrid company with more than one service, audience or market. We organise the offer, design the key customer journeys and build the agreed editing and enquiry tools. HeadPills works remotely from Wrocław, with English coordination and a defined Spanish content review.
- Choose
- The relevant service
- Check
- Scope and proof
- Enquire
- Context for the right person
Organise the offer before adding more pages
A company with several service lines can have a large website that still fails to explain what a customer should choose. The homepage may list departments, while visitors think in terms of their own problems. Before redesigning a Madrid business website, map the actual offers, their audiences and the information needed to compare them. We turn that map into a practical navigation and decide which differences justify separate pages.
Several services
A service deserves its own page when it addresses a recognisably different need or requires a different buying decision. That page should explain suitability, deliverables, dependencies and the next step. Minor wording variations do not necessarily require new URLs. The goal is to make each entry useful in its own right, including for someone arriving directly from a search result or a link shared by a colleague.
Several markets
Invest in Madrid describes connections between digital business and international markets, including Latin America. For an individual company, this is a reason to ask which markets it actually serves, not to assume it sells everywhere. A Spanish-language offer can differ by country in delivery, terminology or commercial conditions. Establish those differences from your operation before deciding whether the site needs separate regional pages or one well-maintained language version.
Give each service a useful set of buying information
- Suitability and exclusions
- Describe the situation in which the service is appropriate and the cases that require another approach. This helps customers qualify themselves before contacting you. If a project depends on access to an existing system, approved material or a particular technical condition, say so. A page that admits relevant boundaries can be more useful than one that promises complete flexibility without explaining how a project is assessed.
- Evidence that matches the offer
- Choose evidence for the specific service. A visual portfolio may demonstrate design, while a process diagram can explain delivery and a case can establish the team’s actual role. Do not borrow results from an unrelated offer. If the company has not measured conversion or revenue changes, describe the delivered work. We can structure confirmed material clearly without adding fabricated metrics to make a page appear more persuasive.
- Inputs needed for a quote
- Ask what the team needs to prepare a first estimate. A short brief may be sufficient for a consultation; a complex technical project may need representative documents or a discussion of constraints. Explain the purpose of requested information and avoid asking for confidential customer records through an ordinary public form. The page should make a suitable visitor feel prepared to start, not force them to guess what a useful enquiry looks like.
Plan language and regional differences deliberately
Project coordination with HeadPills can take place in English while the public website uses Spanish, English or both. Choose those versions according to your customers and the team’s ability to maintain and answer them. Translation includes headings, navigation, forms and confirmation. A second language that stops at the homepage gives an incomplete journey and can create misunderstandings at the point where the visitor tries to act.
Spanish and English versions
Appoint a Spanish reviewer who understands the company’s terminology and tone. An English version may need extra context for international buyers rather than a word-for-word reproduction. Give equivalent pages clear language links and stable addresses. Keep shared facts synchronised: a changed service or price should not remain outdated in one version simply because its editor did not know that the source content had been revised.
Separate regional offers
Create separate regional pages only when there is a meaningful difference in the offer or customer information. A company serving Spain and another country may have different delivery conditions or responsible teams, but that must be established by the business. Google’s guidance distinguishes language versions from regional targeting. Repeating a page with a different place name is not a substitute for explaining how a customer in that market is actually served.
Route enquiries without making the form unnecessarily long
Identify the request
Use the selected service to guide the form rather than asking every visitor the same extensive questionnaire. A small number of useful choices can distinguish an estimate, support request or partnership enquiry. The labels should use customer language. If the organisation’s internal department names are unfamiliar to outsiders, do not make visitors learn that structure before they can ask a question.
Keep its context
Pass the relevant page or selected item with the message so the receiving person understands the context. Where a CRM connection is requested, check the existing system’s supported interface, required fields and access. Agree how failures are handled. A form that sends an email is different from a fully synchronised workflow; the proposal must state which is included and what the team continues to do manually.
Confirm and follow up
After submission, explain the next step accurately. Only state response times the business can support. An email acknowledgement does not prove that the request has been reviewed or accepted. Test delivery to the actual working destination with an authorised submission. If analytics is included, distinguish a successful form, a contact-link click and a qualified sales opportunity; these are useful but different stages of the customer journey.
Build a site the company can continue to operate
Content roles and permissions
Decide who maintains services, projects and translated content. Webflow or WordPress may fit a regular editorial routine, while a coded site can suit a more controlled publishing model or individual interaction. If a store is needed, scope its catalogue and order operations separately. Test a representative edit with the appointed owner. Account access, subscriptions and maintenance should be explicit rather than left to an informal arrangement after launch.
Technical quality
Use meaningful page structure, readable headings and a clear order for keyboard navigation. W3C guidance can inform these implementation checks. Inspect long Spanish text and realistic imagery on mobile, and avoid placing essential information only inside decorative animation. AI may assist development, but the delivered code still needs review. A claim that a site is custom-built does not by itself demonstrate good accessibility, performance or indexing.
A careful replacement launch
When replacing a current site, keep an inventory of existing pages and the reasons people visit them. Map changed addresses to relevant destinations and preserve useful information. Test redirects, internal links and language relationships in the final build. After publication, examine real search entry pages and enquiries. Improve the parts causing demonstrated confusion before expanding the site into more services or regions without evidence that visitors need them.
Prepare a brief that separates launch needs from later work
Send the offer map, even if it is rough
Send the current site, the main service lines and the customer types they serve. Include existing sales material, the intended languages, who reviews content and any systems that must receive enquiries. Identify a representative request and explain how the team handles it now. If several departments approve the project, name a person who can consolidate feedback so that contradictory comments do not determine the structure by accident.
Our published starting scopes are €500 for a simple coded site, €1,000 for custom website design and €2,000 for an online store. Content, language versions, migration and integrations affect the specific estimate. The proposal defines deliverables, responsibilities and review stages, with external fees and ongoing support identified separately. HeadPills works remotely from Wrocław; a Madrid page describes the market we can serve, not an unverified local office or guaranteed sales result.
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
Can you work on the website while our team prepares the local content?
Yes, if responsibilities and approval dates are clear. We can develop the structure and design with representative content, then replace it with reviewed copy before launch. Missing content can affect the final date.
Is HeadPills based in Madrid?
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.