80 answers that really help.

The cost of a Shopware 6 shop comes down to three drivers: B2B pricing logic, ERP integration and the scale of the data migration. We price in person-days rather than in packages: audit, planning, data migration, interfaces, theme and testing are separate line items in the quote. On top of that come the Shopware licence and the running costs for hosting, updates and maintenance. A price you can rely on only exists once the data, plugins and interfaces have been audited.

A migration from Shopware 5 to Shopware 6 usually takes several months, and the pace is set by the extensions rather than by the product data: Shopware 5 plugins do not run under Shopware 6 and have to be replaced or rebuilt. That is why we start with a plugin and data audit before committing to a date.

For B2B shops with customer-specific prices, quantity scales, order approvals and ERP synchronisation, Shopware 6 is the more durable base; WooCommerce suits small ranges and straightforward D2C selling on an existing WordPress site. Shopware 6 ships company accounts, quotations and approval workflows as B2B Components — but only in the paid editions, whereas WooCommerce gets there only through a chain of plugins. As a rule of thumb: with a small range, uniform prices and no ERP, WooCommerce is often the cheaper and perfectly adequate choice.

A B2B shop sells to business customers on agreed terms: login required, net prices, customer-specific price lists, purchase on account, order approvals and links to ERP or procurement systems. A D2C shop sells openly to consumers, shows gross prices, allows guest orders and is built around campaigns, conversion and returns. The biggest technical difference lies in pricing: in D2C one price applies to everyone, in B2B the system calculates per customer and per quantity.

A Shopware 6 shop is connected to the ERP through the Admin API and a middleware layer; what moves between them is articles, prices, stock, customers, orders and documents. We build these interfaces in PHP 8 with Symfony and log every transfer, so failed runs can be traced. Before the first line of code comes the question of direction: which system owns prices, which one owns stock. Once that is settled, the integration is craft rather than risk.

A shop relaunch keeps its rankings when every indexed old URL points via a 301 to its content equivalent, and the redirect list is checked on a test system before go-live. The basis for that is a complete crawl of the old shop with URLs, titles and copy. Category pages and filter URLs are the most common point of loss, because they get new paths when the system changes. After go-live we review log files and Search Console and clear up the remaining 404s.

A Shopware 6 project runs with us in five steps: an audit of data, plugins and interfaces; a plan with a feature list and an estimate of the work; the build in sprints on a test system you can reach yourself; the data migration with sign-off; then operation and maintenance on our own servers in Germany. Planning, build and operation stay with one team, and you deal with the same developers throughout. Sign-off happens on the running system, not on screenshots.

Moving to Shopware 6 is worth it once key extensions are no longer maintained or new requirements come up — B2B pricing logic, accessibility under the German Accessibility Improvement Act (BFSG), ERP integration or OCI punch-out — and support for Shopware 5 ended at the end of July 2024. If a small shop runs reliably, brings in revenue and needs no new features, an immediate move is expensive without returning anything; a planned date in the next financial year is enough. We settle that with an audit rather than with a quote.

Sharpness Solutions in Oldenburg builds online shops with Shopware 6 from Edewechter Landstraße 161 in 26131 Oldenburg, with projects across the north-west of Germany and beyond. Clients include M&S Armaturen, Heinje, Manotura, Eschen Nutzfahrzeuge and Autohaus Brüggemann. The team is made up of PHP developers, and hosting runs on our own servers in Germany on Proxmox. Reachable Monday to Friday, 9:00 to 16:00 CET on +49 441 21 21 63 0.

Shopware 6 supports the common payment methods through the providers' own extensions: PayPal, credit card, SEPA direct debit and Klarna, plus aggregators such as Mollie, Stripe or Unzer. In B2B, purchase on account and payment in advance remain the important ones, often with a credit limit from the ERP and approval per customer account. What matters is less the selection than the feedback to the ERP: without a clean payment status there, the accounts team is left with rework, and that is what makes a shop unpopular inside the company.

