Software engineering · Cloud architecture · Integration
Phone Island GmbH designs, builds and maintains software for organisations whose operations depend on it. We work in small engineering teams, in English, close to the systems we are responsible for.
Phone Island GmbH is a software company working across custom development, cloud architecture and systems integration. Our work is defined less by a single product than by a way of working: read the existing system carefully, describe the problem precisely, then change as little as necessary to solve it.
We take responsibility for the parts of a system we build. That means the deployment pipeline, the monitoring, the data migrations and the documentation are treated as part of the delivery, not as an afterthought handled once the feature is finished.
Engagements are structured so that the client always owns the result: the source code, the infrastructure definitions and the operational knowledge required to run the system without us.
Six areas cover most of our work. They are rarely used in isolation — a data platform needs integration work, a mobile release needs a backend that can be deployed safely. The full breakdown is on the services page.
Applications built around a specific operational process rather than adapted from a generic product.
Browser-based systems with server-rendered performance, accessible interfaces and predictable release cycles.
Environments defined as code, sized for real load, with a clear route from the current setup to the target one.
Interfaces between systems that never assumed the other side would exist, with contracts and error handling written down.
Pipelines that move data reliably, and automation that removes manual steps without hiding them.
Incremental replacement of ageing components, supported by tests that make each step safe to release.
We keep our stack deliberately narrow so that every engineer can review every part of it. New tools enter that stack only when there is a system that genuinely needs them.
The technical constraints differ by sector, but the requirement is the same: systems must behave predictably under load, and changes must be reversible.
Provisioning flows, subscriber data, billing interfaces and device management.
Dispatch, tracking, route data and integrations with carrier and warehouse systems.
Catalogue and order systems, stock synchronisation and payment integrations.
Reconciliation, reporting pipelines and controlled access to sensitive records.
Production data collection, machine interfaces and operational dashboards.
Structured clinical and administrative data with strict privacy requirements.
Internal tooling, document workflows and client-facing portals.
Accessible interfaces, auditable processes and long support horizons.
We read the systems, the data and the constraints, and write down what the problem actually is.
A written technical plan: components, interfaces, data flow, failure modes and the order of work.
Short delivery cycles, each one ending in something that runs in an environment you can inspect.
Automated tests, review and manual checks against the acceptance criteria agreed in advance.
Deployment through a repeatable pipeline, with a rollback path prepared before the change goes out.
Monitoring, documentation handover and a defined route for reporting and fixing issues.
Repeatable deployments, monitored services and reversible changes reduce the number of incidents that reach your users at all.
Tested, documented code means the second and third change to a system are not more expensive than the first.
You keep the repository, the infrastructure definitions and the runbooks, so the system is never dependent on one supplier.
Measurement comes before optimisation. Before we change how a system performs, we agree on what is being measured, how it is recorded and what an acceptable result looks like. Without that, performance work is guesswork.
Permissions are granted per role and per environment. Production access is limited to the engineers who need it, and credentials never live in source control.
Personal data is only collected where a feature requires it, encrypted in transit, and separated from analytical copies wherever that is possible.
Every change is reviewed by a second engineer. Dependencies are tracked and updated, and security-relevant updates are prioritised.
Automated tests cover the logic that matters most: money, permissions, and anything that writes to a database.
Backups are verified by restoring them. A change that cannot be rolled back is redesigned until it can be.
The situations below describe the kind of work we are asked to do. They are written as examples of our capabilities and do not describe named clients, results or engagements.
SC/01
The application works, but every release requires a full regression cycle. We map the modules, extract the highest-risk area behind a stable interface, add tests around it, and move it to its own deployment unit so the remainder can be released independently.
SC/02
Orders leave one system as an export and enter another as a manual import. We define the data contract, build an integration service with validation and retry behaviour, and add a reconciliation report so mismatches surface immediately instead of at month end.
SC/03
Figures are assembled by hand from several sources. We build a pipeline that loads each source on a schedule, records where every number came from, and exposes the result to reporting tools that operations staff can use themselves.
SC/04
Servers were configured by hand over several years. We describe the target environment as code, rebuild it from that definition, migrate workloads in stages, and leave a setup that can be recreated from the repository.
10 — Company principles
We would rather explain a constraint than promise around it.
A vague requirement produces a vague system. We write things down.
The smallest solution that holds under real conditions is the right one.
Progress, risks and mistakes are reported as they happen.
We build systems that outlast the engagement that produced them.
A short description of the system, the problem and the timeframe is enough to start. We reply with questions rather than a template. Full details are on the contacts page.
Phone Island GmbH
geraldinewright140@gmail.com
phoneislandgroup.com
