Skip to main content
FISH & FLIPS LTD

Services

Ten engineering disciplines, described in the terms they are actually delivered in.

Each service below sets out what the work involves, when organisations typically need it, how we run it and what you receive at the end. Most engagements combine several. If you are unsure which applies, describe the situation on the Contacts page and we will say which parts are relevant.

01

Custom Software Development

Systems shaped around one organisation's process rather than a generic product.

Custom development is appropriate when an operational process is specific enough that configuring an off-the-shelf product would cost more in workarounds than building the right thing. We model the process, agree the rules that govern it, and build a system that expresses those rules directly so they can be changed later without archaeology.

Typical use cases

  • An internal workflow currently held together by spreadsheets and email
  • A commercial product that must behave in a way no packaged tool supports
  • Replacing several overlapping tools with one system of record
  • Automating a manual step that has become a bottleneck as volume grows

How the work runs

  1. 1Process mapping with the people who perform the work
  2. 2Domain and data modelling, with the business rules stated explicitly
  3. 3Architecture and interface design proportionate to the risk
  4. 4Incremental implementation with review and automated testing
  5. 5Deployment, documentation and handover

Possible deliverables

  • Source code in a repository you own
  • Data model and architecture documentation
  • Automated test suite and build pipeline
  • Deployment and operations notes

02

Web Application Development

Browser-based products that stay fast, accessible and maintainable as they grow.

Web applications are where most business software now lives. We build them with attention to the parts that decay first: page performance under real data, state management as features accumulate, and accessibility for keyboard and screen-reader use. Server-rendered output is preferred where it improves first-load performance and indexability.

Typical use cases

  • A customer-facing portal for accounts, orders or documents
  • An internal administration or operations console
  • A public site where search visibility and load time matter
  • Replacing a legacy desktop tool with a browser-based equivalent

How the work runs

  1. 1Task analysis and interface specification
  2. 2Component and state architecture agreed before build
  3. 3Implementation with continuous integration and automated checks
  4. 4Accessibility, performance and cross-browser verification
  5. 5Release with monitoring in place

Possible deliverables

  • Responsive application covering the agreed browsers and screen sizes
  • Reusable component library and design tokens
  • Accessibility and performance test results
  • Release and rollback procedure

03

Mobile Product Development

Applications for phones and tablets, together with the services behind them.

Mobile work extends beyond the application itself to the backend services, authentication, offline behaviour and release process that surround it. We plan for intermittent connectivity, device diversity and store review cycles from the beginning, because retrofitting those concerns is expensive.

Typical use cases

  • A field-work application used away from reliable connectivity
  • A customer-facing companion to an existing web product
  • An internal tool that depends on device features such as camera or location
  • Consolidating separate platform-specific applications

How the work runs

  1. 1Platform and distribution decisions based on your audience and constraints
  2. 2Interaction design against real device dimensions
  3. 3Implementation with automated and on-device testing
  4. 4Store submission preparation and release configuration
  5. 5Post-release monitoring of crashes and adoption

Possible deliverables

  • Application builds for the agreed platforms
  • Backend services and API documentation
  • Release configuration and signing procedure
  • Crash reporting and analytics wiring, where agreed

04

Cloud Solutions

Environments that can be rebuilt from a repository rather than remembered.

Cloud work covers environment design, deployment automation, scaling behaviour, observability and cost visibility. We describe infrastructure as code so that development, staging and production stay comparable, and so that recovery is a procedure rather than an improvisation.

Typical use cases

  • Moving a system from self-managed servers to a managed environment
  • Replacing manual deployments with an automated pipeline
  • Bringing cloud spending under control after unplanned growth
  • Establishing separate, consistent environments for a growing team

How the work runs

  1. 1Review of the current environment, deployment path and costs
  2. 2Target architecture with scaling, backup and recovery defined
  3. 3Infrastructure expressed as code and applied through review
  4. 4Pipeline construction with automated verification
  5. 5Observability, alerting and runbook preparation

Possible deliverables

  • Infrastructure-as-code repository
  • Automated build and deployment pipeline
  • Monitoring dashboards and alert definitions
  • Backup, restore and rollback runbooks

05

API and Systems Integration

Reliable paths between systems that were never designed to meet.

Integration is mostly about failure. Two systems exchanging data will eventually disagree, and the value of the work lies in how those disagreements are detected, reported and resolved. We design integrations with explicit contracts, idempotent operations, retry behaviour and reconciliation, rather than optimistic one-way transfers.

Typical use cases

  • Connecting a finance, CRM or ERP system to an operational tool
  • Publishing an API for partners or customers
  • Replacing scheduled file transfers with an event-driven exchange
  • Consolidating duplicated records across systems

How the work runs

  1. 1Mapping the data, its owners and its authoritative source
  2. 2Interface contract definition and versioning strategy
  3. 3Implementation with error handling, retries and idempotency
  4. 4Reconciliation and monitoring for silent failures
  5. 5Documentation for the teams on both sides

Possible deliverables

  • Documented API or integration service
  • Contract specification and versioning policy
  • Error handling, retry and reconciliation logic
  • Integration test suite

06

UI/UX Design