The same items get overlooked almost every time: licences for third-party extensions including their annual renewal, preparing the product and image data, training the editorial team, the testing effort on your side, and the running costs of hosting and maintenance. Add payment and shipping providers with their transaction fees, and the internal working hours that appear in no quote. So budget a shop project across its first years of operation, not across the invoice at go-live.

The Community Edition is enough for shops whose requirements can be met with standard features and your own plugins; it is free and open source. A commercial edition is worth it if you want B2B features such as company accounts, order approvals and quotation processes as part of the product rather than as custom development, or if vendor support is required by contract. Those features are not in every paid edition, though — check the scope before you buy. Paying for modules you never use is the most expensive form of precaution.

OCI (Open Catalog Interface) is a standard defined by SAP through which a procurement system calls up a supplier's online shop and takes the basket filled there back into its own purchase requisition. Technically it runs over HTTP form fields: the procurement system passes credentials and a HOOK_URL, and the shop returns the line items as NEW_ITEM fields. OCI 4.0 and OCI 5.0 are the versions in common use. We build OCI integrations in Shopware 6, among other systems.

Punch-out means a buyer never leaves their procurement system but is passed through to the supplier's shop with a click. The process has four steps: the procurement system calls the shop with a user name, a password and a HOOK_URL. The shop recognises the customer and shows that customer's range and prices. The buyer fills the basket. Instead of placing an order, the shop sends the basket back to the HOOK_URL, where it becomes a purchase requisition.

OCI and cXML PunchOut solve the same task but differ in format: OCI transfers the basket as HTML form fields such as NEW_ITEM-DESCRIPTION[1], while cXML exchanges complete XML documents (PunchOutSetupRequest, PunchOutOrderMessage) and authenticates with a shared secret. OCI comes from SAP and dominates in German-speaking markets; cXML comes from the Ariba and Coupa world and is used internationally. If you serve both groups of customers, your shop needs both.

As a supplier you need three things: a shop with customer-specific prices and ranges, an OCI-capable punch-out module, and one technical account with user name and password per procurement system. On top of that comes a test phase with the customer's IT department, because SAP SRM, Onventis, Coupa and Unite each set their own field requirements. We build this in Shopware 6 and handle the technical coordination with the other side.

An OCI basket has to pass at least description, quantity, unit of measure, price, currency and price unit for every line: NEW_ITEM-DESCRIPTION[1], NEW_ITEM-QUANTITY[1], NEW_ITEM-UNIT[1], NEW_ITEM-PRICE[1], NEW_ITEM-CURRENCY[1], NEW_ITEM-PRICEUNIT[1]. NEW_ITEM-MATNR (the customer's material number), NEW_ITEM-VENDORMAT (the supplier's article number), NEW_ITEM-LEADTIME and NEW_ITEM-LONGTEXT are usually added. The unit of measure belongs there as a code, not as free text: the specification calls for UN/ECE codes (PCE for pieces), but many SAP installations expect the internal T006 codes (ST, KG). Which version applies is agreed before the first test transfer.

The most common errors are not in the standard but in the details: units of measure sent as free text instead of a UN/ECE code, prices including rather than excluding VAT, the price unit ignored on scaled and packaging-unit articles, character-set problems with umlauts, and sessions that are lost inside the procurement system's iFrame because cookies go out without SameSite=None. The second classic: the return jump lands in the wrong frame because the HOOK_URL target is not set to _top.

A punch-out catalogue is worth it for large, frequently changing ranges, configurable articles and customer-specific prices, because the buyer always sees the current state. A static catalogue via BMEcat or Excel is the better choice when only a few hundred articles with stable prices are ordered: quicker to set up, and no permanent availability requirement on the shop. With few articles and rare changes, an OCI integration is oversized.

The connection runs through a defined interface that synchronises article data, prices, stock and orders between the shop and the upstream system, usually via a REST API, file exchange (CSV, BMEcat) or middleware. What matters is the direction for each type of data: articles and prices come from the ERP or PIM, orders go back the other way. We build interfaces like this in PHP 8 with Symfony or Laminas and run them on our own servers in Germany.

