Custom and Bespoke Software

User operations are a crucial part of the project team as they bring the perspective of end users. This role ensures that the developed solutions meet the actual needs of users. Additionally, user operations act as a link between technical developers and users, promoting communication and understanding. Through regular feedback, user operations can contribute to the continuous improvement of the project.

Custom software is developed for a specific company and its processes, rather than being sold as a finished product to many. It reflects processes as they actually occur – the company is responsible for development, operation, and further development, which are included in the license price of standard software.

The price is determined by effort multiplied by daily rate – not from a price list. Three factors are crucial for the effort: the number of different processes, the number of interfaces to other systems, and the requirements for permissions and traceability. To get a reliable figure, a concept is needed beforehand.

An MVP (Minimum Viable Product) is the smallest version of software that provides real value in everyday use. It is not an unfinished product, but a complete small one. The purpose: to test assumptions against reality early, instead of spending six months building features that no one needs.

When multiple people are working on it simultaneously, when no one knows which file is the current one, when formulas are only understood by one person, or when an error could cause real damage. As long as one person is working alone and an error is harmless, Excel is perfectly fine.

Vendor lock-in means that switching providers becomes disproportionately expensive or practically impossible. In custom software, it rarely arises from the code itself, but from what is missing: no access to the repository, no documentation of the environment, no data exports, no second person knowledgeable about the system.

In general, yes. The usual approach begins with an inventory: reviewing the code, checking dependencies, assessing security. Stabilization follows, without immediate restructuring. A complete rebuild is the exception – it seems attractive but often underestimates how much invisible knowledge is embedded in the old system.

It depends less on the technology and more on three other factors: how clear the requirements are, how quickly decisions are made, and how many external systems need to be integrated. A first usable version is usually achievable within weeks, while a complete system with multiple interfaces takes months.

Rarely due to technology. The most common causes are: unclear goals, no one with decision-making authority, scope creep without an increasing budget, and users being consulted only at the end. All four are organizational – and all four can be recognized in advance.

An API is an agreed way for two programs to communicate. One requests something, and the other responds in a defined format. The advantage over direct access to external databases is that both sides can change internally as long as they adhere to the agreement.

Not based on price and not on the technology list. Four things are significant: references you can speak to; an offer that also describes what is not included; transparency about operating costs after launch; and the willingness to advise against a project.

At its core, three things: secure login, view your own process, and be able to initiate something. Everything else – files, notifications, reports, invoices – comes afterward. A portal rarely fails due to missing functions, but rather because the data within it is not up to date.

Typically in two to three meetings: observing how work is done today; jointly documenting the process; reviewing special cases. The result is a description from which a reliable effort can be derived. The value lies not in the document, but in the questions that are asked for the first time during the process.

A clickable prototype clarifies more in one hour than a thirty-page concept in a week. People struggle to assess whether a description fits their daily work – but can immediately tell if a screen works. The concept remains necessary, but as a result, not as a starting point.

Based on previously agreed criteria, not on feelings. A testing phase with real data and real users is common, along with a list of identified deviations classified by severity, and an acceptance that does not block minor defects. Discussing criteria only at the time of acceptance is negotiating at the worst possible moment.

Do not decide individually, but collect. Each request goes on a visible list with estimated effort. Regularly – about every two weeks – prioritize: What gets added, what gets removed, what is on hold. This keeps the framework intact without losing good ideas.

Not just the source code. It includes: access to the repository, operational documentation, credentials in your possession, a description of the environment, and at least one training session for the future users. Without these five things, you have software, but no control over it.

A database stores data in a structured way and ensures that many people can work with it simultaneously without overwriting each other. This is the key difference from a file: An Excel spreadsheet can only be effectively edited by one person at a time, while a database can handle hundreds.

For most companies, the cloud: ready to go in no time, no investment, built-in reliability. An own server is worthwhile if legal requirements demand it, there is very high and consistent load, or a data center already exists. The cost issue is less decisive than one might think.

Scalable means: The system remains usable as the quantity grows – more users, more data, more processes. The important question is how much growth is realistic. Software built for one hundred users that is intended for one hundred thousand is unnecessarily expensive and more complicated to operate.

Because otherwise, every change is a risk. Automated tests check within minutes whether everything that worked before still functions after an adjustment. Without them, every further development becomes more expensive and riskier over time – until no one dares to touch anything anymore.

Technical debt arises when a quick solution is chosen instead of a clean one. Like a loan, it incurs interest: every subsequent change takes a bit longer. This is not inherently wrong – one just needs to be aware that debt is being taken on and that it will need to be repaid eventually.

Yes, at the federal, state, and partially EU level – however, the programs change frequently, expire, and are reintroduced. The most important rule: The application must be submitted before the commissioning. Those who commission first and then apply usually lose their entitlement completely.

The core is inventory management: stocks, orders, suppliers, prices. Custom development becomes interesting where standard systems reach their limits – customer-specific price lists, tiered pricing, framework agreements, EDI connections, and customer portals with individual conditions.

There is often a gap between ERP and machines in many companies: the ERP knows orders, the machine knows cycles, but no one knows in real-time where an order stands. Custom development usually addresses this gap – order tracking, feedback from production, quality documentation.

Member management with fee collection is the core. This is complemented by communication, events, and often a member area. The unique aspect compared to companies: changing voluntary support – the software must be operable without training and must not depend on one person.

Whenever a service provider processes personal data on your behalf – including hosting, software maintenance with access to live data, and support. The contract according to Art. 28 GDPR must be concluded before processing begins, not afterwards.

Almost every modern software uses open-source components. Most licenses – MIT, Apache, BSD – allow commercial use without conditions other than attribution. Caution is advised with so-called copyleft licenses like the GPL: they may require that derivative software be published under the same license.

It entirely depends on what you arranged beforehand. With repository access, your own credentials, and operational documentation, a transition is inconvenient but feasible. Without these three things, your system will be at a standstill until someone reverse-engineers it – which takes weeks and costs a multiple.

Neither fundamentally more secure nor less secure than standard software – it depends on maintenance and care. Standard software is reviewed by many, but it is also a more lucrative target. Custom software is less in focus but only receives the attention that is paid for it.

In steps, not on a specific date. A proven method is parallel operation: the new system initially takes over one area while the old one continues to run. Only when the new area is stable does the next follow. Switching over in a single weekend is the riskiest option.

Comparing annual salary to daily rates can be misleading, as an employee is only productively available for about 200 out of 365 days, with additional costs for overhead, equipment, and training. An employee is worthwhile for consistent, long-term workloads; a service provider is better for projects with a defined start and end or for knowledge that is not needed year-round.

Only if they have been explicitly agreed upon – a penalty never arises from the law, but always from a penalty promise (§ 339 BGB). What arrangement Ouhud GmbH offers is available upon request. Without such an agreement, the client is left with the delay damage, which they must quantify and prove.

Prioritizing requirements in a project with a limited budget and timeframe requires a structured approach. First, requirements should be evaluated based on their business value and urgency. Methods such as MoSCoW (Must have, Should have, Could have, Won't have) or the Kano analysis can help identify the most important requirements. Additionally, it is important to involve stakeholders to ensure that priorities align with actual needs.