Choose language

Nothing here fits your case?

The four systems on this website are our own developments. Your particular case is built the same way: design first, a fixed price before the build, acceptance against criteria agreed in advance.

  • You are talking to the developer

Starting point

Four systems on this website, four in-house developments

Anyone commissioning a bespoke system is not buying a product but a promise. These four facts are why you can check it before you believe it.

  • 4 of 4
    systems on this website were developed here
    No bought-in third-party system with our label on it
  • Fixed price
    for the build is settled before the build starts
    It is based on a design you have read and approved beforehand
  • €5 million
    of public and product liability cover
    for personal injury and property damage — including on a project that has not existed before

Manual work

The most expensive process is the one nobody counts

For the big topics at a car wash there are off-the-shelf systems: till, subscriptions, access, accounting. For the rest there is Excel, bits of paper and word of mouth.

The rest is usually exactly what sets your business apart from others. The list of number plates that have come up as anomalies in your subscription scheme. The reconciliation between the point-of-sale system and the wash card that someone does by hand every morning. The monthly comparison across three sites, for which someone exports three reports and merges them in a spreadsheet.

That costs in two directions. First time, every day, unnoticed, because it never appears on an invoice. Second, decisions made on instinct rather than on data.

The usual answer is a standard package that fits your case eighty per cent of the way. You pay for the remaining twenty per cent every day afterwards: as double entry, as a workaround, as “we'll just carry on doing that by hand”. Which components exist at all and in what order it makes sense to add them is set out in our Digital car wash checklist (in German).

Run the numbers on your own assumptions

Take a process in your business that someone does by hand today. Set how often and for how long. The figures below are yours, not ours.

Your assumption, including employer costs. We do not preset an industry value here.

working hours per year

staff cost per year, fully loaded

These figures come from what you entered, not from our experience. They say what the process costs today — not what a build would save. How much of it can be automated is settled in the design phase, not on this page.

Process

From conversation to accepted system in three steps

The process is the same for every project, whether it turns into four weeks of work or six months. After each step you know more than before — and you can stop.

  1. Initial call and survey, on site where needed

    On the phone we establish what this is about and whether we are the right people for it. If we are, we come to your site: we watch the process in operation, take photographs and note the important details: which systems you already run and who looks after them. The initial call and first assessment are free of charge.

  2. Design phase with a fixed price at the end

    We write down what is to be built: which data comes from where, which interfaces are needed, where the limits lie, what is expressly not included — and what will be used to check, once it is finished, that it works. At the end of this phase there is a fixed price for the build and a schedule. The design phase is commissioned separately; its price is settled before it starts. The result is a document that belongs to you.

  3. Build, acceptance, operation

    Development, installation and commissioning by us. Acceptance is against the criteria from the design, at your site, in live operation — not on a demonstration setup. After that we take on operation: round-the-clock remote monitoring, a four-hour target response time for critical faults, an annual on-site inspection.

No money changes hands between step 1 and step 2. Between step 2 and step 3 you decide with a design in your hands — not with a brochure.

Project types

Four kinds of project for which there is no standard product

We show no customer projects here. Instead, four kinds of project and, for each, how we would go about it. If your case appears among them, you know before the first phone call what to expect. If it does not, tell us yours — the approach stays the same.

Type A

Two systems that know nothing about each other

Starting point: Your ANPR knows which vehicle came in. Your point-of-sale or subscription system knows who paid. Each knows it separately. So someone reconciles them by hand in the morning, or nobody does — and one subscription washes three vehicles.

  • Approach: First we establish whether your existing system will release what we need at all. Then we define the matching rule with you: what counts as an anomaly, from what frequency, in what time window.
  • Result: A daily list of anomalous records that someone goes through in five minutes in the morning.
  • Timeframe: Design two to three weeks, build four to eight weeks.
  • What we say up front: If your existing system has no interface and the supplier will not open one, this route is closed. We establish that during the design phase — not after the deposit.
Type B

You notice the failure when it is already there