The work for an OCI integration with Shopware 6 is manageable on a well-maintained shop and is priced by the work involved, in person-days: setting up the punch-out access, field mapping, units of measure and test rounds with the customer's procurement system. It gets more expensive when customer-specific prices and ranges have to be fetched live from the ERP, or when several procurement platforms have to be connected in parallel. We quote after reviewing the shop and the customer's requirements.

Sharpness Solutions in Oldenburg sets up OCI and punch-out integrations for Shopware 6 and works from Oldenburg across the north-west of Germany and beyond. Planning, build and operation from one team: PHP development, interfaces to ERP and PIM, and hosting on our own servers in Germany. Contact: Edewechter Landstraße 161, 26131 Oldenburg, phone +49 441 21 21 63 0, Monday to Friday, 9:00 to 16:00 CET.

The processes worth automating are above all those with repeated manual steps: order entry, keeping article data in step between ERP, PIM and shop, quotation and approval processes, and transfers that today run by email attachment or Excel list. The benefit shows up where data is entered more than once and where switching between media produces errors. We build such processes with PHP 8, Symfony and interfaces to ERP, CRM and Shopware 6 — starting with the process that causes the most rework.

Any ERP can be connected that releases its data through an interface, a file export or direct database access — in practice that includes SAP, Microsoft Dynamics 365 Business Central, Sage, proALPHA, abas and Odoo. What decides the effort is not the vendor name but the quality of the data model: how cleanly article numbers, variants, units of measure and price lists are maintained. We check that before the build, because that is where the work sits — not in moving the data.

TYPO3 v14 is the right choice when several editors work with graded permissions, when several languages or several domains run from one installation, and when interfaces to an ERP or CRM are part of the picture. WordPress is enough when a modest site needs to go live quickly and the editorial team stays small. We build both and decide on the basis of the permission model, the number of languages and the interfaces needed. A website with a handful of pages does not need TYPO3; a portal with an approval workflow is expensive to rebuild in WordPress.

TYPO3 is an open-source enterprise CMS written in PHP, used in Germany above all by mid-sized companies, public authorities, universities and associations. There are no licence fees; you pay for the build, the hosting and the maintenance. Its strengths are a fine-grained permission system, approval workflows, multilingual support in the core and several websites from one installation. We build TYPO3 projects on the LTS release v14 with PHP 8. For a small brochure website with no editorial team, TYPO3 is oversized — WordPress will do.

Jumping from TYPO3 v8 or v9 to v14 is technically a rebuild, not an update: across several major versions the extension APIs, TypoScript, Fluid templates and the required PHP version all change. Content and database can be migrated, custom code rarely can. The biggest risk is abandoned third-party extensions with no version for v14. We therefore check every installed extension one by one and replace what has been dropped with core features. The work depends on the amount of custom development, not on the number of pages.

Moving to WordPress makes sense when the old TYPO3 installation holds little more than editorial pages, uses hardly any custom extensions and nobody in-house is confident with TYPO3. You stay with TYPO3 and upgrade to v14 as soon as several languages, graded permissions, workflows or interfaces are involved. Either way the decision is pressing: TYPO3 v11 has had no free security updates since the end of 2024, and free support for v12 ended on 30 April 2026. We cost out both routes and set them against each other.

TYPO3 has no licence fees — you pay for the planning, the templates, the data migration and the operation. What drives the price is the number and condition of the custom extensions and the volume of bespoke templates, not the number of pages. After the launch, three items remain: hosting, security updates for the core and the extensions, and ongoing development of the content. We run projects on our own servers in Germany using Proxmox, and maintenance comes from the same team that did the build. A reliable price only emerges after the extension review.

The German Accessibility Improvement Act (BFSG) has applied since 28 June 2025 to websites and apps through which consumers buy products or book services — that is, to online shops as well as booking and customer portals. A purely informational or B2B website with no consumer offering is not covered. For services there is also a micro-enterprise exemption below 10 employees and 2 million euros annual turnover. The technical benchmark is EN 301 549, which refers to WCAG 2.1 level AA. We settle the classification before any template work begins.

