Custom software

When this service helps

Custom software: your brief for us.

Eliminate data re-entry and manual work
Develop your own digital products
Reliably map special business processes

Standard software covers many processes, but rarely the ones that set your company apart from competitors. For these processes, we develop business applications, portals and backend services with an architecture that plans for security requirements from the first sketch onward. We choose language and platform according to the task: .NET and Go for services, TypeScript for user interfaces, Rust and C++ where the code works close to cryptography or hardware.

What the assignment can include

Requirements analysis with the business unit, threat model and target architecture based on the C4 model
Domain model, data model and interface contracts before the first line of code
Development in short iterations with code reviews and acceptance by the business unit
Secure development under OWASP ASVS, checked dependencies and signed builds
Handover with source code, architecture documentation and operations manual

We define the specific scope, acceptance points and your involvement in the proposal.

The context at a glance

From a business rule to usable software.

01
Model
Refine rules and states
02
Develop
Implement a complete process
03
Test
Test functionality, permissions and error cases
04
Roll out
Prepare data, users and operations

Planning, implementation and decisions

What matters for Custom software.

01

Business logic before feature count

The starting point is the workflow for which the investment should pay off. We model terms, states and business rules together with the people who will later work with them. An approval, for example, is not just a button: deputizing arrangements, permissions, deadlines and the reversal of a decision must all fit together. These rules become part of the data model and the tests.

The first version focuses on one complete, usable process. We add further features based on feedback from actual use. This creates a product with verifiable benefit rather than a large collection of unfinished screens.

02

Technology matched to lifespan

For the backend, user interface and data storage, we choose technologies based on your existing system landscape and expected future development. Existing skills, interfaces and operating requirements weigh more heavily here than a short-term technology trend. The current offering includes .NET, Go and TypeScript, among others; system-level components are assessed separately.

We define module boundaries and responsibilities so that changes stay traceable. Credentials do not belong in source code, and business rules do not belong solely in the user interface. Reviews, automated checks and versioned database changes accompany the implementation from the start.

03

Acceptance means holding up in daily use

Every iteration shows usable features with known limitations. Business acceptance and technical release are considered separately: a correctly calculated order can be functionally right while load behavior or error handling is not yet ready for production. Together we define which evidence is required for each expansion step.

The agreed scope of delivery includes source code, reproducible builds and documentation. For go-live, we clarify data migration, training, responsibilities and how incidents are handled. Usage rights, third-party components and later maintenance are settled before the handover.

For business owners and technical teams

The decisions behind the implementation.

04

Business rules, transactions and competing changes

An application must also work correctly when several people change the same stock at the same time. Two reservations must not allocate the same last item without anyone noticing. We therefore determine which changes must succeed together and which conflicts require business feedback. Database constraints, transactions and version checks can solve different parts of this task; the user interface alone cannot enforce these rules.

Longer business processes, on the other hand, often do not fit into a single transaction. An order, an external payment service and a shipping approval each have their own failure states. We model the case with explicit states and permitted transitions. Repeated requests receive a suitable case identifier so that a connection failure does not automatically trigger a duplicate action. In the event of partial failures, a business-defined correction is needed, such as reversing an approval, instead of a blanket technical restart.

05

Tenants, roles and traceable data access

For SaaS products and internal platforms, we distinguish a user’s identity from their rights to a specific record. A logged-in employee must not automatically be able to read every invoice or every order. We check access in the backend at the level of organization, role and case. Exports, search indexes, background tasks and cached results must also respect these boundaries.

Shared tables with a tenant identifier, separate database schemas or dedicated databases each bring different requirements for isolation, migration and recovery. We choose the model based on the separation required and your operations organization. Tests with multiple tenants specifically check for unauthorized access. An audit log documents business-relevant changes with suitable context; what data it contains and how long it remains available is explicitly defined.

06

Data storage, performance and long-term extensibility

The data structure follows the queries and business rules. We examine typical filters, sorting, evaluations and write operations before introducing additional storage technologies. Unbounded result lists, repeated individual queries and large data transfers can slow an application down even though the server appears barely loaded. Measurements with realistic data volumes show whether indexes, query changes, pagination or a different division of tasks help.

Caching is a deliberate decision about timeliness: it must be defined when a stored result becomes invalid and which users are allowed to see it. Extensive calculations can run as background jobs, but then need progress indicators, restart capability and failure states. For extensions, we separate business rules from technical adapters. Automated tests and versioned database changes secure these boundaries so that a new channel or a different provider does not require changing every module.

Results you can verify

What you take away.

Result 01

Working application with source code and build pipeline

Result 02

Architecture documentation with threat model

Result 03

Operations manual with runbooks and emergency plan

Example project flow

This is what the engagement can look like.

Maintenance planning has so far been managed in spreadsheets. A business application brings together assets, appointments, responsibilities and approvals. The first expansion stage covers one site; further sites follow only after the business side has checked the process.

Illustrative scenario, not a customer reference or a guarantee of results.

This helps you get started

Examples of today’s workflows and exceptions
People responsible for business decisions
Existing systems, data sources and operating requirements

Missing documents are not an obstacle. We work out together which information needs to be gathered first.

Your project in detail

Model business rules clearly and implement them reliably.

Custom software pays off where your processes need a solution of their own. We develop not only user interfaces, but also the business rules, data structures and operational processes behind them.

Turn exceptions into a robust domain model

It is often the rare cases that determine the effort involved: partial approvals, retroactive changes or a case with several owners. We model states and permitted transitions together with the business unit. This shows which rules the software should enforce and where a reasoned manual decision remains necessary.

Permissions are tied to actions and data. Separation by organization or tenant must be effective in processing and queries, not only in hidden buttons. Change histories are provided wherever users later need to trace who changed a business state.

Plan data migration and product maintenance from the start

Existing data must be prepared and mapped to the new model. We check completeness, duplicates and invalid states before a production import takes place. A trial run produces not only a technical run time but also a business error list that can be worked through with your owners.

Requirements keep evolving after launch. That is why a clear structure, automated checks and a documented release path are part of the agreed scope of delivery. Source code access, usage rights, documentation and responsibility for maintenance are set out specifically in the contract, so that your product can be supported over the long term.

Illustrative project scenario

How the service helps in everyday use.

Example: An approval process needs deputies and different amount thresholds. We model these rules explicitly and also test changes of responsibility during an ongoing case. The result is a continuous workflow instead of a collection of disconnected input forms.

This example explains a possible process and is not a customer reference.

Before you place an order

Your questions about Custom software.

When does custom software make sense?

When special business rules, integrations or product features can only be achieved with standard software through unreasonable workarounds. For common baseline functions, an existing solution can be more economical. We clarify this distinction before the development contract is awarded.

How do we avoid depending on individual developers?

Shared code reviews, understandable module boundaries, documented decisions and reproducible builds spread knowledge. We also agree on access, usage rights and handover formats. This makes a later change of provider easier to plan, but it does not replace adequate knowledge transfer.

Is a fixed price possible?

For results that are clearly scoped both functionally and technically, a fixed price can be considered. Where requirements are still open, a preliminary analysis or smaller stages ordered one at a time are often more reliable. Changes to scope are assessed transparently for their impact on effort and schedule.

Useful combinations

Software consulting Web portals & apps Modernize software Develop interfaces Software testing DevOps & releases Software maintenance

The next step

Tell us where things are stuck today.

A short description of your application, the problem and your goal is enough to get started. The selected service is carried over into your contact request.

Request this service

Navigation

Your processes deserve software that fits.