Customer, partner and dealer portals
We build protected portals where your external users place orders, book appointments, retrieve documents and check the status of their requests without picking up the phone. Every role sees exactly the data released to it. The portal is designed and built by the two founders, and you talk to them directly.
Typical starting points
A portal does not fix an organizational problem, but it moves recurring back-and-forth to where customers and partners can handle it themselves. These are the situations we see most often.
Customers ask about delivery status, invoices or documents, and your inside sales team pieces the answer together from several systems. Each of these requests could be answered with a quick look at the portal.
Availability goes out as a PDF, orders come back by email and are re-entered by hand. In the Dealer Box we built for ADG Sales, authorized dealers filter in-stock, inbound and factory-order vehicles, add them to a cart and complete a validated purchasing flow.
In networks and associations, coordination depends on phone calls and personal contacts. In Praxisnetz Nürnberg Süd, medical practices, psychotherapists, medical care centers and hospitals publish available appointments centrally instead and book capacity at other members for specific patients.
External users share logins, permissions are granted on request, and when a partner leaves, their access stays open. That is a data protection and liability risk that grows with every new partner.
What we build
A portal is more than a login in front of existing data. We build these components depending on the user group and the process.
New users register with email verification, are invited by your team or are approved by an administrator. In Praxisnetz Nürnberg Süd, new members only gain access after administrative approval.
Validated flows lead from cart to contract document or from open slot to confirmation. In the Praxisnetz platform, race-safe booking logic prevents double bookings and automatically sends a confirmation to both the providing and the booking practice.
Contracts, order confirmations and invoices are available in each user's protected area. In the ADG Sales Dealer Box, purchase and contract documents are generated automatically during the purchasing flow.
Customers start subscriptions, buy credit packages and manage their payment details themselves. On PinnDeals, Stripe Checkout, Billing, the Stripe customer portal and signature-verified webhooks drive a tiered subscription and credit model.
Messages and questions happen where the case itself lives. PinnDeals supports anonymous listings and realtime chats in which both participants reveal their identity in a controlled way.
Your team sees what happens in the portal, approves users, maintains content and steps in when needed. At ADG Sales, the Distribution Box gives internal teams one place for dealer applications, distribution rights, price lists, logistics and aftersales cases such as warranty and support.
Approach
In a portal, the question of who may see what shapes architecture, security and acceptance. That is why we answer it first, not last.
We clarify which external and internal groups use the portal and which data each role may view, change or approve. This permission matrix is the basis for the data model and the interface, not a filter added later.
Together we decide how users get into the portal: self-registration with approval, invitation by your team or sign-in with an existing identity. This includes password reset, locking out users who have left and, if required, two-factor authentication. Not everyone needs an account: at ADG Sales, freight forwarders receive a secure link for individual jobs.
The most important flows, such as ordering, booking or retrieving documents, are built first and tried out with a few selected customers or partners. Their feedback shows where terms, steps or required fields do not match how they actually work.
External users cannot be trained like your own employees. We plan invitations, help texts and notifications so the first sign-in works without a phone call, and we open the portal to user groups step by step.
Technology
We usually build portals with Next.js or React and TypeScript, with Node.js frameworks such as Fastify or with Supabase in the backend. For sign-in, we use established services such as Supabase Auth or Amazon Cognito instead of building our own password handling. Payments and subscriptions run through Stripe with signature-verified webhooks.
We enforce the separation between customers as close to the data as possible: on PinnDeals, Row Level Security is enabled on every table, and database functions identify the user from the session only. At ADG Sales, permissions follow a matrix of domains, groups and individual rights, and every write request is logged with a before and after comparison. All data is transmitted encrypted.
Case studies
Three portals with very different users: authorized vehicle dealers, the members of a regional practice network and companies and founders looking for business partners. What they share is a clear role model behind the login.
Automotive IndustryADG Sales GmbH
An integrated platform for brand experience, dealer operations, vehicle commerce and aftersales
HealthcarePraxisnetz Nürnberg Süd e.V.
Regional appointment exchange for medical practices with specialty-based search, secure booking and automated billing
Business & MarketplacePinnProject GmbH
A reverse marketplace for expert requests, business partnerships, co-founders and business succession
Frequently asked questions
Mainly the number of roles, the self-service flows, the connections to your existing systems and the security requirements. That is why we do not quote a flat price. In a free 30-minute call, we assess the scope, and you then receive a transparent proposal covering approach, milestones and billing.
Yes, for most portals that is the core. The portal reads inventory, orders or customer data from your systems and writes orders or requests back. Our Integrations & automation page describes how we build these connections.
Every request checks on the server which organization and role the signed-in user belongs to, because filters in the interface alone are not enough. Where it fits, we also enforce the separation in the database, for example with Row Level Security in PostgreSQL. In Praxisnetz Nürnberg Süd, for example, only the two practices involved see the patient name on a booked appointment, and only its recipient sees an invoice.
A first version with sign-in, roles and one central self-service flow is typically ready within 3 to 6 weeks, depending on scope and integrations. Before opening it to all external users, we plan a pilot phase with selected customers. Further user groups follow step by step.
Yes, if data protection is built into the data model and permission concept from the start. We only collect the data the process needs, log access to sensitive records and, on request, host the portal in EU data centers. The legal assessment, such as records of processing or data processing agreements, stays with your data protection officer, and we supply the technical details for it.
Initial consultation
Bring a list of the user groups that currently call, email or request lists from you. In the free initial call, the founders sketch roles, core flows and the connection to your systems with you. We reply to your inquiry within 24 hours.
More services
Internal tools, dashboards and SaaS products that follow your processes instead of bending them. Designed and coded by the founders themselves.
Learn moreAPI integrations, ERP and accounting connections, PDF imports and automated jobs that move data reliably between your systems.
Learn moreWCAG 2.2 AA audits, fixes in the source code and automated CI checks for web apps, portals and online shops that fall under Germany's BFSG.
Learn moreBackend experience from Germany's ePA, an appointment platform for a practice network, and architectures that account for GDPR Article 9 and Section 393 SGB V.
Learn more