TYPO3 v14 handles multiple languages in the core: languages are defined in the site handling, each translation hangs off the original record as a language version, and fallback chains, language slugs and hreflang output are configuration rather than an add-on. WordPress needs a plugin such as WPML or Polylang for this, and that plugin has to be kept in step with every core update. We recommend TYPO3 as soon as several languages are edited and maintained permanently; for a single translated copy, WordPress is enough.

A relaunch keeps its rankings when every old URL gets a 301 redirect to the new page that matches it in content. Before the move we crawl the old site, match it against the new page structure and enter the mapping into the redirect module of TYPO3 v14. Then come sign-off on a staging system, the switchover, a check of the status codes and submission of the new sitemap. Missing redirects are the most common reason for a drop in traffic after launch.

Yes — provided the backend is cut to the editorial tasks that actually come up. We build TYPO3 v14 with a fixed set of tested content elements instead of free HTML fields: editors assemble pages from building blocks, and layout, contrast and structure stay intact. Permissions can be separated by page tree, language and workspace, including approval before publication. WordPress is easier on first contact but allows a good deal more design sprawl.

Sharpness Solutions in Oldenburg builds TYPO3 and WordPress websites from Edewechter Landstraße 161 and has been in business since 1999. Planning, build and operation from one team: PHP developers in-house, hosting on our own servers in Germany using Proxmox. Projects run across the north-west of Germany and beyond, among others for M&S Armaturen, Heinje, Autohaus Brüggemann and the Diakonisches Werk Oldenburg, a Protestant welfare organisation. You can reach us Monday to Friday, 9:00 to 16:00 CET on +49 441 21 21 63 0.

Managed hosting means the provider is responsible for the whole server operation: operating system, PHP version, database, web server, security updates, backups and monitoring. With plain web space that responsibility sits with the customer. We run customer systems on our own servers in Germany using Proxmox and provide the services the project needs: MariaDB as the database, plus Redis, Elasticsearch or Docker containers where load and catalogue size justify them. The environment is sized to fit the project, not sold as a standard package.

A German server location on its own does not make a website GDPR-compliant. You also need a data processing agreement under Article 28 GDPR, documented technical and organisational measures, a deletion policy and a review of every third-party service embedded in the site: fonts, maps, tracking, chat and payment providers frequently transfer data to countries outside the EU. We host on our own servers in Germany and sign data processing agreements. The legal assessment of the services in use stays with the controller — that is, with whoever operates the website.

Four blocks of cost arise after the launch: hosting, maintenance with security updates, licences for extensions, and ongoing development. TYPO3 v14 is open source and carries no licence fee for the system itself. With Shopware 6 the Community Edition is free of charge, while the commercial editions run as a subscription. On top come paid extensions or plugins, payment and shipping services, and monitoring. We itemise hosting and maintenance separately so you can judge each of them on its own.

A maintenance contract should cover security updates, core and extension updates, backups with a defined retention period, monitoring, bug fixing and an hourly allowance for small changes. Agreed response times matter too, as does settling who keeps the PHP and database versions current. We test updates for TYPO3 v14 and Shopware 6 on a staging system first and only then apply them in production. If you would rather not have a contract, you can commission updates one at a time — but then without an agreed response time.

You can reach us Monday to Friday, 9:00 to 16:00 CET on +49 441 21 21 63 0; binding response times are set out in an individual SLA rather than promised across the board. The routine in an emergency: check availability and logs, roll back the last deployment, restore from backup if it comes to that, and only then establish the cause. Guaranteed response windows outside business hours belong in a maintenance contract. If you genuinely need round-the-clock cover, agree it explicitly instead of relying on it.

A project can be taken over without documentation, because missing paperwork is the rule rather than the exception when agencies change. We start with a code audit: secure the source code and the database, establish which versions of PHP, TYPO3 or Shopware 6 are in use, review dependencies and custom development, and trace the interfaces. Only after that audit is it possible to say honestly what will be carried over and what will be rebuilt.

