Web design for businesses in Berlin.

A website for your Berlin business, planned around the people who will buy from you. Work with HeadPills in English on the structure, visual design and implementation; appoint a reviewer for German copy where it is needed. Our studio is in Wrocław and the project runs remotely.

One offer, several routes
Service
Understand → enquire
Product
Evaluate → request a demo
Local visit
Check details → book
Decide what the visitor needs to do

Who should your Berlin website serve first?

A request for web design in Berlin can describe very different projects: a practice serving its neighbourhood, a consultancy selling across Germany, or a product team introducing software to international buyers. Before discussing page count, identify the first customer you want the site to help. Write down their problem, what they already know and the information they need before contacting you. Those answers give the homepage a purpose and keep unrelated messages from competing for its first screen.

Customers nearby

For a business customers visit, show the actual location, appointment conditions and practical access information. A service area is different from an office address: a contractor may work across several districts while a studio receives customers at one location. State the real arrangement. An English page should explain the same opening hours and booking process as the German page, rather than sending someone into a different service merely because they changed language.

Customers beyond Berlin

For a business selling remotely, geography can be a reassurance rather than the main promise. Berlin Partner describes support for international projects and links between business and science; this is useful market context, not evidence that your particular offer has demand. A technology or professional-services website still needs a clear use case, a credible demonstration and a commercial next step. We establish these from your product and customers, not from a generic description of the city.

German and English: plan complete customer journeys

Content responsibilities
Decide who owns each language before approving the design. The project can be discussed in English while the customer-facing website is primarily German. A fluent industry reviewer should check terminology, descriptions of the service and calls to action. HeadPills can implement approved translations; native German copywriting is not silently included. The content schedule must allow for review, especially when long product names or specialist explanations change the space needed in a layout.
Independent page addresses
Give published language versions their own URLs and an understandable switcher. Keep a record of which pages have an equivalent and which genuinely serve a different audience. Google provides specific guidance for multilingual URLs and language annotations; neither a flag nor an automatic browser redirect substitutes for correct content relationships. We check that a visitor can choose a language and remain on the relevant subject, including when arriving directly at an internal page.
After the enquiry
Translate the parts that follow the sales page: form labels, validation, confirmation and the information explaining what happens next. The business must also be able to answer the resulting enquiry in the advertised language. If the team supports English only for selected services, make that scope clear. A successful submission should not promise a confirmed appointment when someone still needs to review availability and reply manually.

Build the site around how the buyer evaluates you

  1. Define the entry page

    Choose the entry page for each main audience. A recommendation may lead to the homepage; a search for a particular service should land on that service; a partner may share a project directly. Each page needs enough context to stand alone. For example, a B2B service page can explain the problem, suitable company size, deliverables and dependencies without making visitors read a lengthy company history before they understand the offer.

  2. Show evidence at the decision

    Place evidence beside the claim it supports. A portfolio image shows visual work, while a project description explains your role and the delivered functionality. Customer quotations need attribution and permission. Where commercial results have not been measured, describe what was built instead of inventing an increase in sales. We can help structure evidence already available to you and identify missing materials early enough to arrange photography or approval.

  3. Make the request specific

    Ask only for information needed for the first useful answer. A consultation request might need the service, context and preferred contact; a technical estimate may need a project outline and an attachment. An attachment field also brings file handling and privacy questions into scope. Avoid collecting customer records or passwords in a public enquiry form. We agree the destination of submissions and test the message the person receives after sending one.

Choose the editing and delivery model

Technology follows the maintenance plan. List what changes weekly, what changes occasionally and who will make those changes. A few stable service pages have different needs from a publication with several editors or a catalogue with frequent updates. We compare the relevant options against your actual content rather than declaring that every Berlin business needs the same system. Tilda is not part of our development offering.

A site the team updates

Webflow or WordPress can be appropriate when editors need to publish structured pages, projects or articles. Define the fields and permissions as part of the design, and test a realistic edit before handover. If a store is needed, Shopify or WooCommerce requires a separate discussion of catalogue, checkout and operations. Platform subscriptions, paid extensions and ongoing support should appear in the estimate rather than being hidden behind an initial design fee.

An individual site in code

Custom code can suit a distinctive interface, specific integration or relatively stable site. AI tools may assist implementation, but the work still needs review, accessibility checks and a maintainable structure. Agree where the code is stored, who controls deployment and how future changes are handled. Code or AI alone does not confer a ranking advantage: the implemented content, performance and technical accessibility are what we can inspect.

Check the full route from arrival to enquiry

  • Reading and interaction

    Review the website on a narrow phone as well as a desktop. Check headings with the longest real German wording, keyboard navigation, visible focus, meaningful link labels and form errors. W3C accessibility guidance helps frame these checks; a visual review alone is not a complete accessibility assessment. Any formal compliance requirement should be identified in the brief so that the required audit, expertise and evidence can be scoped separately.

  • Delivery and measurement

    Confirm that an authorised test submission arrives in the correct working inbox or system. A successful browser screen is not proof of email delivery. Where analytics is configured with the appropriate consent, distinguish a successful form from a contact-link click and exclude technical tests from customer enquiries. The business then records which genuine enquiries fit its offer, receive a proposal and become paid work.

  • Existing search entry points

    For a replacement site, inventory existing URLs before changing the structure. Map valuable pages to relevant destinations, preserve useful content and test redirects. Update internal links and the sitemap. We do not promise that a redesign will retain every search position, but we can avoid preventable losses such as deleting a useful service page without an equivalent or moving its address without a working redirect.

What to send for a useful estimate

Start with one real project

Send your current website, the offer you want to sell, the intended customers and examples of the material already available. Add the languages, who can approve translations and who will update the site after launch. If there is a fixed campaign or opening date, explain which pages and actions must be ready for it. This gives us a concrete first release to estimate rather than a vague request for a modern website.

HeadPills lists starting prices from €500 for a simple coded site, from €1,000 for custom website design and from €2,000 for an online store. These are scope starting points, not a quote for every multilingual project. Content work, integrations, translations, third-party fees and maintenance need explicit agreement. We provide the deliverables, responsibilities and approval stages in the proposal, working remotely from Wrocław with shared previews.

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 pricing

Questions

Before starting your project

Should our marketing website be built inside the product?

Not necessarily. Tell us which information and interactions belong on the public site and which require a signed-in product. We can define a clear boundary before choosing the implementation.

Is HeadPills based in Berlin?

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.

Your project enquiryreplies from a person

We reply with a few questions or a price. We arrange a call only if you want one.