Services
Engineering services, described in full.
Six services covering the life of a software system: from the first written scope through to the maintenance of a product already running in production.
01Service
Custom software development
Purpose
To replace a process that no packaged product models correctly with an application built around the organisation's own rules, states and exceptions.
Typical scope
- Domain and data modelling, including migration of existing records
- Application services, business rules and background processing
- Administrative and operational interfaces
- Automated test suites and deployment configuration
Deliverables
- A running application in the agreed environments
- Source code and infrastructure definitions in the client's repository
- Architecture notes recording decisions and alternatives considered
- Operating and handover documentation
Collaboration process
Discovery produces a written scope and a delivery sequence ordered by risk. Implementation proceeds in short increments, each reviewed, tested and demonstrable. A hardening step exercises failure paths and access rules before the first production release.
02Service
Web application development
Purpose
To deliver browser-based products and internal tools that remain fast, accessible and legible as features accumulate.
Typical scope
- Component system, design tokens and responsive layout rules
- Server-rendered or client-rendered strategy chosen per view
- Authentication, authorisation and session handling
- Forms, validation, state management and error handling
Deliverables
- A deployed web application with documented environments
- A reusable component library with usage notes
- Accessibility and performance acceptance criteria met at release
- End-to-end tests covering the primary user workflows
Collaboration process
Interface work begins from real content and real data shapes rather than idealised samples. Each increment is reviewed on desktop, tablet and mobile viewports, with keyboard operation checked before it is accepted.
03Service
Cloud architecture and infrastructure
Purpose
To make environments reproducible and releases routine, so that deploying a change is a low-risk, frequent operation.
Typical scope
- Infrastructure described in code and versioned with the application
- Build, test and deployment pipelines with controlled promotion
- Log aggregation, metrics and alerting
- Backup, restore and recovery procedures
Deliverables
- Provisioned environments created from source definitions
- An automated pipeline from commit to deployment
- Dashboards and alerts tied to meaningful system behaviour
- A written runbook for routine and exceptional operations
Collaboration process
We begin by describing the current deployment path, including the manual steps. Automation replaces those steps incrementally, with a rollback route available at each stage, so migration does not depend on a single cutover.
04Service
API development and systems integration
Purpose
To let separate systems exchange information reliably, with an agreed authoritative source for every record.
Typical scope
- Interface design with explicit schemas, versioning and error semantics
- Synchronous APIs and event or message-driven exchanges
- Idempotent handling, retries and reconciliation of conflicting records
- Integration with third-party platforms within their published APIs and limits
Deliverables
- Documented interfaces with machine-readable schemas
- An integration layer deployed alongside monitoring
- A replayable audit trail of exchanged messages
- Contract tests protecting both sides of each interface
Collaboration process
Integration work starts with a data map: which system owns which record, what triggers a change, and how a failed exchange is detected and repaired. Implementation follows only once that map is agreed in writing.
05Service
Quality assurance
Purpose
To keep change affordable by verifying behaviour automatically and reserving human attention for what automation reads poorly.
Typical scope
- Unit, integration and end-to-end test suites executed in the pipeline
- Static analysis: type checking, linting and dependency auditing
- Exploratory, accessibility and cross-viewport manual testing
- Regression tests written from reproduced defects
Deliverables
- A test suite that runs on every change and blocks a failing release
- A documented test strategy describing what is covered and what is not
- Defect reports with reproduction steps and severity
- Release verification checks against the deployed environment
Collaboration process
Acceptance criteria are agreed before implementation, so testing verifies a stated expectation rather than an inferred one. Coverage is directed at business rules and integration boundaries rather than pursued as a number.
06Service
Technical maintenance and support
Purpose
To keep a system in production healthy, current and supportable after the initial delivery.
Typical scope
- Issue intake, triage and corrective fixes
- Dependency, platform and security updates
- Certificate renewal, backup verification and capacity review
- Planned enhancements delivered on the same review cadence as new work
Deliverables
- A written support arrangement stating coverage and severity handling
- A maintained changelog of applied updates and fixes
- Periodic reports on system health and outstanding technical risk
- Updated documentation as the system changes
Collaboration process
Reported issues are acknowledged, reproduced, classified by severity and tracked in the shared board. Routine upkeep is scheduled in advance so that updates do not accumulate into a single disruptive change.
Service questions
Frequently asked questions about these services.
- Can a single service be engaged on its own?
- Yes. Each service listed on this page can be delivered independently — for example an integration layer for existing systems, or maintenance of an application built elsewhere.
- How is scope agreed before work starts?
- Through a discovery step that documents the objective, the constraints, the systems already in place and the acceptance criteria. That written scope, together with a delivery sequence, precedes implementation.
- Do you take over software built by another team?
- Yes. That begins with a review of the code, data model, deployment process and dependencies, followed by a written summary of risks and a proposed sequence of incremental changes.
- How are technologies selected?
- Against the requirement, the environment the system will run in, and the ability of the maintaining team to support it afterwards. Widely used and well-documented tooling is preferred over novel choices.
- What does the handover include?
- Source code and infrastructure definitions in the client's own repository, architecture notes, operating documentation and the automated test suite. Nothing required to run the system is retained by us.
- How is ongoing support arranged?
- Coverage, issue reporting, severity classification and expected handling are written down before support begins, so both sides work from the same agreement.
07Contact information
Enquiries are answered by email, in English.
- KEY & CO HOME LTD
- Email: lularay1997@gmail.com — Website: keyandcohome.com