Interfaces designed around the tasks people actually perform.

Design work begins with the task, not the screen. We establish what people are trying to achieve, where the current interface obstructs them, and which states — empty, partial, error, overloaded — are being ignored. The output is a specification detailed enough to build from, tied to the same component vocabulary the engineers use.

Typical use cases

  • An existing product where users make repeated mistakes
  • A new product that needs a coherent interface language from the start
  • Bringing consistency to an interface built feature by feature
  • Improving accessibility to meet organisational requirements

How the work runs

  1. 1Task and journey analysis with real users where available
  2. 2Information architecture and navigation structure
  3. 3Interaction design covering all interface states
  4. 4Visual system, typography scale and design tokens
  5. 5Specification and review alongside implementation

Possible deliverables

  • Interface specifications covering primary and edge-case states
  • Design token set aligned with the implemented components
  • Accessibility notes and contrast documentation
  • Reusable pattern library

07

Software Modernisation

Replacing ageing systems piece by piece, without stopping the business.

Rewrites fail more often than they succeed, usually because the old system's behaviour was never fully understood. We favour incremental modernisation: characterise the current behaviour with tests, isolate a component, replace it behind a stable interface, and repeat. The business keeps running throughout.

Typical use cases

  • A system whose original authors have left the organisation
  • A platform stuck on an unsupported runtime or database version
  • A codebase where every release requires extensive manual testing
  • Separating a monolithic system so parts can evolve independently

How the work runs

  1. 1Assessment of the existing code, data and deployment path
  2. 2Characterisation tests to capture current behaviour
  3. 3A sequenced plan with the riskiest dependencies addressed first
  4. 4Incremental replacement behind stable interfaces
  5. 5Decommissioning of superseded components

Possible deliverables

  • Assessment report with risks and sequencing
  • Characterisation test suite for existing behaviour
  • Replaced components with documentation
  • Migration and decommissioning plan

08

Technical Consulting

A time-boxed, written answer to a specific technical question.

Consulting engagements are appropriate when a decision needs an outside view: whether an architecture will hold, whether a technology choice is sound, why delivery has slowed, or what a proposed programme of work would realistically involve. We conclude with written findings and prioritised recommendations rather than a verbal impression.

Typical use cases

  • Reviewing an architecture before a significant investment
  • Assessing an inherited codebase during due diligence
  • Diagnosing why a delivery process keeps missing its dates
  • Choosing between build, buy and integrate options

How the work runs

  1. 1Agreement on the question, the scope and the time box
  2. 2Review of code, infrastructure, documentation and process
  3. 3Interviews with the people involved in delivery
  4. 4Written findings with evidence and prioritised recommendations
  5. 5Review session to work through the findings

Possible deliverables

  • Written findings report
  • Prioritised recommendations with estimated effort
  • Risk register for the areas reviewed
  • Optional follow-up implementation plan

09

Quality Assurance

Testing built into delivery rather than appended to it.

Quality assurance works when it runs continuously and blocks bad changes automatically. We build automated coverage around business rules and integration points, add exploratory testing for the things automation cannot judge, and make results visible in the pipeline so that a failing check stops a release rather than generating a ticket.

Typical use cases

  • Defects that reappear release after release
  • A manual regression cycle that delays every deployment
  • A product with no automated coverage inherited from another team
  • Preparing a system for higher load or wider release

How the work runs

  1. 1Review of current coverage, defect history and release process
  2. 2Test strategy covering unit, integration and end-to-end levels
  3. 3Automation implemented in the delivery pipeline
  4. 4Exploratory and accessibility testing for judgement-based checks
  5. 5Reporting so quality trends are visible over time

Possible deliverables

  • Documented test strategy
  • Automated test suites integrated into the pipeline
  • Defect reports with reproduction steps
  • Release readiness checklist

10

Maintenance and Support

Keeping a working system working, deliberately rather than reactively.

A live system needs attention regardless of whether anything appears to be wrong: dependencies age, certificates expire, data grows, and usage patterns change. A maintenance arrangement covers monitoring, corrective work, security updates and a defined process for responding when something does fail.

Typical use cases

  • A system in production with no assigned engineering owner
  • Dependencies and runtimes falling behind supported versions
  • Recurring incidents that are resolved but never diagnosed
  • A need for a defined response process outside office hours

How the work runs

  1. 1Handover and review of the existing system and its history
  2. 2Monitoring and alerting brought to an agreed baseline
  3. 3Defined intake, triage and response procedure
  4. 4Scheduled dependency and security update cycles
  5. 5Periodic review of incidents, trends and planned improvements

Possible deliverables

  • Support arrangement with a documented response process
  • Monitoring, alerting and escalation configuration
  • Maintenance log and dependency update record
  • Periodic service review notes

Scope and expectations

What we do not promise

We do not quote guaranteed business outcomes, fixed percentage improvements or delivery dates set before the problem has been examined. What we can commit to is a defined scope, a documented way of working, visible progress and honest reporting when something changes. Estimates are given with their assumptions attached, and revised in writing when those assumptions turn out to be wrong.

Enquiries: louisegomez1993@gmail.com

Blue light trails sweeping through an illuminated concrete corridor in a long exposure