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.

Misinvestments in custom software can be avoided through careful needs analysis, clear goal definitions, and iterative development. It is important to understand the users' requirements precisely and document them in a specification sheet. Additionally, an agile approach should be chosen to respond flexibly to changes. Regular feedback loops with stakeholders help continuously optimize the software and identify misdevelopments early.

An effective project team consists of various roles that bring different skills and perspectives. Typically, these include project managers, subject matter experts, developers, testers, and stakeholders. The exact composition may vary depending on the type and scope of the project. It is important that all team members have clearly defined tasks and communicate well with each other.

The integration of custom software with existing systems depends on factors such as interface compatibility, data formats, and system architecture. Seamless integration often requires adjustments to existing infrastructures. Critical aspects include ensuring data security, compliance with standards, and the scalability of the solution. Practical experience shows that involving IT expert teams is crucial for success.

Adapting custom software to specific business processes is technically possible, as software solutions are generally adjustable through configurable modules and custom development. However, implementation depends on the specific software architecture, the requirements of the business processes, and the resources of the development team. There are no secured statements from Ouhud GmbH regarding this question. The assessment of adaptability should be based on the software's technical documentation and the vendor's experience.

Custom software is developed for a specific company and its processes, rather than being sold as a finished product to many customers. It replicates processes exactly as they actually operate – the company itself bears the costs of development, operation, and further development, which are included in the license price of standard software.

It is worthwhile when a process is critical to the business and standard software can only represent it with workarounds. It is not worthwhile for tasks where mature products already exist: accounting, payroll, word processing. The honest rule of thumb is: custom only where you differentiate yourself from the competition.

The price is calculated as effort multiplied by daily rate – not from a price list. Three factors determine the effort: the number of different workflows, the number of interfaces to other systems, and requirements regarding rights and traceability. Whoever wants a reliable number needs a concept beforehand.

An MVP (Minimum Viable Product) is the smallest version of a software that provides real value in everyday use. Not an unfinished product, but a finished small one. The purpose: Test assumptions against reality early, rather than spending six months building features no one needs.

A requirements specification describes which problem needs to be solved – not how. It includes the current situation, goals, processes with their special cases, affected systems, data volumes, and framework conditions. Whoever instead prescribes technical solutions wastes exactly the experience for which they pay a service provider.

A fixed-price model is suitable when the scope is clearly defined – it transfers the risk to the service provider, who incorporates it into the price. Cost-plus billing is suitable when requirements are still being clarified and is often more cost-effective. A practical middle ground: fixed-price for the concept, then cost-plus with agreed-upon boundaries.

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

Vendor Lock-in means that switching providers becomes disproportionately expensive or practically impossible. With custom software, it rarely arises from the code itself, but from missing elements: no access to the repository, no documentation of the environment, no data exports, and no second person with system knowledge.

In general yes. The usual approach starts with an inventory: reviewing code, checking dependencies, assessing security status. After that, the system is stabilized, not immediately rebuilt. A complete rebuild is the exception – it may seem attractive, but regularly underestimates how much invisible knowledge is embedded in the old system.

This depends less on technology than on three other factors: how clear the requirements are, how quickly decisions are made, and how many third-party systems need to be integrated. A first usable version is usually achievable in weeks, while a complete system with multiple interfaces requires months.

Rarely because of technology. The most common causes are: unclear goal, no one with decision-making authority, growing scope without increased budget, and users were only consulted at the end. All four are organizational – and all four can be recognized in advance.

An API is an agreed-upon way for two programs to communicate. One program makes a request, and the other responds in a predefined format. The advantage over direct access to foreign databases: Both sides can change internally, as long as they adhere to the agreement.

Not by price and not by the technology list. Four things are telling: References you may speak to; an offer that also describes what is not included; transparency about operating costs after launch; and willingness to advise against a project.

At its core, three things: secure login, view your own process, and be able to trigger actions. 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.

Usually in two to three sessions: observing how work is done today; jointly recording the process; going through special cases. The result is a description from which a reliable workload can be derived. The value lies not in the document, but in the questions that are asked for the first time.

An interactive prototype clarifies more in one hour than a thirty-page concept paper in one week. People struggle to judge whether a description fits their daily work – but can immediately tell if a screen works. The concept paper remains necessary, but as an outcome, not as a starting point.

At least three roles: an authorized decision-maker as a fixed contact person, at least one person from the functional area who will work with the result daily, and someone with access to the affected systems. If the first role is missing, every project is delayed—regardless of anything else.

