Custom software development
Systems shaped around a specific operational process, where general-purpose products do not fit.
Sheet 01 — Information technology services
CHAIRBEARS
HUNTON LTDSoftware built to specification, documented and maintained.
CHAIRBEARS HUNTON LTD is an information technology company. It designs and develops custom software, builds and modernises web applications, sets up and maintains cloud infrastructure, connects systems that were never intended to talk to one another, and supports those systems after they are running. Work is carried out as engineering: requirements written down, decisions recorded, changes tested, and handover made complete enough that the client is never dependent on undocumented knowledge.
- Discipline
- Software engineering
- Scope
- Build, integrate, maintain
- Contact
- By email
Fig. 01 — Reference platform plan
02Company introduction
An engineering company, not a software shop that ships and disappears
Most organisations do not have a software problem in isolation. They have an operational process that software is supposed to support, and the software has either never fitted it properly or has drifted away from it over years of small changes. CHAIRBEARS HUNTON LTD works from that starting point: understand the process, then build or repair the system that serves it.
That means the first output of an engagement is usually written rather than executable — a clear statement of what the system must do, what it must not do, where its data comes from and who is accountable for each part of it. Only when that is agreed does implementation begin. It is slower for a week and considerably faster for the remaining months.
The company works with organisations of different sizes and in different sectors. What they tend to share is a dependence on systems that must keep running while they are being improved, and a preference for suppliers who explain their reasoning instead of presenting conclusions.
03Core technology capabilities
Capabilities across the full stack of a working system
- 01
Application engineering
Server-side services, browser front ends, background processing and scheduled jobs, built around explicit domain models rather than ad hoc scripts.
- 02
Data layer design
Relational schema design, migrations that can be run repeatedly and safely, query performance work, and reporting structures separated from transactional load.
- 03
Interfaces and APIs
HTTP and message-based interfaces with versioning, validation and documented contracts, so that consuming systems can be changed independently.
- 04
Infrastructure and deployment
Environment definitions kept in code, repeatable build and release pipelines, configuration separated from artefacts, and rollback treated as a normal operation.
- 05
Observability
Structured logging, health checks and metrics chosen to answer real operational questions rather than to fill a dashboard.
04Services overview
What the company delivers
Ten service areas, each described in full on the Services page. In practice an engagement usually draws on several of them at once, because a system rarely needs only one kind of attention.
Web application development
Browser-based applications with real state, permissions and workflow, designed for daily use.
Cloud and infrastructure
Hosting environments defined in code, sized to actual load and reproducible from scratch.
Systems integration
Reliable exchange of data between applications, including legacy systems and third-party services.
Technical consulting
Independent assessment of architecture, delivery practice and technical risk, delivered in writing.
Software modernisation
Incremental replacement and refactoring of ageing systems while they remain in production.
Quality assurance
Automated and manual testing arranged around the behaviour that carries the most business risk.
Maintenance and support
Ongoing correction, dependency updates and small improvements after release.
Security-conscious engineering
Authentication, authorisation, data protection and dependency hygiene handled during design.
Data and automation
Pipelines, reporting structures and the removal of repetitive manual steps from routine work.
05Business challenges addressed
Problems this kind of work is meant to solve
Manual work that should not still be manual
Data re-keyed between systems, reports assembled by hand each month, approvals tracked in email. Each is small; together they consume real capacity and introduce errors that are hard to trace.
Systems that cannot be changed safely
Software that works but that nobody is willing to touch, because there are no tests, no documentation and no way to reverse a bad release. The risk grows quietly until a required change becomes an emergency.
Tools that no longer match the process
A product chosen years ago for a different way of working, now held together with workarounds. The cost appears as staff time rather than as a line on an invoice.
Information trapped in separate places
The same customer, order or record existing in three systems with three different values, and no agreed source of truth.
06Working approach
How work moves from a description to a running system
- Step 01
Discovery
Establish the facts: current systems, data, users, constraints, and the outcome that would count as success.
- Step 02
Specification
Write down scope, interfaces, data model and acceptance criteria. Disagreements surface here, where they are cheap.
- Step 03
Implementation
Build in short increments, each reviewed and tested, with working software available to inspect throughout.
- Step 04
Verification
Automated tests, manual checks against acceptance criteria, and a rehearsal of the release procedure.
- Step 05
Handover and support
Documentation, deployment instructions, operational notes, and an agreed arrangement for what happens next.
07Technology and engineering principles
Principles applied to every engagement
Boring technology by default
Mature, widely used tools are chosen unless there is a concrete reason to do otherwise. Their failure modes are known, their documentation exists, and other engineers can pick the system up later.
Explicit over implicit
Configuration, contracts and assumptions are written down. A system whose behaviour can only be discovered by running it is unfinished.
Small, reversible changes
Work is delivered in increments that can be reviewed, deployed and reversed individually. Large simultaneous changes make failures difficult to diagnose.
Automate the repeatable
Builds, tests, migrations and deployments run the same way every time, by machine. Manual steps are documented where automation is not justified.
Design for the next reader
Code is written to be read by whoever maintains it, including the client's own team. Clarity is preferred to cleverness in every case.
Measure before optimising
Performance work follows measurement. Tuning without evidence usually moves complexity around rather than removing it.
08Security and reliability
Security treated as part of the build, not a later review
Security work that arrives after a system is complete tends to be superficial, because the expensive decisions have already been made. CHAIRBEARS HUNTON LTD addresses it while the structure is still open to change.
- Authentication and authorisation designed against the actual roles in the organisation, with permissions enforced on the server rather than hidden in the interface.
- Input treated as untrusted at every boundary, with validation close to where data enters the system.
- Secrets and credentials kept out of source control and rotated when people or providers change.
- Dependencies tracked and updated deliberately, since most practical vulnerabilities arrive through libraries rather than through original code.
- Encryption in transit as standard, and encryption at rest where the data or the applicable rules require it.
- Backups that are tested by restoring them, because an untested backup is an assumption rather than a safeguard.
- Failure planned for explicitly: timeouts, retries with limits, graceful degradation and clear error reporting.
09Business contexts served
Where this work tends to be needed
The following are contexts in which the described services apply. They are examples of typical demand rather than a claim about any particular past client.
Professional services
Case, project and time records that must reconcile with billing and reporting.
Logistics and operations
Scheduling, tracking and status data shared between field activity and office systems.
Manufacturing and supply
Production and inventory data moving between shop-floor tools and business software.
Retail and e-commerce
Catalogue, order and fulfilment data kept consistent across storefronts and back-office systems.
Education and training
Enrolment, content delivery and progress tracking with clear handling of personal data.
Non-profit and public-facing bodies
Small teams supporting services that must remain dependable within limited budgets.
Technology companies
Additional engineering capacity for platform work, integrations or long-deferred modernisation.
Regulated environments
Contexts where auditability, access control and data retention rules shape the design.
10Reasons organisations may choose us
What working with CHAIRBEARS HUNTON LTD is like
Written reasoning. Decisions arrive with the alternatives that were considered and why they were rejected, so that the client can disagree on the substance rather than on the outcome.
No lock-in by omission. Source code, infrastructure definitions and documentation belong with the client. Nothing is withheld to make future work dependent on the same supplier.
Plain communication. Progress is reported in terms of what now works, what does not yet work and what changed in the plan — without technical language used as a shield.
Scope held honestly. When a request would extend the agreed scope, that is stated at the time rather than absorbed quietly and discovered later as a delay.
Continuity after delivery. Systems are handed over in a state where they can be operated by others, and support remains available where a client prefers it.
11Frequently asked questions
Questions about IT services
- What types of engagements does CHAIRBEARS HUNTON LTD take on?
- Engagements range from a single well-defined build, such as an internal web application or an integration between two systems, through to longer arrangements where the company maintains and extends software over time. The shape of the work follows the problem rather than a fixed package: some organisations need a system designed from a blank sheet, others need an existing one stabilised, documented and made safe to change.
- How does a project usually begin?
- It begins with a written description of the current situation: what exists, what is failing or missing, who depends on it and what constraints apply. From there a short discovery phase establishes the technical facts — data sources, interfaces, hosting, access controls — before any implementation estimate is discussed. Discovery output is a written plan, not a slide deck.
- Can you work with software that was built by someone else?
- Yes. A large share of practical IT work involves inheriting a codebase without its original authors. The approach is to read the system before changing it: map its behaviour, add tests around the parts that matter, document the deployment path, and only then begin refactoring or extending. This keeps the running service intact while the ground underneath it is made stable.
- Which technologies do you use?
- Technology choices follow the requirement, the environment already in place and the skills available to the client afterwards. The company favours widely supported, well-documented tools over novel ones, because a system that nobody else can maintain is a liability regardless of how elegant it is. Where a client already has a standard stack, work continues within it.
- How is quality handled during development?
- Quality is treated as a property of the process rather than a phase at the end. Work is reviewed before it merges, automated tests cover the behaviour that carries business risk, and deployments are repeatable so that a release can be reversed. Manual testing is reserved for the things automation cannot judge, such as usability and edge-case data handling.
- What happens after a system goes live?
- Handover includes documentation of the architecture, the deployment procedure and the operational tasks the system requires. Where an ongoing maintenance arrangement is agreed, that covers monitoring, dependency and security updates, defect resolution and incremental improvements. Where a client takes the system in-house, the aim is that their team can operate it without further assistance.
- How are security and confidentiality treated?
- Access to client systems and data is limited to what the work genuinely requires, credentials are never shared informally, and secrets stay out of source control. Security considerations — input validation, authentication, authorisation, encryption in transit, dependency hygiene — are handled during design and implementation rather than retrofitted after a review.
- How can an organisation get in touch?
- By email at edwinphillips19948@gmail.com. A message describing the system, the outcome you need and any deadlines or regulatory constraints allows for a substantive first reply rather than a request for more information.
12Contact
Get in touch by email
Enquiries are handled by email. Include the systems involved, the outcome you need and any timing or compliance constraints, and the response will address the specifics rather than restate general capability.
Contact information
Written enquiries are the quickest route to a considered answer. Describe the system, the problem and the constraints you are working within, and the reply will address them directly.
- Company
- CHAIRBEARS HUNTON LTD
- edwinphillips19948@gmail.com
