Section 01 — About
A company organised around engineering judgement.
Phone Island GmbH is a software engineering company. We describe ourselves through the way we work rather than through claims we cannot evidence: careful reading of existing systems, written plans, small releases, and long support horizons.
We build and maintain software for organisations whose daily operations depend on it. Our work spans custom applications, web and mobile front ends, cloud environments, data pipelines and the integrations that connect systems which were never designed to talk to each other.
Engagements are deliberately small in team size and long in horizon. A single engineer who understands a system fully is more useful than a large team that each understands a fragment. That structure shapes what we take on: work where we can genuinely learn the domain rather than deliver a specification blindly.
We do not publish client names, headcount, revenue figures or certification claims on this website. Where such information is relevant to an engagement, it is shared directly and in writing.
Mission
To build software that behaves predictably, can be understood by the people who own it, and continues to work when we are no longer involved.
Vision
A software industry where changing a running system is an ordinary, low-risk activity rather than an event that requires courage.
Five values we can be held to.
Honest estimation
An estimate is a statement about uncertainty. We give ranges, explain what would narrow them, and revise them in writing when we learn more.
Written thinking
Architecture decisions, trade-offs and rejected options are documented. A decision that exists only in a conversation is lost within weeks.
Small steps
Large releases hide risk. We prefer many small, reversible changes, each one observable in a running environment.
Respect for existing systems
Code that has run in production for years encodes knowledge. We understand it before proposing to replace it.
Craft over volume
We take on fewer engagements than we could in order to keep the standard of the work consistent.
How we work together.
One team, one system
Engineers stay with a system rather than rotating between engagements. Continuity of understanding is worth more than short-term flexibility.
Direct communication
You speak to the engineers doing the work. There is no account layer translating technical questions into commercial answers.
Shared repository
Work happens in your repository or in one handed over to you. Issues, decisions and reviews are visible to your team from the first day.
Written asynchronous default
Meetings are used for decisions that need discussion. Everything else is written, so it can be read later by people who were not present.
Knowledge transfer
Documentation and walkthroughs are part of delivery. The goal is that your own team can extend what we built.
Boring technology, applied carefully.
We favour tools with long track records, clear documentation and predictable upgrade paths. A well-understood relational database, a conventional deployment pipeline and a typed language solve most problems that appear in business software.
New technology is introduced when a specific requirement justifies it — a throughput limit, a data model that genuinely does not fit, a platform constraint. The justification is written down alongside the alternatives we considered.
We also decide deliberately what not to build. Where a well-maintained service or library already solves a problem correctly, we integrate it rather than reproduce it, and we document the dependency that this creates.
The standard we apply to our own work.
- Q/01
Reviewed
Every change is read by a second engineer before it is merged. Review covers correctness, readability and operational impact.
- Q/02
Tested
Automated tests cover business rules, permissions and data writes. Test coverage is a means of enabling change, not a target in itself.
- Q/03
Observable
Services log meaningfully, expose health information and raise alerts that a human can act on.
- Q/04
Accessible
Interfaces are built to WCAG 2.1 AA principles: keyboard operable, sufficient contrast, correct semantics and clear focus states.
- Q/05
Documented
Setup, deployment, configuration and known limitations are written down in the repository, not held individually.
Handle less data, protect what remains.
Our starting position on any system is that personal data is a liability as much as an asset. The less of it a system stores, the less can go wrong.
- Data is collected only where a described feature requires it.
- Access is granted per role and per environment, and reviewed when engagements change.
- Credentials and keys live in managed secret storage, never in source control.
- Traffic is encrypted in transit; sensitive fields are encrypted or separated at rest.
- Production data is not copied into development environments without anonymisation.
- Incidents are reported to the client promptly and in writing, with the facts we have.
Most of our work is second-year work.
Systems reveal their real requirements after they go live. Load patterns differ from the forecast, edge cases surface, and the business changes what it needs. We plan for that period rather than treating launch as the end of the engagement.
A long-term relationship is only healthy if the client could end it without damage. That is why ownership of code, infrastructure definitions and documentation sits with you from the beginning.
Where an engagement ends, we support the handover to your team or another supplier with the same care we apply to delivery.
Correspondence
geraldinewright140@gmail.com