For a change of agency you need nine things: the domain account at the registrar including the auth code, DNS management, hosting and SSH access, the Git repository, a current database dump, all files including uploads, licence keys for extensions and plugins, the Shopware or vendor account, and access to payment, shipping and analytics services. We work through this list before every handover. Ask for these items in writing while the previous provider is still on the project.

Vendor lock-in means a website or shop project cannot realistically be continued without the agency that built it. The usual causes are a proprietary CMS, domains registered in the agency's name, no access to the source code and undocumented deployments. You avoid it with open-source systems such as TYPO3 v14 or Shopware 6, a Git repository owned by the customer, and domains held in your own account. We release source code and access at any time on request.

For a simple WordPress site with no interfaces, standard hosting with a large provider is cheaper and perfectly sufficient. Managed hosting only pays off once services such as Redis, Elasticsearch or Docker containers, ERP interfaces, longer cron jobs or custom PHP configuration come into play — which is the normal case with Shopware 6 and larger TYPO3 installations. We run systems of that kind on our own servers in Germany. For a plain brochure site the effort is not needed.

For operation, maintenance and support, physical proximity is not required, because deployments, monitoring and bug fixing happen remotely anyway. It helps with workshops, training and meetings that involve several departments. Sharpness Solutions in Oldenburg has a single office, at Edewechter Landstraße 161 in 26131 Oldenburg; we look after projects across the north-west of Germany and beyond. Clients include M&S Armaturen, Heinje and Eschen Nutzfahrzeuge.

Yes, Proxmox VE is a mature open-source alternative to VMware vSphere: virtualisation with KVM, containers with LXC, plus high availability, live migration and integrated backups without licence fees. Since Broadcom took over VMware and changed the licensing models, many companies have been looking at a move. We run our entire server environment on Proxmox and host customer systems for TYPO3 v14, Shopware 6 and custom software on it.

A service level agreement (SLA) sets out in binding terms how quickly the provider responds to a fault, the hours during which it can be reached and which services the maintenance contract covers. The key distinction is between response time and resolution time: what is normally guaranteed is when work begins, not when the problem is solved. We agree response times in the maintenance contract; faults and change requests go through a ticket system and are prioritised by their impact.

After a hack there is a fixed order of steps: put the site into maintenance mode, change all passwords and API keys, secure the database and the files for analysis, and only then clean up. A clean state comes from restoring a backup from before the incident and applying all outstanding updates — not from deleting the files you happen to find, because the back door is usually somewhere else. If personal data is affected, Article 33 GDPR also requires a notification within 72 hours.

In our managed hosting, backups run automatically every day, and a snapshot of the entire environment is taken before every update. Retention period and restore time depend on the volume of data and the size of the system; they are agreed per project rather than promised across the board. More important than the frequency is the test: a backup that has never been restored is an assumption. So we check restorability regularly — an emergency is the wrong moment for the first attempt.

You get the complete current state: source code with its version history, a database dump, all files including uploads, the server configuration in documented form, plus domain, DNS and licence access. We hand these over at any time on request, not only when a contract ends — withholding access is a business model, just not ours. Set the handover date so that the new provider can still ask questions while the old environment is running.

Long load times usually come from three places: uncompressed images at full size, too many embedded third-party scripts, and database queries without a suitable index. Server performance is rarely the cause; a more powerful server mainly makes a badly built site more expensive. You measure the state of things with the Core Web Vitals and an analysis of slow queries in live operation. Only then is caching with Redis worth it — otherwise the cache just hides what is badly built underneath.

Answer Engine Optimization (AEO) means preparing content so that it turns up as a source in the generated answers of AI assistants such as ChatGPT, Perplexity, Copilot and Google's AI Overviews. Classic search engine optimisation (SEO) aims at a position in a list of results; AEO aims at getting a specific statement picked up into an answer. The craft behind it is familiar: clean markup, structured data, short statements that can be backed up. What is new is the reader — a machine that quotes instead of linking.

