01
Application engineering
Server-side services, browser clients and background workers written in maintainable, typed codebases with documented boundaries.
Software engineering studio
KEY & CO
HOME LTD
We design, build and maintain software systems — custom applications, web platforms, cloud infrastructure and the integrations that hold them together.
Custom software · Web applications · Cloud & infrastructure · Systems integration · Technical support
02The company
An engineering practice organised around durable software.
KEY & CO HOME LTD works with organisations that depend on software to run daily operations. Our attention is on systems that must remain understandable, changeable and reliable long after the first release — the part of software work that is rarely visible in a demonstration but determines what the system costs to own.
Engagements begin with a written understanding of the problem and end with software that is documented, tested and operable by the people responsible for it. We describe what we do and how we do it; we avoid claims about outcomes that depend on circumstances outside the engineering work itself.
03Core technology capabilities
Six practices that carry across every engagement.
02
Data modelling
Relational schemas, migrations and access rules designed around the way the business actually reads and writes information.
03
Cloud operations
Reproducible environments, deployment pipelines, log aggregation and metrics so that releases are routine rather than eventful.
04
Interface design
Accessible, responsive interfaces built from a shared component system, tested against real content rather than idealised samples.
05
Interoperability
HTTP and event-driven interfaces that let internal systems and third-party platforms exchange data predictably.
06
Operational support
Monitoring, dependency upkeep and change management for software that has already reached production.
04Custom software development
Software shaped to the process, not the other way round.
Bespoke development is appropriate when an off-the-shelf product forces a business to distort a process that is genuinely its own. We model that process explicitly — its states, rules and exceptions — and build against the model rather than against a screen mock-up.
- Domain modelling and data design before implementation
- Typed, reviewed codebases with automated test coverage
- Migration paths for existing data and running processes
- Handover documentation written for the maintaining team
05Web application engineering
Interfaces that stay fast and legible as the product grows.
Web applications are built on a shared component system, typed data contracts and a rendering strategy chosen for the content — server rendering where discovery and first paint matter, client interactivity where the workflow demands it. Accessibility, keyboard operation and responsive behaviour are treated as acceptance criteria rather than later refinements.
Front-end
Component libraries, design tokens, state management, form and validation behaviour, performance budgets.
Back-end
Application services, authentication and authorisation, persistence, background processing and scheduled work.
06Cloud and infrastructure
Environments that can be rebuilt from source, not from memory.
Infrastructure is described in code and versioned alongside the application, so that a staging environment and a production environment differ only in configuration. Deployments run through automated pipelines with reversible steps.
Provisioning
Declarative infrastructure definitions and repeatable environment creation.
Delivery
Build, test and deploy pipelines with controlled promotion between environments.
Observability
Structured logs, metrics and alerting tied to the behaviour that matters.
Continuity
Backup, restore and recovery procedures that are tested, not assumed.
07Systems integration
Making separate systems agree on the same facts.
Most operational friction comes from systems that hold overlapping copies of the same information and disagree about it. Integration work begins by naming the authoritative source for each record, then defining how changes travel between systems, how conflicts are resolved, and how failures are retried without duplicating effects.
Interfaces are documented with explicit schemas and versioning, so a change on one side does not silently break the other. Where a third-party platform is involved, we work within its published API and rate limits rather than around them.
08Product discovery and planning
The cheapest place to change a system is a document.
Discovery establishes what is being built and why, which constraints are fixed, which systems already exist, and what the first useful release contains. It produces a written scope, a data and integration map, a technical approach with the alternatives considered, and a delivery sequence ordered by risk.
Where the requirement is uncertain, we prefer a small prototype that answers the specific question over a longer specification that assumes an answer.
09Development workflow
A sequence we can describe before the work starts.
Phase 01
Framing
We write down the problem, the constraints and the definition of done before any code is committed. Ambiguity is resolved on paper, where it is cheap.
Phase 02
Architecture
We choose the smallest architecture that satisfies the requirement, and record the reasoning so future decisions can be traced back to it.
Phase 03
Increments
Work is delivered in short, reviewable increments. Each one is demonstrable, deployable and covered by automated checks.
Phase 04
Hardening
Before release we exercise failure paths, load characteristics and access rules, then document operating procedures.
Phase 05
Operation
After release we watch the system in production, close feedback loops and keep dependencies current.
10Quality assurance and testing
Tests exist so that change stays affordable.
Automated checks run on every change: unit tests around business rules, integration tests across service and database boundaries, and end-to-end tests for the workflows a user actually completes. The suite runs in the pipeline, and a failing suite blocks the release.
Manual testing is reserved for what automation reads poorly — exploratory use, content and layout across viewports, keyboard and screen-reader operation, and the behaviour of the system when a dependency is slow or unavailable.
- Static analysis
- Type checking, linting and dependency auditing on each commit.
- Review
- Every change is read by another engineer before it is merged.
- Regression
- Defects are reproduced with a test before they are fixed.
- Release checks
- Smoke verification against the deployed environment.
11Security-conscious engineering
Security decisions belong in the design, not the checklist.
We treat authentication, authorisation and data handling as parts of the architecture. Access rules are enforced on the server, secrets are kept out of source control, inputs are validated at trust boundaries, and dependencies are monitored for published vulnerabilities and updated deliberately.
Personal data is collected only where a feature requires it, retained according to an agreed policy, and transported over encrypted connections. We describe the measures we apply; we do not present them as a guarantee against every possible threat.
12Maintenance and technical support
Most of a system's life happens after the launch.
Support arrangements are written down before they are needed: what is covered, how issues are reported and triaged, and what a reasonable response looks like for each severity. Routine upkeep — dependency and platform updates, certificate renewal, backup verification, capacity review — is scheduled rather than improvised.
Corrective
Diagnosing and resolving defects reported in production.
Preventive
Dependency updates, patching and technical-debt reduction.
Adaptive
Adjusting the system as platforms, regulations or volumes change.
Evolutionary
Planned enhancements delivered on the same review cadence.
13Illustrative project scenarios
Examples of the kind of work described above.
The scenarios below are written illustrations of typical engineering problems. They are not descriptions of completed client projects and do not represent any specific customer.
Illustrative example
Field operations application
A distributed team records site visits on mobile devices with intermittent connectivity. The application queues entries locally, reconciles them on reconnection, and exposes a supervisor view built on the same data model.
Illustrative example
Order and inventory integration
An online storefront, a warehouse system and an accounting package exchange records through a documented integration layer with idempotent message handling and a replayable audit trail.
Illustrative example
Internal reporting platform
Operational data is consolidated into a reporting schema, refreshed on a schedule, and presented through a permissioned web interface so that departments read consistent figures.
Illustrative example
Legacy service modernisation
A long-running service is placed behind a stable interface, incrementally replaced module by module, and migrated to a reproducible deployment pipeline without a single high-risk cutover.
14Collaboration principles
How we work with the people we work for.
Written decisions
Architectural choices, trade-offs and open questions are written down so that any participant can review them without attending a meeting.
Predictable cadence
Progress is shown on a regular rhythm with working software, not status percentages.
One source of truth
Requirements, tickets and technical notes live in one agreed place, kept current as the work changes.
Direct access to engineers
Technical questions are answered by the people writing the code, without a translation layer.
15Frequently asked questions
Questions we are asked before an engagement begins.
- What kinds of software do you build?
- Custom business applications, web platforms, internal tools, integration layers and supporting cloud infrastructure. Work ranges from a single well-scoped service to a complete application delivered and then maintained over time.
- How is a new engagement scoped?
- It begins with a discovery step in which the objective, constraints, existing systems and success criteria are documented. That produces a written scope, a technical approach and a delivery sequence before implementation starts.
- Which technologies are used?
- Technology is selected per project against the requirement, the operating environment and the skills available to maintain it afterwards. Preference is given to widely supported, well-documented tooling rather than novel choices.
- Can you work with an existing codebase?
- Yes. Work on existing systems starts with a review of the code, data model, deployment process and dependencies, followed by incremental change rather than an immediate rewrite.
- What happens after a release?
- Maintenance covers monitoring, dependency and security updates, bug fixes, and planned enhancements. The scope and response expectations are agreed in advance and written down.
- How is progress communicated?
- Through a regular written update, a shared task board and demonstrations of working software. Technical questions are answered directly by the engineers involved.
16Company and contact information
KEY & CO HOME LTD
- lularay1997@gmail.com
- Website
- keyandcohome.com
- Correspondence language
- English
Written enquiries are read by an engineer. A message that describes the objective, the systems already in place and any fixed constraints allows a more specific reply.