It is a website
- Strangers should find you and form an impression
- Enquiries arrive through a form or WhatsApp
- There is no login and no permissions
- Every visitor sees the same thing
WAMOCON business systems
Your operation runs. On spreadsheets, in chat threads, on sticky notes and in three heads.
Nobody knows exactly how — and while that holds, your company belongs to whichever tools happened to be lying around. We build the system where its processes finally get a fixed home. And we do not start with software, we start by watching how you work.
- GDPR · DPA
- Servers in the EU
- The source code is yours
- Test management to ISTQB
Schematic: a workspace that can be connected to a field view, a customer portal and a reporting board.
Connect the areas one by one
Five sentences that get said too often
If you recognise even one of them from your own company, keep reading.
- In someone’s head “Only one colleague can do that, and he is back on Monday.”
- In a chat thread “Who actually approved that discount?” — and the answer is in a chat thread.
- In the spreadsheet Three lists with the same customers, and not one of them is quite right.
- Nowhere New hires need weeks to learn the process — because nobody ever wrote it down.
- In the folder Once a year somebody hunts down records that should have been together all along.
None of this is laziness. It is how every company grows when it outgrows its tools.
The difference day to day
What changes once the processes have a home
The software is not the benefit. The benefit is six situations that cost time and nerves today and stop being a question afterwards.
Without a system With a business system
The overview Three lists with the same customers, and none of them is quite right. Anybody who needs the truth phones somebody. One record set, one truth. Whoever needs it sees it, within what their role is allowed to see.
When somebody is away The case waits for a person. “Only one colleague can do that” is an operational risk with a first name. The case waits for a role. Cover is designed in rather than improvised, and the process keeps moving.
When somebody asks A search through chats, inboxes and folders. What comes out is a recollection, not evidence. Person, timestamp and previous state sit on the case. You do not need that day to day — you need it on the one day.
New hires Weeks of onboarding by word of mouth, because nobody ever wrote the process down. Everyone learns a slightly different version. The process is in the system. A new person follows it, and learns exactly the version everybody else uses.
When volume grows More orders means more manual work and more transcription errors. Growth costs headcount first. The same process, just more often. What grows is the number of cases, not the number of workarounds.
Month end Somebody lays two spreadsheets side by side and reconciles. It takes a while, and nobody knows whether it is right. The figures come from the records people worked in. Each one can be opened down to the single record.
Website or system? The difference is bigger than it sounds
Both are software, both run in a browser — and they are still two entirely different projects. This list sorts it in ten seconds.
It is a system
- Several people work on the same case one after another
- Not everyone may see or change everything
- Later you must be able to prove who decided what, and when
- There are states: open, reviewed, approved, invoiced
Often it is both, and then the order does not matter. For Ataberk Estate we built the website first and the system behind it half a year later. You will find both below.
The seven layers a system is made of
Click through the building blocks that sit under every interface. These pictures are schematics, not screenshots — real views are in the two live systems further down, with real data and a real login.
One record instead of three lists
Customer, property, supplier, employee: every object in your business exists exactly once, with a history and a person accountable for it. Whoever edits the record edits it for everyone — that is the difference between a database and a spreadsheet.
- Duplicates are caught on creation, not at year end
- Required fields enforce the details somebody will need later
- Every record knows its own change history
- The situation
A customer calls and asks where things stand. Three colleagues have created him, each spelling the name slightly differently.
- Without a system
The answer depends on which of the three files somebody opens first. Two are out of date, and nothing about them says so.
- With this layer
The record exists once. On creation the system flags the similarity, and the history shows who changed what and when — the answer is the same whoever gives it.
A process that cannot be skipped
Every case has a state and permitted transitions. An approval cannot be skipped because somebody is on holiday — it can be delegated, and that too is on the record afterwards. The process lives in the system, not in someone’s memory.
- States and transitions are agreed with you, not guessed by us
- Deadlines and reminders sit with the system, not with a person
- Cover is designed in, not improvised
- The situation
A quote with an unusual discount has to go out today. The person allowed to approve it is on holiday.
- Without a system
Somebody sends it anyway and mentions it later. Three months on, accounting asks who decided that, and nobody quite remembers.
- With this layer
The case stays in the "reviewed" state and cannot be skipped. The designated stand-in approves it, and the fact that it was them is on the record afterwards.
The database decides who sees what
Rights are not hidden in the interface, they are enforced at row level. A role sees exactly the records that belong to it — and a bug in the front end cannot change that, because what is not permitted never arrives there.
- A role matrix you sign off yourself in phase three
- Read, edit, approve and delete are four different rights
- Every change to a permission lands in the audit trail itself
- The situation
An intern is to write quotes. He must not see the purchase prices while doing it.
- Without a system
A second spreadsheet appears without that column. From day two it drifts, and eventually somebody writes a quote from the wrong file.
- With this layer
He works in the same list as everyone else. For his role that column never leaves the database — not hidden, simply not sent.
The document hangs on the case, not in an inbox
Contracts, records, photos and minutes sit on the case they belong to — versioned, dated, and with the person who uploaded them. The day somebody asks for one is the day this layer was built for.
- Versions are kept; the old one does not disappear
- Expiry dates and deadlines are raised by the system itself
- Visibility follows the same role matrix as the data
- The situation
Two years after a refit, an insurer asks for the handover report and the photos taken on the day.
- Without a system
The photos are on a phone that now belongs to somebody else. The report is an attachment in a mailbox that left with the colleague.
- With this layer
Both sit on the case they belong to, versioned and with the person who uploaded them. The request is answered in two minutes rather than two days.
Open items nobody has to collect by hand
Receivable, payment, reminder and document hang on the same case. What is outstanding is outstanding because the record says so — not because somebody laid two spreadsheets side by side at the end of the month.
- Incoming payment and case are matched automatically
- Several currencies, when your business needs them
- Export in the format your accounting already reads
- The situation
At month end, management wants to know what is outstanding and for how long.
- Without a system
Somebody exports from two systems and reconciles by hand. The result is already stale on the day it is finished, and any query starts over.
- With this layer
Receivable, payment and document hang on the same case. What is outstanding is outstanding because the record says so — and every line opens down to the document.
Documented interfaces instead of an island
Every system gets a documented interface outwards and event notifications inwards. Your accounting can pull, your calendar can write, and a future tool that does not exist yet can dock onto it.
- Outside access runs through keys with rights of their own
- Events are pushed rather than polled every minute
- Every connection is logged like any other change
- The situation
The tax firm wants the documents monthly in its own format, and the field team’s calendar should know the appointments.
- Without a system
Once a month somebody spends half a day on the export, and appointments are maintained twice. Both work until the person doing it is off sick.
- With this layer
The tax firm pulls the documents itself through a documented interface, and the calendar is notified of every new appointment as an event. Both keep running when nobody is there.
Figures from data, not from assertions
Reports calculate on the same records people work in. And where a figure cannot yet be calculated, the tile says exactly that instead of estimating — an estimated metric is worse than none, because somebody will pass it on.
- Every figure can be opened down to the single record
- The AI assistant answers from your content and otherwise stays quiet
- Reports respect the same rights as the lists do
- The situation
In a meeting somebody asks how many cases got stuck at approval last quarter.
- Without a system
Somebody estimates. The estimate goes into minutes, from the minutes into a deck, and from then on it counts as a figure.
- With this layer
The report calculates on the same records people work in and opens down to the single case. And where the data cannot answer the question yet, the tile says exactly that.
Two examples you can open
Two systems we built, not a catalogue — yours would look different. Both run in production and both can be opened: a reference you cannot touch is not a reference.
Reference system 1Çatı ERP
One estate agency, one workspace
An estate agency with years of sales behind it — and an overview that lived in separate lists: sales here, properties there, owners in the folder next door. Today it all sits in one workspace, and who sees which record is decided by the role — not by an agreement in the corridor. The same firm’s public website came from us too.
- Sales and portfolio in one record set
- Owners, tenants, dues, service
- Documents with an audit trail
- Its own customer portal, multilingual
DiTeLe
A learning platform where people actually work
You do not learn software testing from slides. On DiTeLe, learners test running applications, write real defect reports and have trainers review them. Three roles with separated rights, enforced in the database rather than the interface — on a platform where people learn to test, anything else would be embarrassing.
- Roles for learners, trainers, administration
- Tasks, submission, review
- An AI assistant with fixed guardrails
- Three languages, light and dark
A system that docks onto everything else you run
No company starts from zero. Accounting, calendars, payment providers and a ticket system are already there — and they stay. We build the connections through documented interfaces, so a piece of data is created once and counts everywhere.
Which of them get connected is decided in phase three — and whatever is not technically possible, we say so there, not after the signature.
Your system
- Accounting
- Calendar
- Payments
- Ticketing
- Email & messaging
- Sign-in (SSO)
- Government portals
- Document storage
How a system comes about with us
Six phases. Each ends with something you can hold — not an interim state only we understand. After phase two you may walk away and keep everything.
-
Listening
First conversation · business analysis · process capture
We come by and watch how the work is done today. Not how the org chart describes it, but how it actually runs — including the detours somebody invented years ago because the system left no other way.
You receive A process map of how things stand today
-
Writing it down
Requirements capture · documentation · prioritisation
What we saw becomes a requirements document: what the system must do, what it explicitly should not do, and in which order. The document is yours — even if you take it to somebody else afterwards.
You receive A requirements document, signed off by you
-
Aligning
Process alignment · roles and permissions · interfaces
Now comes the uncomfortable question: which workflow stays, which goes, which changes? We walk through every step with you and define who may see and change what. A system sets your processes in concrete — which is why we look closely first.
You receive Agreed target processes and a role matrix
-
Showing
Design alignment · clickable prototype · accessibility
Before a single line of code exists, you click through your system. Real screens, real paths, the vocabulary of your company rather than a textbook. Changes cost minutes at this stage — later they cost days.
You receive A clickable design, accepted by you
-
Building and testing
Development in slices · test management · acceptance
We build in slices: one narrow but complete section goes live, you work with it, then the next one follows. Testing runs by the same rules we apply when auditing other people’s software — test management is the business WAMOCON came from.
You receive An accepted scope at each milestone
-
Rolling out
Data migration · training · manual · operation
The legacy data comes along, spreadsheets included. Your team is trained, not merely informed — that difference decides whether a system gets used or worked around. After that we take over operation, backups and further development, with response times written into the contract.
You receive A system your team actually works in
What sits inside every system
No kit, and no standard product with your logo on it. Every system of ours gets these six things; the rest follows your operation.
Roles and rights
Who sees what is decided by the database, not the interface. So even a bug in the front end cannot leak somebody else’s data.
Workflows with defined states
A case has a state and permitted transitions. An approval cannot be skipped just because somebody is away.
Audit trail
Every change carries the person, the time and the prior state. You do not need it day to day — you need it on the one day somebody asks.
Interfaces, not an island
Accounting, calendar, ticketing, payment provider. A system that connects to nothing becomes the next spreadsheet.
AI with guardrails
Assistants that answer from your own content and otherwise stay quiet. No model that makes something up when it does not know.
Figures that hold up
Metrics from real data instead of claims. Where a figure cannot be computed yet, the tile says exactly that instead of guessing.
What happens when something happens
A system is only finished once it is clear what applies on a bad day. These seven points are part of the blueprint, not of an add-on package.
Rights in the database
Access is enforced at row level, not hidden in the interface. A bug in the front end therefore cannot leak somebody else’s records.
An audit trail without gaps
Every change carries a person, a timestamp and the previous state. Nothing is overwritten without the old state remaining readable.
Servers in the EU
A GDPR data-processing agreement, data held in the EU, a German contracting party and a German place of jurisdiction.
Backups and recovery
Secured states and a rehearsed recovery. A backup that has never been restored is not a backup.
Accessible under the BFSG
Operable by keyboard, readable with a screen reader, sufficient contrast. For many companies this has been a legal duty since 2025, not a nicety.
Tested, not just built
Acceptance criteria before development, test cases designed to ISTQB techniques, regression before every release. This is the business WAMOCON comes from.
A regulated way out
Source code and data belong to you. An exit clause governs handover in a format somebody else can read — including in a dispute.
Why us in particular
We come from testing, not from building
WAMOCON has spent years testing other companies’ software — in test management, to ISTQB standards. When you spend your days seeing why projects fail, you build differently. More carefully, and with more evidence.
One person, not a ticket queue
You talk to the people who actually build your system. At a firm our size that works — and it spares you the translation layer between sales and development.
A German contracting party, EU data
WAMOCON GmbH sits in Eschborn near Frankfurt. GDPR data-processing agreement, servers in the EU, German place of jurisdiction. None of that is a selling point — it is the precondition for you being able to sign at all.
We also say no
Not every company needs a system of its own. Sometimes an off-the-shelf product is enough, sometimes merging three spreadsheets does the job. When we see that, we say so — an honest no beats a project nobody uses.
What you can hold us to
Promises are free. These five sit in the contract and carry consequences if we miss them.
- Acceptance criteria are fixed before we build, not afterwards.
- Payment per milestone after acceptance. No advance payment.
- Support response times are agreed, with a credit if we miss them.
- Source code and data are yours. An exit clause governs handover, including in a dispute.
- GDPR data-processing agreement, servers in the EU.
Frequently asked questions about business systems
The four questions that come up in almost every first conversation, and three that are asked too rarely.
What does a business system from WAMOCON cost?
A price only exists once the scope does, which is why there is none on this page. What forms the price are the six phases: process capture, requirements, alignment of roles and workflows, a clickable design, development with testing and acceptance, and finally data migration, training and operation. After phase two you hold a signed-off requirements document, and a dependable quote can be calculated from it. You may stop there and keep the document, even if you take it to somebody else. Billing runs per milestone after acceptance, with no payment up front.
How long does it take to roll a system out?
It depends on the scope, but not on your patience: we build in slices. A narrow but complete slice goes live early, your team works in it, then the next one follows. That gives you something usable long before the full feature set exists, and it tells us from real cases what is still missing. The first two phases — listening and writing it down — typically take a few weeks at a mid-sized company, and they are the only ones where we need more of your time than you need of ours.
Why not buy standard software instead of building?
Often standard software is the right answer, and then we say so. Building your own makes sense where your process is your competitive advantage and a standard product would force you to give it up. The second case is companies already running three tools in parallel and filling the gaps between them with spreadsheets and verbal agreements — there a system does not replace a product, it replaces the manual work between three of them. If we see in the first conversation that something simpler will do, you get an honest no.
Who owns the source code and the data in the end?
You do, and that sits in the contract rather than in a promise. Source code and data pass to you, an exit clause governs handover in a format another provider can read, and it applies even if we fall out. We are glad to take on operation, backups and further development — but as a service you order, not as a dependency you cannot leave. Processing runs under a GDPR data-processing agreement, on servers in the EU.
How does WAMOCON make sure the system actually works?
With the craft the company comes from: WAMOCON has spent years testing other companies’ software in test management to ISTQB. Acceptance criteria are set before building starts, not afterwards. Test cases are designed with the same techniques we use in enterprise projects, and a regression runs against the already accepted scope before every release. Whatever fails acceptance is not invoiced.
Does a business system have to be accessible?
For many companies, yes. Germany’s Barrierefreiheitsstärkungsgesetz has obliged a large share of digital service providers since June 2025, and even where no duty applies, keyboard operability is simply faster in a system people work in all day. We build keyboard operation, screen-reader support and sufficient contrast into phase four, where you accept the clickable design — retrofitting the same result afterwards costs considerably more.
Can existing data be migrated out of spreadsheets?
Yes, and it is usually the underestimated part of the project. Legacy data rarely arrives clean: the same company appears three times spelled slightly differently, fields have been repurposed, and part of the truth lives in a notes column. Migration is therefore its own phase, with reconciliation, cleansing and a dry run you review before it counts. Whatever cannot be migrated cleanly, we name — rather than importing it quietly.
The first step costs you an hour
Tell us in one conversation where things snag today. We listen, we ask, and afterwards we tell you honestly whether a system of your own is worth it — or whether something simpler will do. No quote attached, no sales deck.
And if it turns out to be a website
Then you have gone one department too far. Our web-design team builds multilingual sites with booking, an AI assistant and search visibility — for clients from a barber in Alanya to a safety-testing provider in the Rhine-Main region.
WAMOCON GmbH
Contact person: Dipl.-Ing. Waleri Moretz, Managing Director, WAMOCON GmbH
Phone: +49 6196 5838311
E-Mail: info@wamocon.com
Opening hours: Mon to Fri: 9:00 to 18:00
Sat: 10:00 to 14:00
Sat: 10:00 to 14:00
Location: Mergenthalerallee 79–81
65760 Eschborn
65760 Eschborn
Follow us on social media
Get in touch
Do you have a question or request? Send us a message and we will get back to you shortly.