Write it down
Decisions that are only spoken are decisions that will be disputed. Scope, assumptions, trade-offs and risks are recorded where the client can read them.
About the company
A small set of convictions about how software should be built.
This page describes how FISH & FLIPS LTD works and what we hold ourselves to. It contains no invented history, figures or credentials.
01 — Overview
Company overview
FISH & FLIPS LTD provides IT services and software solutions. Our work spans custom application development, web and mobile products, cloud environments, systems integration, interface design, testing and long-term maintenance. We take on both new systems and the repair, extension and modernisation of existing ones.
We are deliberately unromantic about software. Most of the value in a system appears after the launch announcement: in the changes that are easy to make, the incidents that are diagnosed quickly, and the handover that does not require the original author. We design for that period, because it is the longest one.
02 — Mission
To make software a dependable part of an organisation rather than a source of risk.
Organisations rarely need more software. They need software they can trust, change and explain. Our mission is to deliver systems that meet a real operational need, behave predictably under pressure, and remain workable for the people who inherit them. Where a smaller change, a better process or no software at all would serve the client better, we say so.
03 — Working principles
Principles we apply on every engagement
Smallest useful increment
We prefer delivering something narrow and working over something broad and unfinished. Progress is demonstrated, not described.
No hidden complexity
If part of a system is intricate, it is documented and explained rather than left as private knowledge.
Say no clearly
Requests that would damage the system, the timeline or the budget are challenged before they are accepted, not after.
Design for handover
Every engagement is written as though another team will take over next quarter, because eventually one will.
Measure before optimising
Performance and cost work begins with measurement of the real system, not with assumptions about where time goes.
04 — Technology
Approach to technology
We are not attached to a particular stack. The right choice depends on the problem, the environment it will run in, the skills of the team that will maintain it and the expected lifetime of the system. What stays constant is the way the decision is made.
- Fit before fashion
- A technology enters the shortlist because it solves the problem well, not because it is prominent this year.
- Operability
- How the system is deployed, observed, upgraded and recovered is part of the choice, not a later concern.
- Exit cost
- We consider what replacing a component would involve before committing to it, and keep business logic portable.
- Team reality
- A stack nobody on the maintaining side can support is the wrong stack, regardless of its technical merits.
05 — Collaboration
Collaboration philosophy
Good software comes out of a working relationship, not a specification handed over a wall. We ask for access to the people who actually perform the process being supported, and we expect to change our own assumptions once we have spoken to them.
- One named point of contact on our side who understands the whole engagement, not a rotating queue.
- A regular, short review of working software rather than long written status reports.
- Direct access between your subject-matter experts and the engineers doing the work.
- Decisions recorded with their reasoning, so a choice made in month one can be understood in month twelve.
- Early notice when something is at risk, together with the options for handling it.
- A defined end point for every engagement, including what is handed over and to whom.
06 — Quality standards
Quality standards we hold ourselves to
- Every change is reviewed by a second engineer before it reaches a shared branch.
- Automated tests cover business rules and integration points, and run on every change.
- Interfaces are checked against keyboard navigation, contrast and screen-reader behaviour.
- Performance is measured on realistic data volumes rather than development samples.
- Documentation is delivered with the code, not promised afterwards.
- Defects found after release are logged with a cause, not only a fix.
07 — Responsibility
Responsible technology practices
- We collect and store the minimum personal data a system needs to function, and we challenge requirements that ask for more.
- Access to client systems and data is limited to the people performing the work and revoked when the engagement ends.
- Accessibility is treated as a baseline requirement so that products remain usable by people relying on assistive technology.
- Automated decisions that affect people are made explainable, with a route for human review where it matters.
- We decline work intended to mislead users, obscure costs or make consent difficult to withdraw.
- Efficiency is a design goal: unnecessary computation, storage and data transfer are removed rather than tolerated.
08 — How the work looks
Most of it is thinking, writing and reading
An engagement rarely begins at a keyboard. It begins with questions: what does this process do today, who suffers when it fails, what has already been tried, and what must not change. The answers are drawn out, written down and reviewed with the people who gave them.
Only then does implementation start — and even then, a large part of engineering is reading existing code carefully enough to change it without surprises. The visible output is a working system. The invisible output is a set of decisions that can be explained years later.
09 — Contact details
Getting in touch
All enquiries reach us by email. If you would prefer a structured form, the Contacts page provides one. A summary of what we do is on the Services page.
- Company
- FISH & FLIPS LTD