01
Boring technology, chosen deliberately
Preference for well-understood tools with long support horizons. New technology is adopted when it removes a specific, named problem — not because it is new.
Software engineering practice
Systems built to be understood, operated and changed.
BIRD & GORTON LTD is an information technology company working on custom software, business systems, integrations and the infrastructure that supports them. The work is deliberately unglamorous: define the problem precisely, build the smallest thing that solves it well, and leave behind a system the client's own people can maintain.
- Discipline
- Software engineering
- Scope
- Build, integrate, maintain
- Method
- Incremental delivery
Overview
An engineering company, not a marketplace of trends
BIRD & GORTON LTD works with organisations whose daily operations depend on software, whether that software faces customers or runs quietly behind an office wall. The company takes on work where the technical problem is real and the constraints are known: an application that must be built, a process that must be automated, two systems that must exchange data reliably, or a platform that has become difficult to change.
Engagements begin with understanding rather than with a proposal. Before an architecture is drawn or a framework chosen, the problem is described in ordinary language and agreed with the people who will live with the result. That single habit removes most of the misunderstanding that makes software projects expensive.
Core capabilities
Four areas of practical engineering work
- 01
Application engineering
Web applications and internal platforms built from a defined domain model, with explicit state handling, predictable data flow and interfaces that reflect how the work is actually performed.
- 02
Data and integration
Connecting systems that were never designed to talk to each other: scheduled synchronisation, event-driven messaging, API layers, transformation logic and reconciliation reporting.
- 03
Infrastructure and deployment
Environments defined in code, repeatable build and release pipelines, observability, backup and restore procedures, and cost-aware use of cloud resources.
- 04
Technical assessment
Structured review of an existing codebase, architecture or delivery process, followed by a written account of the risks found and the sequence in which they can reasonably be addressed.
Problems addressed
The situations that usually prompt the first conversation
- Work that depends on spreadsheets
- Critical processes held together by shared files, manual copying and personal conventions. We replace the fragile parts with systems that record who changed what, and when, without discarding the working knowledge behind them.
- Systems that no longer connect
- Separate tools each holding a partial version of the truth. We define where each record originates, how it moves, and what happens when a transfer fails.
- Software nobody wants to change
- Codebases where a small change carries unclear risk. We introduce tests, boundaries and documentation incrementally so that change becomes routine again.
- Growth outpacing the platform
- Applications that were adequate at one scale and are now slow, expensive or unstable. We measure before rewriting, and address the causes that the measurements actually support.
Service categories
Work grouped by what it is for
Each category is described in detail on the Services page, including typical scope and the general approach to delivery.
Build
- Custom software development
- Web application development
- Business systems and internal tools
Connect
- Systems integration
- API design and implementation
- Data migration and mapping
Operate
- Cloud and infrastructure consulting
- Maintenance and ongoing improvement
- Quality assurance and technical review
Advise
- Technical consulting
- Software modernisation
- Security-conscious engineering
Delivery process
Five phases, applied proportionally
The sequence below describes a full engagement. A short piece of work compresses it; a long one repeats phases three and four. The order does not change, because each phase depends on the written output of the one before it.
Phase one / 01
Understand the problem
Conversations with the people who use the system, a review of the existing technical material, and a written statement of the problem in plain language before any solution is proposed.
Phase two / 02
Define scope and shape
An outline of the intended architecture, the boundaries of the work, the assumptions being made and the decisions that still need an answer. Scope is agreed in writing.
Phase three / 03
Build in reviewable increments
Work is delivered in small, demonstrable pieces. Each increment is deployable, tested and reviewed, so direction can be corrected early rather than at the end.
Phase four / 04
Harden and hand over
Automated checks, operational documentation, deployment and rollback procedures, and a handover that leaves the client's own team able to operate and extend the system.
Phase five / 05
Support what was built
Ongoing correction, dependency maintenance and measured improvement, with a clear record of what changed and why.
Engineering principles
Technology choices are made to reduce future cost, not present excitement
02
Readable before clever
Code is read far more often than it is written. Naming, structure and explicitness are treated as engineering requirements, not stylistic preferences.
03
Automate the repeatable
Builds, tests, migrations and deployments run the same way on every machine. Manual steps are documented where automation is not yet justified.
04
Decisions recorded
Architectural choices are written down with their context and trade-offs, so that future maintainers understand the reasoning rather than guessing at it.
Non-functional requirements
Security, maintainability and scalability are design inputs
These qualities are difficult to add to a finished system and inexpensive to build into one. They are treated as requirements from the first design conversation and revisited at every review.
Security
- Least-privilege access for services, environments and people
- Secrets held outside source control and rotated on a defined schedule
- Input validated at every boundary, not only in the interface
- Dependencies monitored and updated as part of routine maintenance
Maintainability
- Clear module boundaries with limited, intentional coupling
- Automated tests covering the behaviour that matters most
- Documentation kept beside the code it describes
- Consistent conventions applied across the codebase
Scalability
- Load characteristics measured before capacity is added
- Stateless services where the workload allows horizontal growth
- Query and index review as data volume increases
- Caching and queueing applied where they resolve a measured constraint
Types of organisation
Where this kind of engineering tends to be useful
The following describes the categories of organisation the company is equipped to support. It is a statement of capability rather than a list of engagements.
Professional services firms
Practices that manage client work, documents and billing across several disconnected tools, and need consistent records across them.
Operations-led businesses
Logistics, field service, manufacturing and distribution work where scheduling, tracking and reporting drive daily decisions.
Digital products
Teams maintaining a customer-facing application who need additional engineering depth, a technical review, or a modernisation path.
Non-profit and membership organisations
Organisations with limited internal technical capacity that need dependable systems and clear, unhurried explanations.
Collaboration
How the working relationship is set up
Written before spoken
Proposals, scope and decisions exist in writing so they can be reviewed, questioned and referred back to later.
One point of accountability
Each engagement has a named engineering contact who is responsible for progress and for raising problems early.
Estimates with their assumptions
Every estimate is presented together with what it assumes. When an assumption proves wrong, the estimate is revised and the reason explained.
Client ownership
Source code, infrastructure definitions and documentation belong to the client and are handed over in a usable state.
In summary
Careful software, described plainly and maintained properly
BIRD & GORTON LTD builds and looks after software systems for organisations that need technology to be dependable rather than impressive. Enquiries describing the current situation, the constraints involved and the outcome being sought are welcome by email.