IT company · Sunset
Software that keeps working after launch day.
Sunset designs, builds and maintains custom systems — applications, cloud platforms, data pipelines and the security practices around them — so technology stays an asset rather than a growing repair bill.
02 — Who we are
An engineering company, organised around the systems people actually run.
Sunset works with organisations that depend on software to operate: internal tools, customer-facing products, integrations between systems that were never designed to speak to each other. We take responsibility for the whole lifecycle — discovery, design, implementation, release and the long tail of maintenance that follows.
We prefer small, senior teams and short feedback loops over large plans written far ahead of reality. Decisions are documented, code is reviewed, infrastructure is described in version control, and nothing is handed over as a black box. What we build should be legible to the people who inherit it.
03 — Core services
Six practices, one delivery team.
- 01
Custom software development
Backends, integrations and business applications built to a specific operating model instead of forced into off-the-shelf software.
- 02
Web and mobile products
Responsive web applications and mobile products, from the interface layer down to the APIs and release pipelines behind them.
- 03
Product design
Research, information architecture, interface design and design systems that stay implementable in real code.
- 04
Cloud, DevOps and infrastructure
Infrastructure as code, environment strategy, continuous delivery, observability and cost-aware architecture.
- 05
Data and analytics
Pipelines, warehouses, modelling and reporting layers that turn scattered operational data into something people can query.
- 06
Security and IT consulting
Threat modelling, secure development practices, dependency and access review, and technical advice for teams choosing a direction.
04 — Software delivery
A process built for changing your mind cheaply.
- 01
Discovery
We map the problem, the users, the existing systems and the constraints — commercial, legal and technical — before proposing anything.
- 02
Shaping
Scope is cut into deliverable slices with a clear first release. Architecture options are compared in writing with their trade-offs.
- 03
Build
Short cycles, reviewed code, automated tests and a deployable trunk. Working software is demonstrated at the end of every cycle.
- 04
Release
Automated pipelines, staged environments, migration plans and monitoring in place before traffic arrives, not after.
- 05
Operate
Observability, incident response, dependency and security updates, and continued development against real usage.
05 — Capabilities
Technology chosen for the problem, not the trend.
Our engineers work across typed application languages, relational and document databases, container platforms and managed cloud services. The selection for any project follows from the workload, the team that will maintain it, and the operational budget available — never from novelty alone.
- Application engineering
- Typed server-side and front-end languages, REST and event-driven APIs, background processing, integration with third-party systems.
- Data storage
- Relational databases, document stores, caching layers, schema migration strategy and backup and restore procedures.
- Cloud platforms
- Managed compute, containers and serverless runtimes, networking, identity and access management, infrastructure as code.
- Delivery automation
- Continuous integration, automated test suites, reproducible builds, staged deployments and rollback paths.
- Observability
- Structured logging, metrics, tracing, alerting thresholds and runbooks written for the people on call.
- Interfaces
- Accessible component libraries, design tokens, responsive layouts and performance budgets applied from the first sprint.
06 — Industries and challenges
The same failures appear in very different industries.
Where we work
Professional services, logistics and operations, retail and e-commerce, education, manufacturing support functions, and small software companies extending a product beyond its first version.
Problems we are asked to solve
- Manual processes held together by spreadsheets and email
- Systems that cannot exchange data without human copying
- Software nobody can safely change because it has no tests
- Cloud spend growing faster than usage
- Reporting that arrives too late to act on
- Security practices that exist on paper but not in the pipeline
- Releases that require a weekend and a rollback plan
- Products that work on desktop and fail on mobile
07 — Product design
Design that survives contact with engineering.
Design at Sunset is not a decorative layer added at the end. It starts with the task a person is trying to finish and the information they need to finish it, then works outward into structure, states and edge cases.
- Interviews and workflow observation before any interface is drawn
- Information architecture and content structure agreed before visuals
- Wireframes and prototypes tested against real tasks and real data volumes
- A design system expressed as tokens and components, shared with the codebase
- Accessibility considered as a requirement: contrast, focus order, keyboard paths
08 — Security and quality
Principles we do not trade away.
- Least privilege by default
- Access to systems, data and secrets is scoped to what a role genuinely requires, and reviewed when responsibilities change.
- Secrets never live in code
- Credentials are held in managed secret storage, rotated deliberately, and kept out of repositories and build logs.
- Automated checks before human review
- Static analysis, dependency scanning and test suites run on every change so review time is spent on design, not typos.
- Data minimisation
- We collect and retain the data a feature needs, document why it is held, and design deletion paths alongside creation paths.
- Reversible releases
- Every deployment has a rollback path, and database migrations are written so they can be applied and undone safely.
- Written decisions
- Architecture and security decisions are recorded with their context and alternatives, so future teams understand the reasoning.
09 — Collaboration models
Three ways of working together.
| Model | Suits | How it runs |
|---|---|---|
| Delivery team | A defined product or platform to be built and released end to end. | Sunset provides design, engineering and delivery management, plans in cycles, and reports against an agreed scope and release plan. |
| Embedded engineers | An existing team that needs additional depth in a specific area. | Our engineers join the client's rituals, board and repositories, follow the client's standards, and contribute as team members. |
| Advisory engagement | A decision to be made: architecture, migration, tooling or security posture. | A time-boxed review with interviews, system inspection and a written recommendation covering options, risks and sequencing. |
10 — Why Sunset
Reasons companies keep working with us.
Senior attention
The people who scope the work are the people who build it. Context is not lost in a handover between sales and delivery.
Maintainability first
We optimise for the second year of a system's life: tests, documentation, boring dependencies and clear boundaries.
Full ownership transfer
Repositories, infrastructure accounts, pipelines and documentation belong to the client from day one.
Honest trade-offs
When a request is expensive, risky or unnecessary, we say so in writing and propose what we would do instead.
11 — Questions
Frequently asked questions.
- What kind of work does Sunset take on?
- Custom software development, web and mobile products, product design, cloud and DevOps work, data platforms, cybersecurity consulting, and the modernisation of software that is already in production.
- How does an engagement usually start?
- With a discovery conversation about the business problem, the systems already in place, and the constraints that matter. From there we describe a scope, a delivery approach and the decisions that need to be made first.
- Can Sunset work alongside an in-house team?
- Yes. We work as an embedded extension of an existing engineering team, or as a self-contained delivery team with its own planning and review cycle, depending on what the organisation needs.
- Who owns the code and the infrastructure?
- The client does. Source code, infrastructure definitions, pipelines and documentation are handed over in repositories and accounts the client controls.
- How is progress made visible?
- Through short delivery cycles with working software at the end of each one, a shared backlog, and written notes on the technical decisions taken and their trade-offs.
- What happens after a product is launched?
- We can continue with maintenance, monitoring, dependency and security updates, performance work and further development, or hand the system over with documentation so an internal team can run it.
12 — Contact
Tell us what needs building.
Company
Sunset
evasims1975@gmail.com
Domain
sunsethillside.com