01
Application engineering
Server-rendered and client-side applications built on typed codebases, with clear module boundaries and readable data flow.
/Information technology company
Systems
built to
be maintained
ASO Immobilienservice GmbH is an IT services company. We design, build and look after software, cloud infrastructure and data platforms — the unglamorous layer that decides whether a business can change its mind next quarter.
01Who we are
An engineering practice, not a product catalogue
We work as a technical partner for organisations whose operations depend on software they did not set out to build. Some of that software is new; much of it already exists, carries years of decisions inside it, and cannot be switched off while it is improved. Both situations call for the same discipline: understand the system honestly, change it in small verifiable steps, and leave it easier to reason about than it was before.
The company operates under the registered name ASO Immobilienservice GmbH and provides information technology services. Our engagements are shaped around a defined technical problem rather than a fixed package, because the useful answer to "what should we build" is almost never available before someone has looked closely at the constraints.
We describe what we do and how we do it. We do not publish claimed results, guaranteed timelines or performance figures we cannot substantiate.
02Core expertise
Six areas of technical depth
These areas overlap in practice. Most work touches at least three of them, which is why they are held by one team rather than handed between specialists.
02
Platform and cloud
Environments described in configuration, provisioned repeatably, and observable enough to answer questions without guesswork.
03
Integration
Contract-first interfaces between systems that were never designed to speak to one another, with explicit failure handling.
04
Data engineering
Pipelines, models and storage layouts that turn scattered operational records into a dependable reporting surface.
05
Secure engineering
Threat-aware defaults: least privilege, validated input, managed secrets, dependency review and audit trails.
06
Interface design
Design systems and interaction patterns that keep dense professional software legible and accessible.
03Software development
Code written to be read again
Most of a system's cost arrives after the first release, when someone unfamiliar with it has to change it under time pressure. We optimise for that moment: explicit types, narrow interfaces, straightforward control flow, and tests that describe intent rather than restate the implementation.
Work is delivered in increments that can be reviewed, deployed and reverted independently. Architecture decisions are written down alongside the code, including the options that were rejected and the reason.
04Cloud infrastructure
Environments you can rebuild
Infrastructure is defined as code so that staging and production differ by configuration rather than by history. Networking, identity, storage and compute are versioned together with the application they support.
We instrument systems before they need it: structured logs, metrics tied to real user outcomes, and traces across service boundaries. Cost and capacity are treated as engineering signals, reviewed alongside latency and error rates.
05Systems integration
Making unrelated systems agree
Integration work is mostly about disagreement: two systems hold overlapping records, use different identifiers, and were built with different assumptions about time, currency and ownership. We resolve that explicitly, in a documented contract, instead of hiding it in a scheduled script nobody wants to open.
- Contract-first API definitions with versioning rules
- Idempotent operations and safe retry behaviour
- Explicit reconciliation for records that drift apart
- Dead-letter handling with a readable audit trail
06Data platforms
From records to a reliable answer
Reporting fails for structural reasons more often than analytical ones: the same figure is defined twice, a load silently skipped a day, or nobody can say where a number came from. We build the plumbing that removes those failure modes — tested transformations, versioned models, and lineage that survives a change of team.
07Security-conscious engineering
Defaults that fail closed
Security is an engineering property, not a review stage at the end. Access is scoped to the smallest workable permission, secrets are managed outside the codebase, input is validated at every boundary, and dependencies are tracked so a published vulnerability becomes a task rather than a surprise.
- Least privilege
- Identity and data access scoped per service and per role.
- Managed secrets
- Credentials injected at runtime, rotated, never committed.
- Validated boundaries
- Schema validation on every external input and response.
- Dependency review
- Automated scanning with a defined path for remediation.
These are engineering practices. They reduce risk; they are not a claim of certification or of compliance with any specific standard.
08Interface and experience
Dense software, still legible
Professional tools carry more information per screen than consumer products, and the people using them work fast. Design work here means information hierarchy, predictable states, and interaction patterns that behave identically wherever they appear.
Interfaces are built as a token-driven system: colour, spacing, type scale and component variants defined once. Keyboard operation, focus order, contrast and reduced-motion behaviour are part of the specification rather than a later fix.
09Reference architecture
How the layers fit together
A simplified view of the structure most of our systems share. Concrete projects add or remove layers, but the separation between interface, application logic, integration and data — with observability and security cutting across all of them — stays constant.
10Delivery
A cycle, run deliberately
Discover and shape
We read the existing system, its data and its deployment path, then write down the problem, the constraints and the options. Nothing is estimated before this exists.
Build and verify
Work proceeds in small increments behind automated checks. Each increment is demonstrable, and each is reviewed by someone other than its author.
Release and operate
Releases are repeatable and reversible. What we learn from running the system in production feeds directly into the next cycle of work.
11Quality assurance
Checks that run without being remembered
Testing is part of the delivery pipeline, not a phase. Static analysis and unit tests run on every commit; integration tests exercise real boundaries against disposable environments; accessibility and performance budgets are asserted automatically.
Manual testing is reserved for what automation reads badly: exploratory work on new behaviour, judgement about interface clarity, and verification of migration and recovery procedures.
12Maintenance and support
After the launch, the long part
Software in use is never finished. Dependencies age, traffic patterns shift, regulation changes, and the business asks for something the original model did not anticipate. Ongoing support covers that reality: routine updates, monitoring and alerting, incident response with a written follow-up, and a backlog of small improvements handled in a predictable rhythm.
Where an organisation prefers to operate its own systems, we prepare handover material — runbooks, architecture notes, environment inventory and access model — and stay available for review rather than daily involvement.
13Frequently asked questions
Questions we are asked first
- What kind of technical work does the company take on?
- Custom application development, cloud and platform engineering, integration between existing systems, data pipelines and analytics layers, interface design, testing, and ongoing maintenance of software already in production.
- Do you work with systems you did not originally build?
- Yes. A large share of engineering work involves existing codebases and infrastructure. That work starts with reading the system as it is — its data, deployment path and known weak points — before any change is proposed.
- How is scope decided?
- Scope is derived from the problem rather than from a fixed package. Discovery produces a written description of the current state, the constraints, and the smallest useful piece of work that can be delivered and verified.
- Which technologies are used?
- Selection follows the requirement, the operating environment and the skills available to maintain the result afterwards. Mainstream, well-documented tooling is preferred over novelty, and the reasoning behind each choice is written down.
- How is quality handled?
- Through automated checks in the delivery pipeline: static analysis, unit and integration tests, review of every change, and release verification. Accessibility and performance are treated as functional requirements, not afterthoughts.
- How do you communicate during a project?
- In writing, with a regular cadence. Decisions, open questions and trade-offs are recorded so anyone joining later can reconstruct why the system looks the way it does.
- What happens after a release?
- Maintenance covers dependency and security updates, monitoring, incident response, and incremental improvement. Handover documentation is prepared so an internal team can operate the system independently if preferred.
- How can the company be reached?
- Enquiries about IT services can be sent by email to anthonywils27@gmail.com. A short description of the system, the problem and the constraints is enough to begin a conversation.
14Company and contact
Write to us about
technical work
Enquiries about software development, cloud infrastructure, integration, data platforms, design, testing or ongoing support are welcome. A short description of the system and the problem is enough to start.
ASO Immobilienservice GmbH
anthonywils27@gmail.com
asorealtygroup.com