Starting point: A brush motor fails, a bearing runs hot, a pump loses pressure. It is noticed when the wash has stopped — in the middle of Saturday morning. You know consumption as a monthly bill, not as a trend.

  • Approach: We define which points are measured, retrofit the sensors and let them only record at first. The threshold values come out of that reference period — out of your site, not out of a manual.
  • Result: A trend instead of a snapshot, an alarm when something deviates, comparable consumption figures.
  • Timeframe: Design two to three weeks, installation and first data four to six weeks, reliable thresholds after two to three months.
  • What we say up front: In the first weeks this system delivers data, not predictions. Anyone who promises you a failure forecast on the day of commissioning has guessed the thresholds.
Type C

Vehicles that should never have been let in

Starting point: Roof racks, open windows, a raised spoiler, a model that is incompatible with your brush configuration. It is noticed inside the tunnel. After that it is a damage claim.

  • Approach: The basis is a camera at the entrance. First we collect image material from your site over several weeks, then we train the recognition on our own servers. What the GDPR requires for camera and number plate data is set out in our guide CCTV and the GDPR (in German).
  • Result: A warning before the entrance instead of a damage claim after the wash — and photographic evidence for a dispute.
  • Timeframe: Realistically four to six months in total, of which six to eight weeks are for collecting image material alone.
  • What we say up front: A detection rate cannot credibly be promised before training. So it becomes one of the acceptance criteria — measured against a test data set from your business that we set aside before training.
Type D

Three sites, three logins, one gut feeling

Starting point: You run several sites. Each has its own systems, its own logins and its own way of counting. A comparison between sites is produced today in a spreadsheet, by hand, once a month, and is already out of date on the day it is finished.

  • Approach: A survey per site, then a shared layer — normally based on our cloud platform, because user management, roles, encryption and export are already solved there. We start with one site and only roll out once that one is running cleanly.
  • Result: One login, one set of metrics, comparable across sites, with roles and permissions for your site managers.
  • Timeframe: Design three to four weeks, first site six to ten weeks, each further site one to two weeks after that.
  • What we say up front: With several systems our volume discount applies — that covers the running costs, not the development share.
Included

Work that belongs to a project but is not one in itself

Almost every project involves infrastructure: the network connection between the control cabinet and the equipment room, switches, cabling in the tunnel, running the server. We handle that as well and itemise it separately in the quote. We also run websites and mail servers as part of an existing working relationship.

And this is what we turn down

What we do not build

  • Point-of-sale, subscription and accounting systems. There are good standard products for those. We connect to them, we do not replace them.
  • The PLC programming of your wash. That stays with your PLC contractor and is included in none of our prices.
  • Safety-related control technology. Our systems monitor, report and intervene. Emergency stop, guarding and the wash controller itself remain the responsibility of your wash manufacturer.
  • Mechanical conversion or new build of the wash. We retrofit; we do not build tunnel car washes.
  • Projects with no checkable result. If it cannot be put into words how everyone will recognise at the end that it works, we say no. That is not modesty but experience: such projects never get finished.

A look inside

What you see here was built in this office

Footage from our own systems. None of it is bought in, none of it is a relabelled third-party product. If you want to know what we can build, here is what we have built.

Vehicle tracking in the tunnel

Several vehicles in the tunnel, each tracked individually. The critical moment is not the single vehicle but the gap between them — and that is exactly what is known here at all times.

Cloud platform dashboard with maintenance lists, stock levels and activity

The platform behind it

Maintenance lists, stock levels, consumption and activity in one interface. User management, roles, encryption and export are already built here — which is why many projects build on it rather than starting from scratch.

There is no other process between these systems and your project. It is the same one: design, fixed price, acceptance, operation.

Benefits

A system that follows your process, not the other way round

You pay for the part you use

A standard package comes with modules your business never opens, and charges for them monthly all the same. With a custom build, what gets made is what is in your design — and nothing beside it.

No double entry