SEO and AEO share the same technical basis and differ in their goal: SEO works towards a position in the list of results, Answer Engine Optimization (AEO) towards being cited in a generated answer. Load time, clean HTML structure, heading hierarchy, structured data and crawlable pages count for both. What differs is the way you write: an AI assistant picks up self-contained statements that can be verified, not paragraphs that take three sentences to reach the point.

An online shop gets into answers from ChatGPT and Perplexity under three conditions: the search crawlers of those services are allowed to read the shop, the product data carries structured data to schema.org, and the texts answer a specific question in the first sentence. We do this in Shopware 6: maintain product attributes in full, cut category and guide texts to fit real questions, check robots.txt and status codes. Nobody can guarantee being cited.

A robots.txt blocks the AI search assistants whenever it bars everything wholesale instead of distinguishing between the individual crawler names. The providers run separate crawlers: GPTBot and ClaudeBot collect training data, OAI-SearchBot and PerplexityBot supply the answer function with current pages, and Google-Extended only controls whether content is used for training and for answers in the Gemini applications — it has no effect on the AI Overviews in Google search, which draw on the normal search index. Microsoft has no AI bot of its own; Copilot is served by Bingbot. Block everything and you keep your texts out of training while disappearing from the answers at the same time. We check each user agent one by one and match it against the server log files instead of copying a standard file.

Yes — classic search engine optimisation remains the foundation, because the technical basis is the same for both goals. Load time, clean HTML structure, structured data and reachable URLs decide whether Google indexes a page and whether an AI assistant can read it at all. Classic search is not disappearing, it is losing share: on information-led searches the click numbers fall, while the visitors who remain stand closer to a buying decision. Someone who still clicks after an AI answer wants something.

You can only measure this approximately — far less precisely than a Google position. Three routes give you something to go on: regular spot checks with the same questions in ChatGPT, Perplexity and the AI Overviews; referrer traffic from AI services, reported as its own source group in your web analytics; and watching for brand mentions. Answers vary between sessions and regions, and the same question gives a different result tomorrow. Anyone selling you a ranking table for AI answers is selling an estimate.

AI pays off on repetitive drudge work, not on a chatbot on the home page. Concretely: enriching product data from manufacturer documents, standardising attributes and categories, reading orders and delivery notes out of PDFs and emails, classifying incoming enquiries and routing them, semantic search in the shop, translations as a first draft. What these tasks have in common is that they cost many hours and nobody enjoys doing them. Nonsense implemented cleanly is still nonsense — the process has to be sound first.

Yes, provided the flow of data is settled: which personal data leaves the building, to which provider, into which country, for how long. Services such as OpenAI or Anthropic need a data processing agreement under Article 28 GDPR, a settled basis for the transfer — processing inside the EU or standard contractual clauses — and training use ruled out. Where that is not enough, we run open-weight models on our own servers in Germany, so documents and customer data never leave the network. The legal assessment is your data protection officer's call.

Retrieval Augmented Generation (RAG) is a method in which a language model first searches your own documents before answering and writes only from the passages it finds — stating the source. The model answers from the company's manual, price list or knowledge base instead of from its training memory. Technically this needs a search index, Elasticsearch for example, and the documents broken into sections. If the source is missing from the index, there is no answer — that is the point.

An AI project has two cost items: the one-off integration and the running cost by volume processed. The integration is calculated in person-days — data access, interfaces, prompt and test setup, acceptance. On top of that you pay per document, item or request processed, depending on the model and how it is run. That is why we start with a single pilot process and measure volume, runtime and hit rate there. After that you can extrapolate instead of guessing. A figure quoted before the pilot would be a guess.

The rights of use in design, texts and images pass to the client as far as the contract says so — which is why this point belongs in the contract and not in the closing invoice. Bought-in components are the exception: stock photos, fonts and third-party extensions stay tied to their licences, which are often limited to one project or one domain. Have the licence handed over with every purchased image and every font.

