A company shaped by maintenance.
Sunset is an IT company. We design, build and look after software systems — applications, cloud environments, data pipelines and the practices that keep them secure. Most of what we believe about engineering comes from having to live with software long after the first release.
Company overview
What Sunset does
We work with organisations whose operations depend on software that does not come out of a box: internal platforms, customer-facing products, integrations between systems bought at different times for different reasons. Engagements range from a single advisory review to a complete delivery team responsible for a product from research to production support.
The company operates remotely and communicates in English. Work is delivered through the client's own repositories and cloud accounts wherever possible, so ownership never has to be reclaimed later. Contact runs through a single address, evasims1975@gmail.com, and the site lives at sunsethillside.com.
Mission
To leave every client with systems they understand, control and can change without fear.
Software becomes expensive when nobody can safely modify it. Our aim is the opposite condition: tested code, documented decisions, reproducible infrastructure and interfaces that match how people actually work — so the next change is cheaper than the last one.
Working principles
How we conduct the work.
- 01
Understand before proposing
No architecture, estimate or tool recommendation is offered before the problem, the users and the existing constraints have been examined.
- 02
Small increments, visible results
Work is delivered in short cycles that each end with something demonstrable, so direction can change while it is still inexpensive.
- 03
Write things down
Decisions, trade-offs and rejected alternatives are recorded. Documentation is part of the deliverable, not an afterthought.
- 04
Say the difficult thing early
Risks, unrealistic scope and technical debt are raised as soon as they are visible, in writing, with an alternative proposal.
- 05
Automate the repeatable
Builds, tests, deployments and checks belong in pipelines. Human attention is reserved for judgement, not for ceremony.
- 06
Leave the system better documented
Every engagement ends with the client able to run, deploy and extend what was built without depending on us.
Approach to technology
Boring where it counts, considered where it matters.
We favour mature, well-documented technology for the parts of a system that must simply keep running, and reserve newer tooling for places where it answers a specific need. Every significant choice is written up with its alternatives, its operational cost and the exit path if it turns out to be wrong.
That includes the unglamorous parts: schema migrations, backup restoration drills, dependency upgrade cadence, environment parity and the question of who gets paged when something breaks at night.
Collaboration philosophy
One team, one backlog, one version of the truth.
We work as part of the client's team rather than across a contractual wall. That means shared planning, shared visibility of progress, and direct access between the people asking for the work and the people doing it.
- Direct communication
- Engineers and designers speak with the people who use the software, not only with a project manager relaying requirements.
- Shared planning
- Priorities are agreed openly, in one backlog, with the cost and sequencing of each item made explicit.
- Regular demonstration
- Each cycle ends with working software and a written note of what changed, what did not, and why.
- No lock-in
- Access, credentials, code and documentation stay with the client throughout, so the relationship continues by choice.
Quality and security mindset
Quality is a process, not a final inspection.
Testing, review and security thinking happen while code is being written. A change reaches production through automated checks, peer review and a deployment path that can be reversed. Security is treated as a property of the development process — access scoping, secret handling, dependency hygiene and data minimisation — rather than a scan performed at the end.
- Automated tests as a condition of merge
- Peer review on every change
- Dependency and vulnerability scanning in the pipeline
- Least-privilege access to systems and data
- Secrets held in managed storage, never in repositories
- Reversible deployments and tested migrations
- Structured logging, metrics and alert thresholds
- Accessibility and performance checks before release
Contact information
Reach the company directly.
- Company
- Sunset
- evasims1975@gmail.com
- Domain
- sunsethillside.com