When a system does not fit the process, staff enter the same thing twice: once into the system, once onto the piece of paper that is actually used. A system that follows the existing process does not need that second route.

Your data stays readable, even without us

What is created in our systems can be exported to open formats — not on request, but at any time from the interface. Changing supplier costs you negotiating time, but not your history.

One point of contact for survey, build and operation

Whoever saw the site writes the design. Whoever wrote the design builds it. Whoever built it answers the phone when something is not working. There is no handover at which knowledge gets lost.

Scope

Is this your route? A custom build is right for you if you have a process that none of our four systems covers — and if you can describe how anyone would recognise that it works. If your case does fit one of the four systems, that one is cheaper and ready in weeks rather than months. Which of the two applies, we will tell you in the initial call — including if the answer is that you do not need us for it.

Risk questions

What happens if it does not work

What does this cost? I need a ballpark before I call.

We do not quote an entry price here, and the reason is not tactical. With a custom build the scope determines everything: reconciling two existing systems is a different undertaking from image recognition that has to be trained on your entrance. A figure on this page would be nonsense in one case and misleading in the other.

What you get instead: the initial call and the first assessment cost nothing. After that comes the design phase as a separate, deliberately small engagement with a price fixed in advance — and at the end of it there is a fixed price for the build. So you only decide on the large sum once you have a document in your hands, not before.

Who owns the source code in the end?

The design document is yours — it is produced under a separately commissioned step and remains yours even if you go on to work with someone else. For the software: you receive the right to use the finished system. If you need rights to the source code beyond that — because your group requires it, for example — say so in the initial call. That is negotiable, but it affects the price, and we would rather settle it beforehand than at acceptance.

What is used to measure whether the result is right?

Against the acceptance criteria from the design, and we write those down together beforehand. They are the most important part of the document — more important than the functional description. A criterion is usable if two people would independently reach the same verdict: “The list contains every record in which the same number plate appears more than twice within 24 hours” can be checked. “The system should run reliably” cannot.

Acceptance takes place at your site in live operation, not on a demonstration setup. If the system does not meet the agreed criteria, it is not accepted.

What if the requirements change during the build?

Then the fixed price changes, and we say so immediately rather than at the end. Changes against the design are recorded in writing, with the effort and the effect on the schedule — you then decide whether they happen now, later or not at all. What we do not do: build them in quietly and hand you the bill afterwards.

The most common case is a different one, incidentally: during the build it turns out that a planned function is unnecessary. That deserves saying too.

How long does something like this realistically take?

The design phase takes two to four weeks. The build ranges from four weeks to several months — the project types above give a concrete range for each case. What regularly takes longest is the thing that does not look like work: collecting reference data. Image recognition needs weeks of material from your site, condition monitoring needs a reference period before threshold values are worth anything. Skipping that time delivers faster and worse.

Who maintains the system once the project ends?

We do, under a service and maintenance contract: round-the-clock remote monitoring, a four-hour target response time for critical faults, an annual on-site inspection. The contract runs for twelve months per system from commissioning and can then be cancelled with three months' notice to the end of the month. So you are not tied to the decision indefinitely.

Can you extend an existing system instead of building a new one?

Most of the time that is exactly the cheaper route, and we suggest it ourselves. Whether it is possible is not for flowcontrol to decide but for the supplier of your existing system: is there a documented interface, database access or at least a regular export? That question comes first in every design we write, because the whole undertaking depends on it. If the answer is no, we tell you during the design phase — not after the deposit.

Next step

Describe the process, not the solution

For the first conversation you need no idea of how it should work technically. Four details are enough — we do the rest.

  1. Which process is done by hand today and who does it
  2. Which systems are already in use at your site and who looks after them
  3. How you would recognise that the project had succeeded
  4. By when it needs to be running — and why then in particular

You speak directly to the developer and owner, not to a call centre. The initial call and first assessment cost nothing — and if your case fits one of our existing systems, we will tell you that instead of selling you a build.

Available Monday to Friday, 9am–4pm · info@flowcontrol.de