About Us
An engineering
practice, written
down.
Lit clothing is a technology company. We build software systems for business operations and stay with them afterwards. This page describes how the work is organised: what we commit to, how technical decisions are made, and what clients can expect from the collaboration.
Who we are
The company works as a small, senior engineering group rather than a layered agency. The people who scope an engagement are the people who write the code and later maintain it, which removes the gap between what is promised and what is technically possible. Work is accepted only where the required expertise is actually present in the team; where it is not, that is said directly.
Most engagements concern systems that already exist in some form — a manual process, an ageing application, a set of tools that do not exchange data reliably. That means the first task is usually understanding an environment we did not design, and documenting it well enough that decisions can be defended later.
Mission
To build business software that the client organisation can understand, operate and change without depending on the people who wrote it. Every project should leave behind working software, readable code, reproducible infrastructure and documentation sufficient for another competent team to take over.
Vision
A technology practice where architecture decisions are recorded rather than remembered, where security and maintainability are part of the first design pass instead of a later project, and where the cost of changing a system stays roughly constant over its lifetime rather than growing until replacement becomes the only option.
How we operate
- 01
Scope before code
Nothing is built from a conversation alone. Requirements, constraints and acceptance criteria are written and confirmed first.
- 02
One decision-maker per side
A named contact on each side can approve scope changes, which prevents work stalling between departments.
- 03
Say no with reasoning
Requests that damage maintainability or security are declined in writing, with an explanation and an alternative.
- 04
Estimate ranges, not points
Estimates are given as ranges with the assumptions behind them, and revised in writing when assumptions change.
- 05
Client owns everything
Repositories, infrastructure accounts, domains and credentials are held by the client from the first day.
- 06
Finish before starting
Iterations end with deployable, tested work rather than a partially integrated branch carried into the next cycle.
Approach to technology
Technology choices are made against the constraints of the project, not against personal preference. The relevant questions are which options the client can hire for, which have a maintenance record long enough to trust, and which fit the operational environment already in place. Where an existing stack is serviceable, it is kept and improved rather than replaced.
When something genuinely new is required, it is introduced in a contained part of the system first, with an exit route documented. Each significant decision — storage engine, messaging approach, hosting model, framework — is captured in a short record stating the context, the options, the choice and the consequences.
Working with clients
Clients are treated as participants in the engineering process, not recipients of a finished object. That means access to the backlog, visibility of the branch and build status, and demonstrations against a running environment rather than screenshots.
Communication is deliberately asynchronous by default: written updates, recorded decisions and a shared tracker, with scheduled calls for decisions that need discussion. This keeps a searchable record and reduces dependence on who happened to be in a particular meeting.
Quality standards
Definition of done
A change is done when it is reviewed, covered by tests appropriate to its risk, documented, and running in a staging environment.
Review discipline
Every change is read by a second engineer, who checks behaviour, data handling, error paths and readability, not only correctness.
Automated gates
Linting, type checks, tests and dependency scans run on every change; a failing pipeline blocks the merge.
Regression protection
Each fixed defect gains a test that reproduces the original failure, so the same problem cannot silently return.
Accessibility checks
Interfaces are checked for keyboard operation, contrast, focus order and semantic structure as part of the build, not afterwards.
Security mindset
Systems are designed on the assumption that credentials leak, dependencies contain flaws, inputs are hostile and people make mistakes under time pressure. Access is scoped to the narrowest useful level, sensitive fields are identified during data modelling, and privileged actions are logged in a form that can be reviewed later.
Security is also an operational habit: dependency updates on a schedule rather than after an incident, secrets rotated through a defined procedure, restores tested rather than assumed, and an agreed contact path for reporting a suspected problem. No system is treated as immune; the objective is to reduce exposure and shorten reaction time.
How projects are organised
Structure
One accountable engineer per engagement, supported by reviewers with the relevant specialism. Responsibilities are written into the engagement notes.
Rhythm
Short iterations, a shared backlog, an end-of-iteration summary, and a demonstration on a deployed build rather than a local machine.
Records
Architecture decision records, integration contracts, runbooks and environment documentation live in the client's repository from day one.
Contact information
- Company
- Lit clothing
- meijerkevin06@gmail.com
- Website
- litwearco.com