Logistics and distribution
Order intake, stock movement and carrier integrations, where records must reconcile across several systems and time zones.
Lit clothing — Technology Company
Software engineering
Cloud architecture
System integration
Data platforms
Security engineering
Systems that keep
working after
launch day.
Lit clothing designs, builds and maintains software for business operations: custom applications, cloud infrastructure, APIs between systems that were never meant to talk to each other, and the data pipelines behind reporting. Every engagement is written down before it is built — architecture, deliverables, review process and handover.
02Overview
What the company does
Lit clothing works with organisations whose operations depend on software that has to be correct, available and understandable to the people maintaining it. Typical work starts with a system that has outgrown its original design: a manual process that needs an application, a monolith that needs to be split, an integration that breaks every time a supplier changes a field, or a reporting stack nobody can explain.
Engineering is organised around small, reviewable changes and environments that mirror production closely enough to be trusted. Decisions about frameworks, hosting and data structures are documented with their trade-offs, so the reasoning survives staff changes on either side. The objective is a system the client can operate, audit and extend without depending on a single supplier.
- Discovery first
- Systems, data flows and constraints are documented before code.
- Written architecture
- Every structural decision is recorded with its alternatives.
- Reviewed changes
- Nothing reaches the main branch without a second engineer.
- Operable handover
- Runbooks, diagrams and access procedures ship with the system.
03Starting points
Problems this work addresses
- 01
Processes that live in spreadsheets
Operational data spread across files and inboxes, with no history, no validation and no reliable single version. Replacement means modelling the process accurately first, then building an application around the real sequence of work.
- 02
Systems that cannot exchange data
An ERP, a CRM, a warehouse tool and a billing platform that each hold part of the truth. Integration work defines the record of reference for each entity, then builds the transfer, retry and reconciliation logic around it.
- 03
Infrastructure nobody can reproduce
Servers configured by hand years ago, where a rebuild is a research project. Infrastructure as code makes environments reproducible and reviewable, and turns recovery into a documented procedure.
- 04
Releases that are risky
Deployments that require downtime, manual steps and a specific person. Automated pipelines, migrations that run forward safely and staged rollouts make releases routine.
- 05
Reporting nobody trusts
Numbers that differ between dashboards because each query defines the metric differently. Data work centralises definitions, documents lineage and makes discrepancies traceable.
- 06
Software without an owner
Applications still running, but with unpatched dependencies and no one who knows the deployment path. Takeover starts with an audit, a dependency plan and reconstructed documentation.
04Capabilities
Core technical ground
Application engineering
Typed backends and component-based frontends, built around explicit domain models rather than framework defaults.
Cloud architecture
Environment separation, network boundaries, managed data services and cost-aware sizing, defined as code.
Interfaces and contracts
REST and event-driven interfaces with versioning rules, schema validation and documented failure behaviour.
Data engineering
Ingestion, transformation and storage layers with tested transformations and traceable lineage.
Reliability practice
Health checks, structured logging, metrics, alerting thresholds and rehearsed recovery procedures.
Security engineering
Threat modelling, least-privilege access, dependency scanning and encrypted data handling as part of delivery.
05Services
Where the work is concentrated
- Custom software developmentApplications built for one organisation's process
- Web application developmentBrowser-based systems, accessible and responsive
- Cloud architectureEnvironments, networking and managed services as code
- API and integration workContracts, transfer logic, retries, reconciliation
- Technology consultingArchitecture review, technical due diligence, planning
- UI and UX engineeringInterface systems built from a shared component library
- Data solutionsPipelines, warehouses and documented metric definitions
- Quality assuranceAutomated suites, exploratory testing, release checks
- Security engineeringThreat models, access control, dependency management
- Infrastructure modernisationMigration of legacy deployments to reproducible setups
- Maintenance and supportMonitoring, patching, incident response, improvements
Full descriptions are on the Services page.
06Method
How software is delivered
Stage 01
Discovery
Current systems, data flows, constraints and users are documented. Output: a written problem statement and a system map.
Stage 02
Architecture
Structure, data model, hosting shape and integration points are decided and recorded with alternatives considered.
Stage 03
Delivery sequence
Work is ordered so the riskiest assumption is tested first, and each iteration ends in a deployable build.
Stage 04
Implementation
Small changes, reviewed by a second engineer, merged behind automated checks and tested in a staging environment.
Stage 05
Verification
Automated suites plus exploratory testing against the documented behaviour, with defects triaged by impact.
Stage 06
Release and handover
Staged rollout, monitoring in place, runbooks and diagrams written, credentials transferred to client control.
07Principles
Engineering rules we apply
Explicit over implicit. Behaviour that matters is written in code and tests, not left to convention or to a comment. Configuration is declared, defaults are visible, and hidden state is treated as a defect.
Boring technology by default. Widely used, well-documented tools are preferred, because they are easier to hire for, patch and debug. New technology is introduced only where it removes a concrete constraint.
Small changes, frequently. Large batches hide defects and complicate rollback. Work is split so that each merged change is reviewable in a sitting and reversible in minutes.
Data model before interface. Screens change constantly; the way information is stored and related does not. Entities, relations and constraints are agreed before layout work begins.
Failure paths are designed. Timeouts, retries, duplicate messages and partial writes are handled deliberately, and the resulting behaviour is documented for operators.
Documentation is part of the deliverable. A feature is finished when another engineer can run it, change it and deploy it using the written material alone.
08Environments
Business contexts we work in
Professional services
Project, resource and billing workflows that need accurate time and cost data and defensible audit history.
Manufacturing operations
Production planning and quality records connected to machine data and existing ERP installations.
Retail and e-commerce
Catalogue, pricing and fulfilment data synchronised between storefronts, warehouses and finance systems.
Technology products
Product teams needing additional engineering capacity, platform work or an independent architecture review.
Regulated back-office work
Processes where access control, retention rules and traceability of changes are part of the requirements.
09Infrastructure
Environments that can be rebuilt
Infrastructure is defined in version-controlled templates, so development, staging and production differ only in scale and access, not in shape. A new environment is created by running the same definitions rather than by repeating manual steps, which makes recovery and onboarding predictable.
Deployment pipelines build once and promote the same artefact through environments. Database changes run as forward migrations with a tested path. Secrets are held in a managed store with scoped access, and every privileged action leaves an audit record the client can read.
10Security and reliability
Controls built into delivery
Security work is part of design rather than a review at the end. Each system is modelled for the data it holds, the people who need it and the ways it could be misused. That analysis produces concrete requirements, which are then implemented and tested with the rest of the feature set.
- Role and permission models defined against real job functions, not generic admin tiers.
- Secrets, keys and tokens stored in managed vaults with rotation procedures written down.
- Dependency and container scanning wired into the pipeline, with an agreed patch cadence.
- Encryption in transit and at rest, with retention and deletion rules applied per data type.
- Backups tested by restoring them, not by checking that the job reported success.
- Incident procedure agreed in advance: who is contacted, what is logged, how it is reviewed.
11Collaboration
How we work with your team
Each engagement has one named contact on each side who can make decisions about scope. Work is planned in short iterations with a shared backlog, and the same tracker is visible to the client throughout. Written summaries at the end of each iteration describe what changed, what was postponed and what needs a decision.
Technical discussion happens in the open: architecture proposals are circulated as short documents, and objections are recorded together with the outcome. When a request would compromise maintainability, security or timeline, that is stated with the reasoning and an alternative rather than absorbed silently.
| Model | Suited to |
|---|---|
| Full delivery | No internal engineering team for this system |
| Joint team | Internal team with capacity or skill gaps |
| Subsystem stream | A defined component alongside in-house work |
| Advisory review | Architecture, security or due diligence input |
| Maintenance only | A running system that needs stewardship |
12Quality assurance
What testing covers
Unit and contract tests
Domain rules and interface contracts are tested close to the code, so a breaking change fails in the pipeline rather than in production.
Integration tests
Realistic paths through the system are exercised against test instances of the databases and third-party services involved.
End-to-end checks
Critical user journeys run automatically against a deployed build in an environment configured like production.
Exploratory testing
Manual sessions against the written acceptance criteria, targeted at edge cases automation is unlikely to reach.
Non-functional review
Load behaviour, response times under expected concurrency, accessibility checks and browser or device coverage.
Defect handling
Issues are reproduced, classified by impact, fixed with a regression test, and reviewed for the cause rather than only the symptom.
13Long-term support
After the first release
Software that is used keeps changing: dependencies age, volumes grow, regulations shift and processes are adjusted. Support agreements define what is monitored, how incidents are reported and reviewed, how often dependencies are updated and how planned improvements are prioritised against operational work.
Periodic technical reviews look at error rates, slow queries, cost drivers, unused components and accumulated shortcuts. Findings are written as a prioritised list with effort estimates, so the client decides what is worth addressing next.
We write down the architecture, the trade-offs and the recovery procedure — because the people maintaining a system are rarely the people who built it.
15FAQ
Frequently asked questions
01What kind of work does Lit clothing take on?
Engagements usually involve building a custom application, replacing or extending an existing system, designing cloud infrastructure, connecting separate tools through APIs, or maintaining software that is already running in production. Work is defined as a written scope with named deliverables before development begins.
02How is a project scoped before development starts?
A discovery stage documents the current systems, the data that moves between them, the constraints that cannot change, and the outcome the business needs. The result is an architecture outline, a delivery sequence, an integration list and the risks that require attention. Scope is revised in writing when circumstances change.
03Who owns the code and the infrastructure configuration?
Source code, infrastructure definitions, pipeline configuration and technical documentation belong to the client organisation and are stored in repositories the client controls. Nothing required to run or rebuild the system is kept exclusively on our side.
04How is progress communicated during delivery?
Work is tracked in a shared issue tracker, changes are reviewed through pull requests, and each iteration ends with a working build that can be inspected in a test environment. Written summaries accompany each iteration so that non-technical stakeholders can follow the state of the project.
05Can Lit clothing work with an existing in-house engineering team?
Yes. Collaboration models include joint teams sharing one backlog, an independent stream working on a specific subsystem, or a review and advisory role for architecture and security decisions. Branching rules, review policy and release responsibility are agreed before the first commit.
06What happens after a system goes live?
Support covers monitoring, dependency and security updates, incident response, performance review and planned improvements. Runbooks, architecture notes and access procedures are written during delivery so the system can also be operated by another team if required.
16Contact
Company contact information
Written enquiries are the fastest route to a useful answer. A short description of the system, the problem and the constraints allows a technical reply instead of a request for more information.
- Company
- Lit clothing
- meijerkevin06@gmail.com
- Website
- litwearco.com
Useful to include
- The business process the system supports
- Existing platforms, languages and hosting in use
- Integrations that must remain in place
- Known constraints: compliance, data residency, timelines
- Who will be involved in technical decisions