Yes, as soon as the agency has access to personal data — with hosting, maintenance and support that is effectively always the case. The basis is Article 28 GDPR; the agreement sets out purpose, duration, sub-processors, technical and organisational measures and deletion once the contract ends. Sharpness Solutions in Oldenburg signs such agreements and supplies the technical details your data protection officer needs for the record of processing activities. The data protection assessment itself stays with the controller, which means you.

You stay able to act only if the domain, the source code and the access credentials are in your name — that is the one precaution that works. Domains belong in an account held by your company, the source code in a Git repository you can reach yourself, and hosting, database and licence credentials in your own hands. Open source systems such as Shopware 6, TYPO3 and WordPress can then be taken over by any experienced PHP agency. Check these three points before you need them.

Defects in the work you commissioned are put right under the contractual warranty, with nothing more to pay; new wishes and changes to the scope are new orders. The line runs at acceptance: what was agreed and does not work is a defect. What nobody asked for beforehand is an extension. So put the acceptance criteria in writing — they settle every later discussion. Faults in third-party software are for its maker to sort out, not the agency.

You need a consent banner as soon as your website includes services that are not technically necessary — analytics, marketing pixels, embedded videos, map services, externally loaded fonts. The legal basis is Section 25 TDDDG, the German act on data protection in telecommunications and telemedia, read together with GDPR. A website that delivers only its own content from its own servers manages without a banner; that is possible more often than people assume. Refusing has to be as easy as agreeing. Judging the individual case is a job for your lawyer.

Marketing emails almost always need prior consent, documented by a double opt-in: sign-up, confirmation email, logged click with a timestamp. For existing customers there is a narrow exception under Section 7 UWG, the German Act Against Unfair Competition, tied to your own similar goods, a notice about opting out in every mailing, and an address collected in the course of a sale. On the technical side, sign-up, logging and unsubscribing are built so they can be proven later. Whether your case falls under the exception is for a lawyer to judge.

Behind Sharpness stands Sharpness Solutions GmbH, Edewechter Landstraße 161, 26131 Oldenburg, run by Andre Westphal and Oliver Dolleck (commercial register HRB 210156 at the Oldenburg district court, VAT ID DE 301 797 265). The team is made up of PHP developers and builds online shops with Shopware 6, websites with TYPO3 v14 and WordPress, interfaces and custom software with PHP 8, Symfony and Laminas. Planning, build and operation from one team. Contact: +49 441 21 21 63 0, info@sharpness.de, Monday to Friday, 9:00 to 16:00 CET.

Sharpness Solutions in Oldenburg has exactly one office: Edewechter Landstraße 161, 26131 Oldenburg. From there we run projects across the German north-west — Bremen and the districts of Ammerland, Friesland, Wesermarsch, Cloppenburg, Vechta, Leer, Emsland and Osterholz — and nationwide beyond that. There are no branch offices. If you need an agency with a permanent presence in your own town, say so before the project starts; for meetings in and around Oldenburg no travel time is charged.

Sharpness Solutions in Oldenburg works for M&S Armaturen, Autohaus Brüggemann, Heinje, Eschen Nutzfahrzeuge, Manotura, Lijnco with bank-formular.de, VRG, Nord Automobile, Dulle Mobile, AMR Wohnbau, Schaukelhelden, Diakonisches Werk Oldenburg (a Protestant church welfare organisation) and Küper Digital with plotplus, among others. The focus is B2B trade, industry, the motor trade and social-sector organisations — projects with stock management, product data and interfaces, not image-only websites.

An advertising agency owns brand, campaign and design; a digital agency builds and runs the systems behind them — online shop, CMS, interfaces to ERP and CRM, hosting. The dividing line is the question of who writes the code. For a Shopware 6 shop with an ERP connection or a TYPO3 v14 portal you need developers inside the agency, not planning alone. If your subject is advertisements, film and corporate design, an advertising agency is the better address. Sharpness Solutions in Oldenburg belongs on the technical side.

