Manual work absorbing capacity
Spreadsheets, re-keyed data and email approvals holding a process together. The cost is invisible until someone measures the hours spent maintaining the workaround.
Information technology · Engineering · Delivery
Software that keepsworking after launch
FOOT FORMULA LIMITED builds, integrates and maintains the systems businesses run on. The work is deliberately unglamorous: well-structured code, documented decisions, predictable releases and infrastructure that behaves the same on a quiet Tuesday as it does under load.
- Practice
- Custom software engineering
- Also
- Design, integration, infrastructure, data
- Method
- Discovery, iteration, measured release
- Language
- English
01 — Introduction
An engineering company, organised around the systems clients depend on
FOOT FORMULA LIMITED provides practical technology services for organisations whose operations, revenue or reporting depend on software. That includes systems built from scratch, systems inherited from earlier teams, and systems assembled over the years from separate tools that never quite agreed with one another.
The company's role is to make those systems understandable and changeable. Before code is written, the existing behaviour is mapped: what the software does, who relies on each part of it, where data enters and leaves, and which constraints are technical rather than habitual. Decisions taken from that basis tend to survive contact with production.
Engagements are shaped to the problem. Some are short pieces of advisory work that end with a written recommendation. Others run for months as a delivery stream alongside an internal team. In all cases the intent is the same: leave behind a system the client can operate, explain and extend without depending on the people who built it.
02 — Core capabilities
Capability set
Six areas of practice that combine within a single engagement rather than being sold as separate products.
- 01
Application engineering
Server-side and browser-side application code, from data model through interface, written to be read by the next engineer rather than only by its author.
- 02
Interface and product design
Interaction design and interface work grounded in the actual task a user performs, tested against real content and real edge cases before it reaches development.
- 03
Integration
Connecting applications, third-party services and internal systems so information moves once, in one direction, with a clear record of what happened.
- 04
Infrastructure and operations
Environments, deployment pipelines, monitoring and recovery procedures that make releases routine instead of eventful.
- 05
Data engineering
Storage design, transformation pipelines and reporting layers that produce figures the business is willing to act on.
- 06
Maintenance and modernisation
Ongoing care for systems already in production: dependency currency, defect resolution and staged replacement of components that have outlived their design.
03 — Challenges addressed
The situations that usually prompt a conversation
A system nobody can safely change
Software still doing its job, but with no tests, no documentation and no one left who understands the original decisions. Every change carries unquantified risk.
Tools that do not share data
Separate systems each holding part of the truth, reconciled by hand. Reporting becomes an argument about which number is correct.
Releases that are disruptive events
Deployment requires downtime, manual steps and a rollback plan nobody has rehearsed, so improvements are batched up and shipped rarely.
Growth outpacing the architecture
A design that was correct at an earlier volume now producing timeouts, queue backlogs and rising infrastructure cost.
Uncertainty before committing
A proposed product or platform change where the technical feasibility, effort and sequencing need examination before budget is allocated.
04 — Services overview
What the company delivers
Services are described here at summary level. Each is set out in full on the Services page, including the business problem it addresses, its typical scope and the kind of outcome it produces.
- Custom software development
- Systems built to a specific operational process rather than adapted to a generic product.
- Web application development
- Browser-delivered applications for customers, partners or internal users.
- IT consulting
- Independent assessment of architecture, tooling and delivery practice.
- Product design and UX
- Research, structure and interface design ahead of engineering.
- System integration
- Reliable movement of data between applications and services.
- Cloud and infrastructure
- Environments, pipelines, observability and cost visibility.
- Data solutions
- Models, pipelines and reporting layers fit to decide on.
- Maintenance and modernisation
- Continued care and staged renewal of production systems.
- Quality assurance
- Automated and exploratory testing built into delivery.
- Security-conscious development
- Security treated as a property of the build, not a later review.
05 — Working approach
How the work is organised
Understand before building
Every engagement starts by describing the current state in writing — systems, data, users, constraints. Ambiguity found at this stage is inexpensive.
Small, reversible steps
Work is divided so that each increment can be reviewed, released and, if necessary, withdrawn without disturbing the rest of the system.
Written decisions
Architectural choices are recorded with their reasoning and their alternatives, so that a future reader understands why the system looks the way it does.
Visible progress
Demonstrations in a shared environment replace narrative status updates. What is running is what is reported.
Client ownership
Repositories, environments, credentials and documentation belong to the client throughout, not at the end.
Honest scope
Where an estimate is uncertain, the uncertainty is stated with it. Where a request is not the best route to the outcome, that is said plainly.
06 — Technology and delivery principles
Technology chosen for its second year, not its first week
Technology selection follows the requirement. Established, well-documented tools are preferred where they fit, because the cost of a system is dominated by the years after it is written: hiring for it, patching it, explaining it and changing it.
Delivery practice is consistent across engagements. Source control with reviewed changes, automated builds, environments that resemble production, migrations that can be replayed, and configuration held outside the codebase. Logging and metrics are added while a feature is being built, not after an incident makes them necessary.
Performance and accessibility are treated as requirements with acceptance criteria. Interfaces are built to work with a keyboard, to meet contrast expectations, and to remain usable on modest devices and constrained connections.
07 — Business contexts served
Contexts the work suits
The company does not claim sector specialisation. What follows describes the kinds of operational context where this way of working tends to be a good fit.
Operations-heavy businesses
Scheduling, logistics and fulfilment processes where software coordinates people and physical work.
Professional services
Firms managing engagements, documents and billing across teams and clients.
Product organisations
Teams shipping a software product continuously and needing extra engineering depth.
Retail and commerce
Catalogue, order and stock systems integrated with storefronts and payment providers.
Education and training
Content delivery, enrolment and progress tracking with clear data handling.
Regulated administrative work
Environments where auditability and record integrity matter as much as features.
08 — Security and reliability
Reliability is designed in, then verified
Least privilege
Access to systems and data is granted narrowly and reviewed as roles change.
Secrets management
Credentials live in managed secret stores, never in source control or documentation.
Input handling
Data entering a system is validated at its boundary and encoded correctly on output.
Dependency hygiene
Third-party packages are tracked, updated and removed when they stop earning their place.
Backup and recovery
Backups are defined with a restoration procedure that is tested, not assumed.
Observability
Logs, metrics and alerts are specified so that failures are noticed before users report them.
Data minimisation
Personal data is collected only where a purpose requires it, with retention agreed in advance.
Incident practice
Failures are documented, reviewed without blame, and answered with a concrete change.
09 — Collaboration process
From first message to steady operation
- 01
Enquiry
A written description of the situation, the systems involved and the outcome sought.
- 02
Discovery
A short, bounded review of the current state, producing a written summary of findings and options.
- 03
Scope and sequence
Work broken into increments with dependencies, assumptions and open questions stated.
- 04
Design
Data model, interfaces and interaction structure agreed before implementation begins.
- 05
Build and review
Implementation in reviewed increments, demonstrated in a shared environment.
- 06
Verification
Automated and exploratory testing against agreed acceptance criteria.
- 07
Release
Deployment through a repeatable pipeline, with monitoring and a rehearsed rollback path.
- 08
Operation
Agreed ongoing support: observation, defect resolution and incremental improvement.
10 — Frequently asked questions
Questions asked before starting
- What kind of organisations does FOOT FORMULA LIMITED work with?
- The company works with organisations that operate software as part of their daily business: teams running internal tools, customer-facing web applications, data pipelines or integrated back-office systems. Engagements are scoped to the technical situation rather than to a fixed company size.
- How does an engagement usually begin?
- An engagement typically begins with a written description of the current situation, the systems involved and the outcome being sought. From there a short discovery phase clarifies scope, constraints and sequencing before any implementation work is agreed.
- Can the company work alongside an in-house technical team?
- Yes. Work can be structured as a self-contained delivery stream or as additional capacity inside an existing team, following the conventions, review process and tooling that team already uses.
- How is progress made visible during delivery?
- Progress is shown through working software in a shared environment, accompanied by written notes on what changed, what is in progress and what decisions are pending. Demonstrations are preferred over status reports.
- What happens after a system goes live?
- Post-release work covers monitoring, defect resolution, dependency updates and incremental improvement. The scope and duration of that support are agreed in advance rather than assumed.
- In which language does the company communicate?
- All documentation, correspondence and delivery communication are handled in English.
11 — Contact information
Written enquiries are read by the people who do the work
Correspondence is handled by email in English. A message describing the current systems, the difficulty being experienced and the outcome being sought allows a useful reply without a preliminary call.
- Company
- FOOT FORMULA LIMITED
- [email protected]
- Domain
- footformulacare.com
- Language
- English