Based on pre-agreed criteria, not by feel. Common practice includes a test phase with real data and real users, a list of identified deviations classified by severity, and acceptance that does not block minor issues. Anyone discussing criteria only at acceptance time is negotiating at the worst possible moment.

Don't decide individually, but collect. Every wish goes on a visible list with estimated effort. Regularly – about every two weeks – prioritize: What comes in, what gets cut, what waits. This preserves the framework without losing good ideas.

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

A database stores data in a structured way and enables multiple people to work with it simultaneously without overwriting each other. This is the key difference to a file: An Excel table can only be meaningfully edited by one person at a time, while a database can be used by hundreds.

For most companies, the cloud: ready in hours, no investment, high availability included. An own server is worthwhile if legal requirements mandate it, there is very high and uniform load, or an existing data center is already in place. The cost question decides less often than expected.

Scalable means: The system remains usable as the volume grows – more users, more data, more processes. It's important to ask honestly how much growth is realistic. Software designed for one hundred users, but built for one hundred thousand, is unnecessarily expensive and complicated to operate.

Because otherwise, every change is a risk. Automated tests check within minutes whether everything that previously worked still functions after an adjustment. Without them, every further development becomes increasingly expensive and risky – 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, you pay interest: every subsequent change takes a bit longer. This is not per se wrong – you just need to be aware that you are taking on debt, and that you will eventually have to pay it back.

Since June 28, 2025, the Accessibility Strengthening Act (BFSG) applies. This affects online shops, banking services, passenger transport, and e-books – each in business with consumers. Pure applications between companies are generally not covered, nor are micro-enterprises under certain conditions.

Externally commissioned software is an acquired intangible asset and is capitalized and amortized over its useful life. For self-created software, there is an option under commercial law, but a prohibition on capitalization under tax law. The specific treatment should be handled by tax consulting.

Yes, at federal, state, and partially EU levels – however, programs frequently change, expire, and are relaunched. Most important rule: The application must be submitted before commissioning. Whoever is commissioned first and then applies usually loses the claim entirely.

With three questions: Does this process differentiate us from the competition? Is there a product that covers at least 80 percent of it? Can we live with the remaining 20 percent? Only if the first question is answered with Yes and the third with No, is developing in-house the right choice.

At its core, three things: plan orders and appointments, record time and materials on site, generate invoices from that. The decisive point is mobile data capture – what is not entered on site will not be added later in the evening and is lost as revenue.

The core is inventory management: stock levels, orders, suppliers, prices. Custom development becomes interesting where standard systems hit their limits – customer-specific price lists, tiered pricing, framework contracts, EDI integrations, and customer portals with custom terms.

The core is the connection between project, time and invoice: Who works on what, how long, and what is billable. If time tracking, project planning and invoicing are in separate systems, billable performance is regularly lost.

Between ERP and machine, many companies have a gap: The ERP knows orders, the machine knows cycles, but no one knows in real time where an order is. Custom software development often starts exactly there – 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.

A contract for work guarantees a result and ends with acceptance – suitable for clearly defined scope. A service contract guarantees the activity, not the outcome – suitable for ongoing development and operation. In practice, both are often used: contract for work for construction, service contract for operation.

In a contract for work, the limitation period for defect claims is generally two years from acceptance (§ 634a BGB). What constitutes a defect is crucial – this is why the agreed requirements are so important. Anything not agreed upon is not considered a defect in case of dispute.

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 restrictions except for attribution. Caution is advised when dealing with so-called Copyleft licenses such as the GPL: They may require that derived software is also published under the same license.

This depends entirely on what you previously agreed upon. With repository access, own access credentials and operational documentation, a transition is unpleasant but possible. Without these three things, your system will be halted until someone reverse-engineers it – this takes weeks and costs multiples.

Neither inherently more secure nor less secure than standard software – it depends on construction and maintenance. Standard software is tested by many, but is also a more lucrative target. Custom software receives less attention, but only gets the attention you pay for.

In steps, not on a single date. Proven to be effective is parallel operation: The new system initially takes over one area, while the old system continues to run. Only once the new area is stable, the next follows. A switchover on 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.

The documentation of architecture decisions is typically done by creating an Architecture Decision Record (ADR). This record includes the decisions made, the reasons for those decisions, and the alternatives considered. It should be clear and concise to ensure traceability. Structured documentation promotes communication within the team and facilitates future adjustments.