A project with Sharpness Solutions in Oldenburg runs in four steps: a first meeting to record what you need, a plan with an estimate of the work involved, the build in stages on a test environment, then launch and operation. You sign off each stage before it goes live. Planning, build and operation stay with one team, hosting on our own servers in Germany included. Moving into regular operation therefore involves no handover to an outside provider.

A fixed price suits a clearly defined scope; billing by time and materials suits projects whose requirements only sharpen during the build. Every fixed price carries a risk margin and makes changes expensive, because each deviation turns into a variation order. Billed by time and materials you pay only for the hours worked, but you carry the budget risk. The combination has proven itself: the planning phase by time and materials, then a fixed price against the specification you know by then. Sharpness Solutions in Oldenburg bills both ways.

Custom-developed code — modules, templates, configuration — should pass to the client by contract, so put code handover and access credentials in writing before the project starts. At Sharpness Solutions in Oldenburg the basis is open source in any case: Shopware 6, TYPO3 v14, WordPress, Symfony and Laminas each come under their own open-source licences, and for commercial editions and third-party extensions the vendor's terms apply. We hand over source code and access credentials at any time on request.

A reputable web agency names the people you will be dealing with, shows references you are allowed to name, and explains who writes the code and where it is hosted. Ask directly: is the work done in house or passed on? Do you get the source code and the access credentials? What does operation cost after launch? Is there a test environment before go-live? Who commits to updates for Shopware 6 or TYPO3 v14? Quotes that break the work down into person-days and name the systems are more reliable than a lump sum.

Yes, most of the project work is independent of location: requirements in a ticket system, interim results on a test environment, discussion by video call and telephone. Sharpness Solutions in Oldenburg looks after clients across the German north-west and beyond, largely remotely; on-site meetings in and around Oldenburg are possible without travel time. What matters is a fixed contact on the client side who supplies content and signs it off — projects founder on that more often than on distance. We are reachable Monday to Friday, 9:00 to 16:00 CET on +49 441 21 21 63 0.

A project starts with a call to +49 441 21 21 63 0 or an email to info@sharpness.de, Monday to Friday, 9:00 to 16:00 CET. Four details help us give a reliable assessment: the systems in use (shop, CMS, ERP), the goal of the project, the timeframe you have in mind and a rough budget range. Sharpness Solutions GmbH, Edewechter Landstraße 161, 26131 Oldenburg, comes back with questions and a proposal for how to proceed.

Quotes only become comparable once they describe the same scope — the breakdown of the work says more than the total at the bottom. Ask for person-days per item: planning, templates, data migration, interfaces, testing, sign-off. Check what is not in there as well: hosting, maintenance, licences for extensions, training, how variations are handled. A markedly cheaper quote usually contains less scope, not less margin. Ask which item is missing — the answer tells you more than any client list.

Three things sit with the client: a contact who is allowed to decide, content and data, and sign-off on time. In practice that means text, images, logos and product data in usable form, access to existing systems, and someone who can answer questions when pricing logic or processes need clarifying. Projects rarely slip because of the development; they slip on content that never arrives and on sign-offs nobody feels responsible for. Settle both before the kickoff, not during the build.

If a project runs late, the date is replanned as soon as the cause has been named — it is not quietly pushed back. Sharpness Solutions in Oldenburg works in stages on a test system you can reach at any time, so the current state stays visible and a delay shows up while its consequences are still small. The most common causes are missing content, open decisions on the client side, and counterparties who fail to deliver on interfaces. If you need a fixed go-live date, agree the scope and the consequences of missing it in writing before the project starts.

Sharpness Solutions GmbH is a small team of PHP developers in Oldenburg, led by two managing directors and registered to train apprentices under the German dual system. Every project is known to more than one person: code sits in Git, deployments and server configuration are documented, and access credentials do not live in a single mailbox. Cover is therefore possible without anyone having to work their way into an unfamiliar system first. The team is reachable Monday to Friday, 9:00 to 16:00 CET on +49 441 21 21 63 0.