What is a B2B portal, and how is it different from an online shop?
A B2B portal is a password-protected website where known business customers do repeat business with you: they see prices agreed for their company, order again, ask for quotes, track deliveries and fetch documents. An online shop sells to anyone at a list price; a portal serves accounts you already have.
That difference drives everything a b2b portal development company has to design. In a consumer shop the hard part is persuading a stranger to buy. In a trade portal the buyer already wants to order; the hard part is showing them the right net price for their customer group, the right minimum order quantity, the right delivery address among their twelve sites, and letting their purchasing manager approve the basket before it reaches you.
For German manufacturers and wholesalers the portal usually replaces three things: orders sent as PDF or by fax, sales staff answering "where is my delivery" by phone, and the shared drive of datasheets that customers email in to request. Getting those off the phone and inbox is where the time saving comes from.
- Customer portal: direct trade customers reorder and self-serve
- Dealer or distributor portal: resellers order, register projects and download marketing material
- Service portal: installers and technicians log tickets, returns and warranty claims
- Supplier portal: the reverse direction, where your suppliers confirm orders and upload documents
When does a German manufacturer or wholesaler need a B2B portal?
You need one when repeat orders from known customers make up most of your revenue and your inside sales team spends its day typing them in. Signs are easy to spot: order confirmations are retyped from emails into the ERP, customers call for prices they could look up, and the same certificate is sent by email dozens of times a month.
You probably do not need one yet if you have a handful of large accounts who order through EDI already, or if every order is a unique engineered project that goes through a sales engineer anyway. In that second case a structured RFQ form on your public website, covered on our manufacturing website design page, often brings more value than a full portal.
A good test before you contact any b2b portal development company: pull three months of orders and count how many were repeat purchases of catalogue items. If that share is high, a reorder portal pays for itself in saved typing hours. If most orders are one-offs, start with quotes and documents, and add ordering later.
Core features a B2B portal development company should deliver
The feature list decides the budget, so it is worth being precise. Release one should cover what buyers do every week; extras can wait for release two. These are the features we treat as the core of a trade portal for the German market.
Customer-specific price lists
Net prices per customer or customer group, quantity breaks, contract prices with validity dates and surcharges such as alloy or energy surcharges, all read from the ERP rather than maintained twice.
Quick reorder
Reorder a past order in one step, paste article numbers with quantities, upload a CSV, or keep saved order lists per site. Buyers who know their article numbers want speed, not browsing.
Quotes and RFQs
A buyer builds a basket or uploads a drawing, asks for a quote, and your sales team answers inside the portal. An accepted quote turns into an order without retyping.
Delivery and invoice visibility
Order status, delivery notes, tracking links and invoices as PDFs, pulled from the ERP so your team stops answering status calls.
Documents per product
Declarations of conformity, operating manuals, safety data sheets and CAD files, shown on the product and in a library filtered by what the customer bought.
Service and returns features are covered further down, because they involve different teams in your company.
How should roles and approvals work for buyer companies?
Model the customer as a company with people inside it, not as a single login. A mid-sized buyer typically has a purchaser who builds baskets, a manager who approves orders above an internal limit, and an admin who adds colleagues and delivery addresses. Your portal should let each buyer company run that itself.
The usual model has three customer-side roles. The purchaser can browse the assigned catalogue, build baskets and request quotes. The approver sees baskets waiting for release and can approve, edit or reject them. The admin manages users, cost centres, delivery addresses and approval limits for their own company. On your side, sales reps can act on behalf of a customer, and a service role sees tickets but not prices.
Approval rules are where portals get complicated. Some buyers want every order approved; others only above a limit per cost centre; a few want two approvers for capital goods. We build the rules as data the customer admin can change, rather than hard-coding them, and we log every approval with user and time so disputes can be settled from the record.
Shopware's B2B Components include employee management, budgets and order approval out of the box, and Shopify's B2B tools add company profiles with their own locations and buyers, with more of the B2B feature set reserved for Shopify Plus. If your approval logic fits what they offer, that saves real money; the build-vs-buy section below goes through the trade-offs.
Which ERP systems can a B2B portal sync with?
Any ERP that exposes an API or can export and import files can be connected; the work lies in agreeing what flows where and how often. The systems German Mittelstand clients most often run are SAP Business One, Microsoft Dynamics 365 Business Central, weclapp and, for online-heavy wholesalers, JTL-Wawi.
For each system we map the same five objects: customers and contacts, articles and stock, price conditions, orders, and documents such as delivery notes and invoices. SAP Business One offers a REST-style Service Layer, Business Central exposes OData and REST APIs, and weclapp has a documented REST API. JTL-Wawi setups usually connect through JTL's own interfaces or a middleware. Where no API exists, a scheduled file exchange still works if both sides agree on the format.
The decision that matters most is which system owns each field. Prices and stock should be mastered in the ERP and only read by the portal. Orders are born in the portal and pushed to the ERP. Contact persons are often edited in both places, so we agree a rule and write it down. A b2b portal development company that skips this step creates duplicate customers within a month.
- Sync frequency per object: live lookups for price and stock, batches for catalogue changes
- Error queue with retry and an alert email when an order fails to reach the ERP
- A staging copy of the ERP, or at least test clients, before anything touches production
Build or buy: Shopware B2B Components, Shopify B2B or a custom B2B portal?
Buy when your processes are close to what a platform already does; build when your pricing, product structure or approval logic is unusual enough that you would fight the platform every week. Many projects end up in between: a platform for the catalogue and checkout, custom modules for the unusual parts.
Shopware's B2B Components are available from its Evolve plan upward, according to Shopware's documentation, and cover roles, budgets, approvals, quick order and quotes. Since April 2026, Shopify has offered its basic B2B features (company profiles, up to three custom catalogues, volume pricing and payment terms) on the Basic, Grow and Advanced plans, while catalogues assigned directly to individual companies stay a Plus feature, according to Shopify's help centre. Both carry recurring platform fees, both are strong at catalogue and checkout, and both assume your data fits their model.
A custom portal costs more up front, starting at US$900 with us, but has no per-seat or per-order licence and can follow your ERP's price logic exactly. It suits firms with configurable products, project pricing, or several ERPs after acquisitions. The table below sets the three options side by side. If you are unsure which shop platform fits a German merchant in general, our Shopware vs Shopify comparison goes deeper.
How much does a b2b portal development company charge in Germany?
What a b2b portal development company charges depends far more on integrations and workflows than on page count. With BtechWaleTech a custom portal starts at US$900 and a platform-based B2B shop at US$750; both are starting prices, and the itemised quote shows how your scope moves them. Quotes from German agencies and other offshore vendors vary widely, so compare scopes line by line rather than headline numbers.
The biggest cost drivers, in the order we usually see them: the number of systems to sync and how clean their data is; the number of price rule types (customer prices, group discounts, quantity breaks, surcharges, promotions); the number of workflows beyond ordering (quotes, approvals, RMA, service tickets); the product structure, especially variants and configurable items; and migration of existing customer logins.
Running costs are separate and belong in your budget from day one: EU cloud hosting billed by the provider to your card, any platform licence, monitoring, and maintenance after the free two months, from US$120/mo. Our page on software development cost in Germany explains how to budget total cost of ownership over several years.
Why hire a remote team in India instead of a local b2b portal development company?
The honest reason is budget per feature: the same portal scope usually costs less when built by a small remote team in India, so you can fund release two sooner. The honest trade-off is that you will not get on-site workshops, German-speaking developers or a local legal entity.
What makes remote work succeed on a portal is structure, not geography. We work from a written scope with acceptance criteria per feature, show progress on a staging portal every week, and keep the code in your repository so you can see every change. Your team tests with real customer accounts before launch.
Working hours overlap well. India runs on IST, three and a half hours ahead of German summer time and four and a half ahead in winter, so a 09:00 call in Stuttgart is early afternoon for us, and your whole morning is shared working time. Invoices come from India in USD or EUR and are paid by Wise or bank wire. For a wider view of the model, read offshore software development for German firms.
GDPR and EU hosting: what your b2b portal development company should set up
A B2B portal still processes personal data, because buyer accounts belong to named people with email addresses and phone numbers. So GDPR applies, and the build should support your obligations from the start: data in an EU region, access limited by role, and a record of who did what.
We deploy into a cloud account owned by your company, typically in AWS's Frankfurt region or another EU region you prefer, so the data and backups stay in the EU. India has no EU adequacy decision, which is why, when our developers need access to production data for support, your data protection adviser will usually want a data processing agreement and Standard Contractual Clauses in place. The European Commission lists the countries with adequacy decisions.
In practice we reduce what we can see: test data for development, masked copies where a production-like dataset is needed, named accounts rather than shared admin logins, and audit logs you can review. Compliance remains your responsibility, confirmed by your own counsel; our job is to build a portal that makes it easy. The wider checklist is on GDPR compliant website.
Document self-service, returns and service tickets
Self-service documents and after-sales workflows are often where a portal saves the most staff time, because they generate constant small requests. A buyer who can download the right declaration of conformity at 22:00 does not email your quality team the next morning.
Document library
Declarations of conformity, operating manuals, safety data sheets, test certificates and CAD files, tagged by article and version. Buyers see documents for the products they bought; public ones stay public for search engines.
Certificates per batch
Where you issue material or inspection certificates per delivery, the portal can attach them to the delivery note so the buyer finds them with the order.
RMA and returns
The buyer picks the order line, reason and quantity, uploads photos, and receives an RMA number and return label instructions. Your team approves or queries inside the portal.
Service tickets
Installers log faults against a serial number, attach photos and follow the ticket status. Tickets can create a spare-parts order in one step.
Safety data sheets for substances and mixtures follow the REACH format, so they are best generated by your compliance tooling and only published by the portal, not rewritten by it.
Which tech stack should a b2b portal development company use?
Pick the stack your future developers can maintain, not the fashionable one; any b2b portal development company should be able to justify its choice in plain words. For custom portals we typically use a TypeScript front end (Next.js or a similar React framework), a Node.js or Python back end, PostgreSQL for portal data, and a search index for large catalogues. For platform builds we use Shopware 6, which runs on Symfony and Vue, or Shopify with custom apps.
A few technical choices matter more than the framework. Price calculation should happen server-side and be cached per customer, because the same article can have dozens of prices. Every ERP call should go through a queue so a slow ERP does not freeze the portal. Search should understand article numbers, old article numbers and manufacturer numbers, since trade buyers search by code, not by product name.
We document the architecture, write automated tests for price and approval rules, and set up deployment pipelines in your GitHub or GitLab. That way another team, or your own hire, can take over without guessing. If you later want a mobile app for field staff, the same API serves it.
How should a b2b portal development company run the project, week by week?
A first release takes 6–12 weeks with us, depending on integrations. The discovery work at the start is what keeps that number honest, so it is never skipped.
- Weeks 1–2: workshops by video, process maps for ordering, quotes and approvals, ERP field mapping, written scope and acceptance criteria
- Weeks 2–3: clickable prototype of the buyer journey, reviewed by your inside sales team and two friendly customers
- Weeks 3–8: build in two-week sprints with a demo each time; ERP connector tested against a test client
- Weeks 8–10: pilot with a small group of real customers, fixes, data migration rehearsal
- Launch: customer invitations in batches, monitoring of the order queue, daily check-ins for the first two weeks
Want the same team on hand for continuous development after launch? Read about a dedicated development team.
How should a b2b portal development company plan the customer rollout?
A portal only saves time if customers log in, so a b2b portal development company should help you plan the rollout like a product launch, not an IT switch-over. Start with customers who already order often and complain about calling in.
Invite in batches of a manageable size, with a short welcome email explaining the three things they can now do alone: see their prices, reorder, and download documents. Give sales reps an "act as customer" view so they can walk a buyer through the first order on the phone. Keep phone and email ordering open during the transition, but route those orders through the portal internally so history builds up in one place.
Measure adoption by active buyer companies per month and by the share of orders arriving through the portal, both visible in a simple dashboard. If a key account refuses to switch, ask why; often the answer is a missing feature, such as their own article numbers, that is quick to add.
Red flags when choosing a b2b portal development company
Most failed portal projects fail on data and scope, not on code. Watch for these warning signs in proposals, whoever sends them.
- A firm total price named before anyone has seen your ERP price conditions
- No mention of which system masters prices, stock and customers
- Portal hosted in the vendor's own account with no transfer plan
- Code, repository or cloud account not in your company's name
- A demo of a generic shop presented as a portal
- No test plan for price rules and approvals
- No named person responsible for the ERP connector after launch
- Promises of Google rankings for a login-only portal, which search engines cannot see anyway
A trustworthy b2b portal development company will ask about your ERP before it talks about design. If the first call is all screens and no data, slow down.
Should a B2B portal be visible to Google and AI search?
The logged-in part should not be indexed; the public catalogue and documentation often should. Buyers and engineers research on Google and increasingly in AI assistants before they contact a supplier, so product pages, specifications and application notes are worth publishing openly while prices stay behind the login.
We structure public product pages with clean URLs, product schema without prices where prices are private, hreflang for your language versions and fast pages that pass Core Web Vitals. Datasheets are published as HTML summaries with the PDF attached, because plain text is easier for search engines and AI systems to read and cite than a scanned PDF.
Google Search Console is set up in your company's account at launch. Nobody can guarantee rankings, but a well-structured public catalogue gives buyers a reason to find you first. For larger catalogues, an SEO-first build starts at US$300, and ongoing work at US$150/mo.
Worked example: a hypothetical fittings wholesaler moves reorders online
This is an illustration, not a client story. Say a family-owned wholesaler of pipe fittings near Karlsruhe serves several hundred installer businesses. Orders arrive by email and phone, prices are negotiated per customer in SAP Business One, and staff email the same installation manuals every day.
We would propose a custom portal starting at US$900. Release one: buyer companies with purchaser and admin roles, prices read live from SAP Business One's Service Layer, reorder from history and a paste-your-article-numbers box, delivery status from the delivery notes, and a document library per article. Approvals are left out because most installers are small firms with one buyer.
Release two, after a pilot with a small group of regular customers, would add quotes for project orders and an RMA form. Hosting runs in the wholesaler's own AWS account in Frankfurt. The sales team keeps taking phone orders but enters them through the portal's "act as customer" view, so all history sits in one place. Two months of free maintenance cover fixes while the portal settles.
Working with a remote team in India from Germany: the first two weeks
The first fortnight decides the tone of the whole project, so here is exactly what happens. Day one is a video call with your project owner, someone from inside sales and ideally your ERP admin. We ask to see how an order moves today, from email to ERP to delivery note.
By day three you receive a written scope with open questions, and within about two working days after that an itemised quote. Once you approve it in writing and the agreed terms are on paper, we create the repository and cloud account in your name, and get read access to a test client in the ERP.
Week two brings the first clickable prototype and the field mapping document. Calls happen during your morning, usually two short ones a week; day-to-day questions go to WhatsApp or your Teams or Slack channel. Invoices come from India in USD or EUR, paid by Wise or bank wire, and nothing is billed before written approval. Our team speaks English and Hindi; German interface text is supplied or approved by you. Contract questions go to our terms or your written quote.
Checklist before you brief a b2b portal development company
Prepare these items and any serious vendor can quote you accurately in days rather than weeks. Missing items are fine; knowing they are missing is what matters.
- Which ERP and version you run, and who administers it
- Your price logic: customer prices, group discounts, quantity breaks, surcharges
- Number of buyer companies and typical users per company
- The workflows you want in release one, ranked
- Documents you want to publish and where they live today
- Languages needed for the portal interface
- Who approves the scope and who tests before launch
- Your hosting preference and data protection contact
Send what you have on WhatsApp or via our contact page; we will tell you what else we need.