Web design for businesses in Munich.
Make your expertise easier to evaluate before the first meeting. We design and build websites for businesses in Munich, with clear service descriptions, useful project evidence and a considered enquiry process. HeadPills works remotely from Wrocław; German content is implemented with an agreed reviewer.
- Explore
- Capabilities and applications
- Evaluate
- Projects and technical details
- Discuss
- A request with context
A business website should help someone evaluate your offer
A technically strong company can still be difficult to buy from when its website lists capabilities without explaining where they apply. Someone arriving for the first time may not know your terminology or which division handles their problem. A Munich website project should begin with a map of buyer questions: what you provide, where it fits, what information you need and what happens after contact. That map informs both the navigation and the content of individual pages.
A specialist supplier
The City of Munich describes a mix of technology, mobility, life sciences and creative businesses. For a specialist supplier working in such a setting, a useful site may need application examples, product data and a route to discuss requirements rather than an immediate checkout. This is a possible project pattern, not a claim that every Munich company buys the same way. We establish the actual sales process with your team before specifying a catalogue or integration.
A professional service
For a consultant, practice or creative company, the evidence may be a qualification, a sample deliverable or a documented project. Clarify your role and the boundaries of the service. A visitor should be able to distinguish an introductory conversation from paid delivery. Where several services require different information, give them distinct explanations instead of placing every request behind one general contact button with no indication of what to send.
Turn technical material into an understandable catalogue
- Choose useful fields
- Start with a small set of representative products or capabilities, including the awkward ones. Decide which attributes help buyers compare options and which belong in a specification document. A category should have a clear purpose; dozens of overlapping filters can make a small catalogue harder to use. Define units, optional fields and naming conventions before importing data. This avoids designing an attractive card that cannot represent the company’s real range.
- Connect files to the right item
- Attach drawings, specifications or certificates to the relevant item with clear names and context. Explain which version is current and whether a document applies to the whole range or one variant. Important commercial information should also be readable on the page rather than hidden entirely inside downloads. If some material is confidential, agree an appropriate request or access process; a publicly linked file is not protected simply because it is absent from the main menu.
- Keep information current
- Choose a source of truth for each type of information. A spreadsheet, CMS and internal system can all be useful, but independently editing the same stock, description or specification creates conflicts. Identify who approves changes and how the public site receives them. If an automated connection is proposed, inspect the available interface and failure handling before quoting it. A manual publishing process can be appropriate when changes are infrequent and responsibility is clear.
Design the enquiry around the first useful conversation
Preserve context
When someone asks about a particular capability or product, include that context in the enquiry. A manager should not have to ask which item the visitor was viewing. Distinguish a technical consultation, request for a quotation and general question where their handling differs. Avoid requiring the customer to reproduce data already selected on the page; the interface can carry the relevant item identifier into the agreed submission.
Collect enough detail
Choose fields by their usefulness to the person preparing an answer. Dimensions, quantity, intended application or a brief description may matter more than a long list of company details. Make required fields obvious and explain errors next to the relevant input. W3C’s forms guidance offers a practical basis for labels and instructions. If documents are accepted, agree file limits, access and retention with the business before enabling uploads.
Confirm receipt honestly
A message confirming submission should say what actually happened. It may confirm that a request was received, but it cannot promise technical feasibility, stock availability or a booked meeting unless the underlying process establishes those things. Agree the working destination and carry out a delivery check. If a system is unavailable, visitors need a clear error and a practical alternative rather than a success screen that silently loses their enquiry.
German content, English coordination and everyday editing
The language used to manage the project is independent from the language used to sell. We can coordinate in English while building a German-first site, or deliver both where you can serve both audiences. Before design, collect a terminology list, product names and examples of approved writing. Translation affects layout and navigation as well as body text, so it belongs in the project schedule rather than being postponed until launch day.
Customer-facing language
For German pages, appoint a reviewer who understands the field. A literal translation can make a technical description inaccurate even when the grammar is sound. Review headings, specifications, forms and confirmation text together. When an English equivalent is published, give it a stable address and a clear language link. Keep the scope manageable: translating a small, complete customer journey is preferable to publishing incomplete copies of a large catalogue.
Team-facing workflow
For editors, test the tasks they will actually perform: add an item, replace a document, publish a project and correct a translation. Webflow, WordPress or a custom editing arrangement can each suit different needs. The number of content types and permissions matters more than a general label such as easy CMS. Agree training and account ownership, and check that staff can carry out the promised updates without changing the underlying layout.
Define quality in checks you can observe
Real pages on real screens
Review a complete service page, a long specification and the enquiry form on desktop and mobile. Check keyboard interaction, contrast, focus, headings and zoom. Test long German labels instead of short placeholder text. Performance work should examine the actual images, fonts and scripts that ship. A platform’s reputation is not a measurement of your implementation, and an AI-assisted build needs the same review as code written through any other process.
Ownership and dependencies
Document the domain account, hosting, source repository, CMS and third-party subscriptions. Access should belong to the agreed business owner, with appropriate permissions for collaborators. Ask how backups and recovery work for the selected setup, and what support remains after handover. Custom code can give flexibility but still needs maintenance. A hosted platform can simplify some operations while retaining subscription costs and constraints; neither removes all operational responsibility.
Migration and ongoing work
If replacing an existing site, prepare a list of old pages, downloadable files and important external links. Match them to the new structure and test relevant redirects. Preserve useful material that buyers still need. After launch, examine actual enquiries and search entry pages before deciding what to add next. A catalogue page with visits but unsuitable requests may need clearer eligibility or specification details, not simply another page of general promotion.
Scope the first release before estimating the full roadmap
Bring representative material
Send a current website, a short explanation of the company’s main offer and several representative products, services or projects. Include one complicated example rather than only the neatest material. Tell us which languages matter, which systems hold the data and who can approve technical claims. If a trade event or sales campaign creates a deadline, identify the minimum complete journey required for it and separate later features from that release.
Our published starting scopes are €500 for a simple coded site, €1,000 for custom website design and €2,000 for an online store. A specialist catalogue, translation or data integration needs its own defined scope. The proposal distinguishes implementation, content, external services and support. We deliver remotely from Wrocław and do not present a Munich office or local client record that has not been established.
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 a product catalogue work without an online checkout?
Yes. A catalogue can help buyers compare technical information and submit a quote request. An online store is a separate choice when product selection, pricing and ordering rules support self-service.
Is HeadPills based in Munich?
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.