Web-based applications for individual requirements. Implemented by senior developers, a maximum of twelve mandates per year.
The difference from everything else lies in who adapts: with standard software, the operation adapts to the program, and with custom software, the program adapts to the operation.
Accounting, time tracking, inventory management: In these areas, in-house development is almost always the worse choice. It gets interesting with the part of the processes that no one else has in the same way – usually precisely the part that today runs via Excel, email chains, and verbal requests.
As long as parameters, fields, and plugins are sufficient, customization is the more affordable route. The limit is reached when every manufacturer update becomes a risk. When employees enter special characters in comment fields so that the evaluation is correct, that limit has been exceeded.
One Website displays content. A web application processes it: users with permissions, a database, logic that performs calculations and validations, and connections to other systems. Both run in the browser, but in terms of effort, they’re worlds apart.
For the remaining 20 percent, in-house development is almost never worth it. Exception: These 20 percent are precisely what makes money in the market.
What is unclear internally, otherwise gets poured into the code as ambiguity. This becomes expensive and no one uses it afterwards.
Your people need decisions, tests, and an introduction. If this time is missing, it's better to postpone than to start.
Software is never finished. Those who don't plan for operation afterward will have a problem instead of a solution in two years.
A core process runs on legacy Excel files that only one person understands.
Two or more systems contain the same data, and someone is transferring it manually.
Numbers from multiple sources are manually compiled monthly.
A process that differentiates you from competitors cannot be mapped with standard software.
An old system is still running, but no one can maintain it anymore.
Immediately available, tested, calculable monthly costs, manufacturer continues maintenance.
The operation adapts, license costs are ongoing, customizations are limited or expensive.
Full control, knowledge stays in-house, no external daily rates.
Locks in in-house developers long-term, system grinds to a halt with staff turnover, maintenance is rarely scheduled.
Experience from many projects, predictable capacity, your own people stay in the core business.
It takes a partner who stays, and commitments that hold independently.
The most common mistake is mixing without a plan: purchased, internally adapted, externally expanded—and after three years, nobody knows who is responsible for which part. Those who combine approaches clarify in writing beforehand who owns which code section and who maintains it.
No one needs to know in advance what software they need. It's enough to be able to describe the problem. In the initial consultation, we will tell you what we would recommend, what technology is suitable for it, and whether we are the right fit for it. Even if the answer to that is no.
For context on whether we're a good fit for a project, here are four examples of projects we've built.
Consolidate data from multiple sources and present it in a way that enables decision-making. A typical scenario: The monthly figures have so far been compiled in an Excel file maintained by a single person.
A portal where others can look up information on their own that they would otherwise have to ask for. Orders, documents, status, contracts.
Applications, approvals, reviews, plans. Everything that currently runs through forms, emails, and verbal requests, and that no one can track.
Connect ERP systems to industry software so that the same data doesn't have to be entered twice. Often, this is the cheapest solution of all: no new software, just a connection between two existing ones.
Before we even talk about technology, let's clarify four things:
Only after that is the decision made. In practice, it often comes down to one of these three:
If there's something that fits the bill, that's the fastest and cheapest way. We say that even when it means we earn less.
If the systems are there and just not talking to each other, we build the connection instead of a new application.
When nothing fits. Then usually with Symfony, because the framework for data-driven business applications is mature, has been maintained for years, and many developers are familiar with it. The last point is the most important: it determines whether someone else could take over the system.
Six data sources, an Excel file built up over years, three to four working days per month in controlling. Figures mid-month, not traceable — and unavailable at all during this one person's vacation.
First, the test on standard BI: it would have been sufficient for four out of six sources. It failed on two proprietary calculation rules that would have become un-testable formulas in the BI tool. So, a custom application, with rules as readable and testable code. Source systems remain leading, nothing is migrated.
The preparation is completely eliminated. Each key figure can be drilled down to the individual document, so that queries can be clarified during the appointment instead of a week later.
Initially, we only spoke with controlling. The sales management joined in week eight and brought requirements that would have been cheaper earlier. Since then, we've been bringing all user groups to the table before the first cycle.
Orders were managed in the industry-specific software, and invoices in the ERP system. Two employees manually entered about fifty data records each day. Typing errors made their way into the invoices. The request was for a new, integrated software solution that would handle both.
Advised against it. Both systems worked on their own. The problem was the gap in between. We built an interface: nightly synchronization for inventory, immediate transfer for status changes, plus an error log that the specialist department can view themselves.
Manual data entry is eliminated. Time is now spent on order processing instead of duplicate data entry—at a fraction of the cost of the requested new development.
The error log was initially only visible in the technical log. Until the business department could view it themselves, every discrepancy ended up as a ticket with us. We are now building this visibility in from the start.
A requirements specification demands knowing everything at the beginning of the project—at the point when the least is known. What results is a document that's no longer accurate after three months, and a change process where every correction becomes a negotiation.
Instead, we work in short cycles. We prioritize together: You decide what's important next, we tell you what it costs. Our project management is a Professional Scrum Product Owner certified by Scrum.org.
A runnable build every two weeks, that you can operate yourselves. Not a status report, but something tangible. From week four, it will be apparent if it's heading in the right direction.
Exit at any time at the end of a cycle. No remaining volume, no penalty.
No lock-in. You can switch providers at any time.
The code has been in your repository from day one., not in ours.
Fixed budget per cycle. Every month, it's clear what was spent and what was produced in return.
Taken together, this shifts the risk: Instead of committing to a result that will only be visible in a year, the decision is made anew every two weeks.
Connect two systems, clearly defined scope of data
One process, one to two connections · Productive operation after 6-10 weeks
Multiple user roles, workflows, multiple integrations · 3 – 6 months
Many user groups, extensive integrations, high compliance requirements
Hourly rates for software development in Germany range from about €80 to €180, depending on the area of specialization. Market data as of 2026.
It's not about the number of screens: special cases in your own rules, the number of third-party systems, and data quality in the source systems. Fifty simple screens are more cost-effective than five with forty pricing exceptions.
Industry benchmark, related to development costs. At €50,000, that's €7,500 to €12,500 annually for hosting, security updates, libraries, and interface changes.
This is not an argument against custom software, but rather against focusing solely on the purchase price: Standard software also costs money—in that case, it’s called a license fee—and the cost increases with the number of employees.
Fixed prices work when the scope is truly fixed—with defined interfaces, almost never for larger applications. Otherwise, one of two things happens: a risk premium that the customer co-pays, or savings on quality that become apparent later. We bill by effort with a fixed budget framework per cycle.
Most of the time, there's an ERP system, an inventory management system, a CRM, and sometimes an online store—and the new application has to integrate with them.
Ideally, the target system has a documented interface, in which case we’ll build our solution to work with it. If not, there are ways to integrate via database access, file exchange, or an intermediate layer. We’ll determine what’s possible before we submit a proposal, not after.
We import only what is needed. The effort almost never lies in the copying itself, but rather in the cleanup: duplicate records, inconsistent spellings, and fields that have been misused over the years.
If a legacy system is causing problems, replacing it isn't necessarily the answer. Often, it's enough to keep the legacy system running and add a new user interface on top of it. There are other reasons to replace it: a lack of security updates, the end of support, or no one left who understands the system.
Without clear priorities, everything gets built, and in the end, the money runs out before the core is finished. Solution: Each cycle has a fixed budget, and anything new that’s added replaces something else. You make that decision, not us.
When five departments have a say and no one makes the final call, the result is compromises that no one wants. On the client side, there needs to be one person who, when in doubt, says what goes.
Software that doesn't take actual workflows into account gets bypassed. That's why we talk to the people who will actually be using it, not just those who commission the project.
No budget for operations, no one in charge, no updates. After two years, the application is running on outdated libraries, and no one dares to touch it. That’s the most common form of a quiet death.
If code is undocumented, runs on exotic technologies, or resides in a foreign repository, any change becomes a rebuild. What helps against this is in the next section.
Source code in your repository, from day one.
Unrestricted and exclusive rights of use with you, including processing by third parties.
Widespread technologies with a job market. No proprietary framework.
Setup, deployment, and architecture documented in case we are no longer around.
Exit at any time at the end of a cycle, including provider change.
We recommend that every customer set up their own hosting—in their own name, using their own login credentials. No fixed partnerships, no commissions. We require that the server be located in the EU.
No, but it changes how quickly and how cheaply development happens. That's why we decide on a project-by-project basis whether and how much we use AI, and we discuss it beforehand.
The right choice for sensitive data, high data protection requirements, and security-critical applications. Anywhere where code or data must not leave the premises.
Rapid prototyping, swift integrations, shorter paths to the first working version. Earlier identification of whether an idea is viable, and earlier course correction.
In practice, the second approach is more common today. What doesn’t change is this: Every line of code is reviewed and scrutinized by a senior developer. AI generates code that looks plausible but can still be incorrect, especially when it comes to validity checks, calculations, and edge cases. We pass on the savings by delivering something that runs sooner—not by skipping the review.
A clearly defined task, a small budget
Absence, vacation, succession — there's only one person
Medium-sized projects, consulting and implementation from a single source
Team changes mid-project, junior staff after sales pitch
Large, long-running systems with many participants
Overhead, slow decisions, high minimum volumes
Budget constraints, clearly defined tasks
Coordination efforts, time zones, language used for technical details
The fourth question is the most telling. Those who have never been rejected have sold nothing.
Specifically named individuals and their roles. A process with cycles and deadlines. A statement regarding source code and rights. Operating costs separate from development costs. And a list of what is explicitly not included—this is almost always missing and causes the most trouble later on.
The first working prototype is ready within a few weeks. For projects with a clearly defined scope, it typically takes 6 to 10 weeks to reach production deployment; for more complex applications with multiple roles and integrations, it takes 3 to 6 months. Larger platforms take years to develop, but go live well before that.
Below approximately 5,000 Euros, the effort for configuration and training is disproportionately high. In this range, you will almost always be better off with a standard solution or an automation tool. We state this in the initial consultation instead of selling a project that's too small.
One to two hours per week for alignment and feedback, plus testing time before each major step. Data migration from legacy systems is the part that takes the most time on the customer's side.
Yes, if the source code and access are available. We will look at the current state and tell you whether taking over or rebuilding is the better path. This assessment is part of the initial consultation.
On servers located within the EU. You arrange the hosting yourself, in your own name—we’ll advise you on your choice, but we don’t earn anything from it and don’t have an exclusive partnership with any provider.
All you need to do is describe the problem. We’ll get back to you with our assessment of what we’d recommend, which technology might be suitable, and whether we’re the right fit for the job—even if the answer is no.
3 Einträge
3 Einträge
4 Einträge
5 Einträge
4 Einträge
