DEW-IT

A practice built
around craft
and continuity.

DEW-IT is an IT company that designs, builds and maintains software systems. We are deliberately structured so that the people who understand a system are the people who remain available to it.

01 / Overview

Company overview

We take on custom software development, web application engineering, cloud infrastructure, system integration, modernisation, quality assurance and technical support. Engagements range from a single well-defined service to long-running responsibility for a platform.

Our work is documentation-heavy by intention. Architectural decisions, interfaces and operational procedures are written down as they are made, so that the organisations we work with own their systems rather than depending on recollection. All communication, documentation and delivery are handled in English.

02 / Mission

Mission

To build software that organisations can rely on and understand — systems that behave predictably, can be changed safely, and remain maintainable long after the first release. We measure our work by how well it serves the people who use and operate it every day.

03 / Vision

Vision

A software landscape where reliability is ordinary: where releases are routine, security is designed in from the beginning, and technical decisions are recorded clearly enough that any competent engineer can pick up the work and continue it.

04 / Principles

Working principles

  1. 01

    Clarity before code

    A problem that cannot be described plainly is not ready to be implemented. We resolve ambiguity first.

  2. 02

    Small, reversible steps

    Change arrives in increments that can be reviewed, deployed and, if necessary, withdrawn.

  3. 03

    Say what is true

    Estimates, risks and limitations are communicated as they are, including when the answer is inconvenient.

  4. 04

    Own the outcome

    Responsibility does not end at handover of a feature; it ends when the system runs as intended.

  5. 05

    Prefer the boring option

    Proven tools with good documentation beat novelty in systems that must run for years.

  6. 06

    Leave it explainable

    Anyone joining the project later should be able to reconstruct why it is built the way it is.

05 / Technology

Approach to technology

We choose technology for the shape of the problem and the capabilities of the team that will keep the system running. A stack that no one in the organisation can operate is a liability regardless of its merits.

Where an existing platform is sound, we extend it. Where it genuinely blocks progress, we plan a migration in stages that keeps the business running throughout rather than proposing a rewrite as a first response.

Portability matters: infrastructure described as code, data in open formats, and interfaces defined independently of any single vendor.

Hand-drawn architecture diagram on a whiteboard showing services, queues and storage components
Fig. 01 — Design discussions are recorded before implementation begins.
06 / Quality

Quality philosophy

Defined before built

Acceptance criteria are agreed before implementation, so quality is measured against a shared expectation rather than an impression.

Tested where it counts

Automated tests concentrate on business rules, boundaries and failure modes instead of chasing a coverage figure.

Reviewed by a second engineer

Every change is read by someone other than its author before it reaches a production environment.

07 / Security

A security mindset means assuming the system will be probed.

We treat authentication, authorisation, secret management and data handling as first-class design concerns. Inputs are validated at boundaries, permissions are explicit, and sensitive values never live in source control.

Dependencies are kept current and reviewed for known issues. Where a system processes personal data, we minimise what is collected, document where it is stored, and build deletion paths at the same time as the features that create the data.

Engineers discussing code on a shared screen during a working session
Fig. 02 — Collaboration in practice: shared screens, short cycles, written outcomes.

08 / Collaboration

Collaboration process

  1. 01

    Shared backlog

    Work is visible in one place, prioritised together, and revised as understanding improves.

  2. 02

    Regular demonstrations

    Progress is shown in a running environment on a predictable rhythm.

  3. 03

    Written decisions

    Anything that affects architecture or data is recorded with its reasoning.

  4. 04

    Direct channels

    Questions go straight to the engineer who can answer them.

  5. 05

    Structured handover

    Documentation, runbooks and access are transferred as part of delivery, not afterwards.

09 / Contact

Contact details

Questions about how we work, or about a system you are responsible for, are welcome by email.

Company
DEW-IT
Email
ellencarpenter19960@gmail.com
Website
dewitworks.com