Service · Custom software
Custom software development for machine builders
Where standard software does not reflect your process, Excel lists and word of mouth fill the gap. We build software for it that fits your process, alongside your ERP and in stages, each of which is usable on its own.
When custom software pays off, and when it does not
Standard software is almost always the cheaper choice, as long as your process fits the standard. For accounting, purchasing and warehouse management, that is usually the case. You should not have anything custom built there.
It is a different story where your company earns its money: special-purpose machines with bills of materials that are still growing while the order is already running. Assembly in sub-assemblies. Changes shortly before the FAT. That is where every company works a little differently, and that is exactly where the Excel lists come from.
A useful rule of thumb: if several people maintain the same list every day and nothing works without it, that list shows fairly precisely which software you are missing. That is why we take it seriously. It is the best requirements specification you have.
Custom software does not pay off if your ERP already offers the function and nobody has set it up. Or if the problem comes up twice a year. In those cases we will tell you so before you have spent any money.
Examples from assembly, production and the office
What we typically build
Three kinds of software, one common denominator: they take data from your ERP and show it to the people who have to act on it, in their terms and at their workplace.
Apps for assembly and production
Your fitter sees on the tablet which assemblies are ready to build, and does not start anything that cannot be finished. The information is where the work is done, not in a binder in the office.
Example: assembly planningDashboards and reports
In the morning you see which order is wobbling, not only when the customer calls. At the machine, the operator sees which order comes next and what has to be ready for it.
Example: reducing setup timeTools for production planning, sales and project management
A change to the bill of materials reaches purchasing, production and assembly before the old part is built. The same pattern gives you tools for quotations, order overviews and deadline tracking, wherever a list is maintained by hand today.
Example: change managementScope
Software for your processes, not machine control or PLCs
People searching for “software for machine building” sometimes mean the software inside the machine: PLC programming, drive technology, operator panels. We do not do that. There are good specialists for it.
We build the software around the machine: for the path an order takes from quotation through design engineering, production planning, production and assembly to delivery. In other words, for the question of whether all parts are there, not for the question of how the axis moves.
Nor do we introduce a new ERP. Your ERP remains the source for orders, bills of materials and stock. What we build reads from there and shows it the way your people need it.
13 years in machine building, then software
Why we understand your specification
Torben Schwanz spent 13 years in machine building before founding THDS: in design engineering, in technical sales and in ERP development. He knows how a bill of materials keeps growing while the first parts are already being made, and what a promised FAT date means.
For you, that means you do not have to write a specification for people who do not know your company. You tell us where things get stuck, in your own words. We ask questions until we have understood the process, and write down the goal in a way your production manager would sign off.
You will not have to explain to us what an assembly, a production order or a piece of equipment is.
How a project runs
Process and verification
You know this from your own orders: before the build, it is settled what the machine must be able to do, and at acceptance it is checked. That is how we work too.
-
1
Define the goal
Together we agree on what should change in your company and how we will recognise it at the end. Not “an app for assembly”, but “assembly only starts assemblies whose parts are all there”.
-
2
Build a prototype
Before we develop, we build a prototype. It shows what the solution will look like and how it will be operated. That is far easier to discuss than a description on paper.
-
3
Review it with every user
You go through the prototype with everyone who will later work with it: assembly, production planning, purchasing. Whatever does not fit, we change now, while a change still costs little. That way nothing gets built that misses the need.
-
4
Develop
We develop in stages, each of which is usable on its own. After every stage you decide whether and how to continue.
Step 5
Roll out and put it right
We support the rollout in your company and check together whether the agreed goal has been reached. If not, we keep improving until it is, just as you do in your own customer projects.
For your IT: We use widespread technology that any good developer can pick up, and we document what we build. Which access we need and which security requirements apply, we agree with your IT before the start.
Frequently asked questions
What you want to know about custom software
What does it cost, and is it worth it for us?
That depends on the bottleneck, which is exactly why the potential analysis comes first: afterwards you know the expected benefit and a realistic order of magnitude for the effort. We work in stages, each of which is usable on its own. You decide again after every stage and know beforehand what it will cost.
Feel free to weigh that against what an hour of searching, a round of rework or a postponed FAT date costs you today.
What happens if someone at THDS drops out, or THDS no longer exists?
A fair question, and we would rather answer it with measures than with reassurance. We use widespread technology that any good developer can pick up, and we document what we build.
How you get hold of source code and documentation is settled in the contract before we start. Our principle: you should stay with us because the collaboration works, not because you cannot leave.
You are a small team. Can you handle this?
We are a small team and only take on as many projects as we can look after properly. Support for what is already running at our customers is firmly built into our planning. It does not happen on the side. For you, that means one fixed contact who knows your company, and developers who are at the table from the start.
If you want to roll out a new ERP across several plants, we are not the right people, and we will tell you so. For targeted solutions in your order processing, a small, well-practised team is exactly right.
Will our staff need training?
Hardly. The user interface is developed together with the people who will use it later. Your fitters, your production planners and your purchasing team see early versions and tell us what works. Nobody needs to be taught something they helped design.
Is an Excel list holding your company together?
Tell us where things get stuck. We will tell you honestly whether software pays off at that point and whether we are the right people for it.
Not quite there yet? Two-minute bottleneck check. No sign-up, no email address.