Software development
A portal where customers check status, documents and invoices themselves, connected to your ERP and secure by design.
Updated November 2026
You’ll talk to the engineer who will build your project.
We work exclusively with businesses and self-employed professionals. All offers exclude VAT.
Datafalke, based in Bottrop, Germany, builds customer portals for B2B companies. Your customers log in to see order status, documents and invoices without having to ask your team. The data comes from your enterprise resource planning (ERP) system through an API or a regular sync. After a discovery sprint, we build your portal at a fixed price.
The portal is a web app that runs in the browser, on computers and smartphones alike. We plan the first release around the questions your customers ask most often, and more features follow based on your priorities. For processes that only involve your own team, custom business software is the better fit. We work remotely across Germany and the EU, and in person in the Ruhr area.
Software development overviewAll servicesEach user gets their own account, ideally with a second factor or a passkey. If you’d like, larger customers can log in with their company account.
Orders, deliveries or service cases with their current status as your ERP records it, plus the time of the last update.
Packing slips, inspection reports, certificates and invoices to download, each visible only to the customer company it belongs to.
Roles within each customer company control who sees what. Optionally, one person there manages access for their colleagues.
Data comes from your ERP or CRM system via API, file export or messages. We check what your system supports before we quote a fixed price.
Your team can see who has which access. The portal records logins and denied access attempts.
A customer portal is suited to recurring requests whose answers are already in your systems, such as where a delivery is, where to find an inspection report or which invoices are open. Your customers find the answer in the portal without anyone on your team having to search. The examples show typical uses by industry, not client projects.
Delivery status, packing slips and invoices
Inspection reports, certificates and other evidence for customers
Property logs, inspection records and damage reports
Maintenance appointments and inspection records for commercial customers
There are four basic approaches: a regular file export, queries through an API, messages on every change and direct database access. Which one fits depends on what your system offers and how current the data in the portal needs to be. We check this in the discovery sprint, before we quote a fixed price.
| Approach | How the data gets into the portal | How current | Keep in mind |
|---|---|---|---|
| File export | Your system saves a file at fixed intervals, for example as CSV or XML, and the portal imports it. | As current as the last export | Doesn’t need an API. The portal has to detect and report incomplete or faulty files. |
| API queries | The portal queries your system directly whenever it needs data. | Current, as long as your system responds | If your system is unreachable and the portal keeps no copy, the data is missing. Some APIs limit the number of requests. |
| Messages on change | Your system reports every change, such as a new delivery status, and the portal applies it. | Shortly after each change | Your system has to be able to report changes. The two systems don’t have to be running at the same time. |
| Direct database access | The portal reads your ERP’s database itself. | Current | Ties the portal to your ERP’s internal structure, so an update can break the integration. We advise against it as long as there’s another option. |
The four approaches correspond to the integration styles that Gregor Hohpe and Bobby Woolf describe in Enterprise Integration Patterns (external site). A portal can combine them, for example with invoices from a nightly export and delivery status via messages.
Microsoft’s Business Central online handles up to five OData requests per user at once and accepts 6,000 in five minutes. If the portal uses one account, all its users share these limits.
Source: Microsoft (external site), · Operational limits, per-user limits
If the portal keeps a copy, it shows the last known data and when it was updated. Level 2 of the OWASP ASVS security standard requires apps to keep operating securely when external services fail.
We recommend a first release that only displays data. When customers want something changed, such as their delivery address, your team gets a request first.
Each customer company sees only its own data, and each person within it sees only what their role allows. We set out these rules in a role-based access plan before development starts. The portal checks them on the server with every request, because a restriction that only applies in the user interface can be bypassed.
Broken access control ranks first in the OWASP Top 10:2025 (external site). Typically, someone changes an ID in a request and retrieves another customer’s documents.
Optionally, one person per customer company invites colleagues and assigns their roles, so purchasing sees invoices and engineering sees inspection reports.
If you’d like, larger customers can use single sign-on via SAML 2.0 or OpenID Connect. Once their employer disables an account, that person can no longer log in.
Your staff get roles too. Someone in customer service who answers questions doesn’t need to be able to grant access.
Even at Level 1, OWASP ASVS 5.0 (external site) requires these rules to be documented and enforced on the server. Accounts can also be created and disabled automatically if your customer’s user directory supports SCIM (external site), an IETF standard. Our explainer on multi-tenant SaaS architecture covers how software keeps the data of many customer companies apart.
Before development starts, the security plan defines how users log in, how the connection is encrypted, what the portal logs and how updates are installed. The OWASP Application Security Verification Standard (ASVS) 5.0 provides a basis with its requirements for secure web applications. We build privacy in from the first draft; the legal assessment belongs with a lawyer.
The ASVS requires it starting at Level 2, which the standard says most applications should aim for. That means a password alone isn’t enough.
The BSI (external site) (in German), Germany’s Federal Office for Information Security, considers passkeys immune to the vast majority of known phishing attacks. We recommend them for logging in.
The plan defines how someone replaces a lost second factor. Under the ASVS, a password reset must not bypass the second factor.
The portal is only reachable over encrypted connections, preferably TLS 1.3, as the BSI’s technical guideline TR-02102-2 (external site) recommends. The guideline recommends TLS 1.2 only until the end of 2031.
The portal records logins, including failed ones, and denied access attempts, without passwords or document contents. The plan defines which events alert your team.
As part of software care, we install security updates for the components in use. The portal only receives the data your customers need there.
We disclose every service that processes data, such as an email delivery service. Our software development page explains which documents you can show your customers when they ask for evidence of supply chain security.
You can check for yourself how we secure connections on our own website. Our site, datafalke.de, redirects every request to HTTPS and tells your browser to open it only over an encrypted connection (HSTS). It also sends a Content Security Policy that defines what the browser may load and run. Our colophon describes the technology and hosting.
Customer portal development starts with a conversation, by video or in person at your office if you’re in the Ruhr area of Germany. It’s free, and you talk directly to the engineer who will build your portal.
We work out which requests the portal takes over first, which data comes from which system and how your ERP can be connected. We also define the roles and the security plan, and we build a clickable prototype.
We first build the minimum viable product (MVP), a first usable version that covers the most frequent requests, and show you where things stand every week. The code is in your repository from the start.
You review the portal against the criteria we agreed on in writing, with a few of your customers first if you’d like. At sign-off, you receive the documentation and the software bill of materials.
After that, if you’d like, we keep looking after the portal and add features based on your priorities, such as writing data back to the ERP. Your team or another provider can also take over.
We built, ran or documented these examples for our articles. The PostgreSQL example uses test data rather than client data.
All examples come from our own project or from test data. None of them comes from client work.
You can carry on without us if you need to. Code, hosting account and domain are under your control from day one, and every sign-off includes documentation another team can work from.
Repository, cloud account, domain and credentials are in your name. We work with delegated access.
Architecture docs (arc42, C4), decision records, an operations manual and a software bill of materials (SBOM) come with every sign-off.
If we part ways, we hand over all documentation to your team or new provider. Your contract sets out how the handover works.
We use widely adopted open-source frameworks, not homegrown tools only we understand.
Mohammad Alboush is a software engineer and the owner of Datafalke. He’s your direct line to the team, from the intro call to sign-off. He replies to requests within one business day (Monday to Friday).
We quote the fixed price for your portal after the discovery sprint, once the integrations, roles and scope of the first release are clear. The sprint is a paid entry offer with its own deliverable, and we tell you its price before you place an order. The factors that drive the fixed price are listed below the packages.
Founders and companies with a product idea
Price in your quote
Excl. VAT, business clients only
Companies that want their customers to see status, documents and invoices online
Fixed price after discovery
Excl. VAT, business clients only
Software care S covers updates, monitoring and two hours of work a month, for at least three months. Software care L is by agreement. Changes outside the fixed price start only once you approve them.
We work exclusively with businesses and self-employed professionals. All offers exclude VAT.
For many portals at mid-sized companies, no; for some, yes. We’ll tell you which applies to yours in the intro call. We build in clearly scoped stages with written acceptance criteria. Every project is led by software engineer Mohammad Alboush, who heads our team, and you talk to him directly. If a project needs a large team from day one, we’ll point you to a better-suited provider.
Then we look at the other ways to connect it. If your system can export data as files, for example as CSV or XML, the portal imports these files at fixed intervals. Your customers then see the data as of the last export, and the portal shows when that was. We confirm in the discovery sprint whether an approach works for your system, before you get a fixed price.
If it covers your processes, yes, and then we’ll recommend it. That’s the first thing we check in the discovery sprint. A portal of your own makes more sense when data comes from several systems or your customers need their own roles and approval steps. The same goes if license fees rise with every customer account. Our comparison Build vs. buy software explains how to weigh the two.
You’ll know the price of development before it begins, because we quote a fixed price after the discovery sprint. Changes are made only through a written change request that states the price, and you see the budget status in every weekly demo. Your quote sets out the payment terms.
We build privacy and security in from the start; the legal assessment belongs with a lawyer. The portal comes with role-based access, an encrypted connection and logging as defined in the security plan, and for logging in, we recommend multi-factor authentication. We disclose every service that processes data.
In your own cloud account, with a provider of your choice, preferably EU-based and under a data processing agreement (DPA). We set up the account with you and work in it with delegated access. The data itself is still maintained in your ERP; the portal only holds what your customers should see there.
You invite your customers by email, and they set up their account the first time they log in. It’s a good idea to start with a few customers and build in their feedback before you invite everyone. Email and phone stay available alongside the portal.
Cost guide · SaaS & software
What custom software development costs: euro price ranges for web apps, customer portals and SaaS, hourly rates, maintenance and the main cost drivers.
Comparison · SaaS & software
Off-the-shelf or custom? Five-year costs, flexibility, lock-in and data control for small and mid-sized companies, with a decision tree and worked examples.
Explainer · SaaS & software
Multi-tenancy means one app serves many customers, with their data kept apart. The three isolation models, their trade-offs and what German authorities expect.
What datafalke.de is built with: Astro, static HTML with zero JavaScript, self-hosted fonts, storage in Frankfurt. Plus every license and image credit.