PENCILTIP LTD — Est. drawing board
Software drawnto specificationbefore it is built.
We are a software engineering company. We design, build, and maintain custom applications, web platforms, integrations, and the infrastructure that carries them. Every project starts with an honest sketch of the problem and ends with software a team other than ours can continue to run.
- Discipline
- Engineering-led
- Focus
- Maintainability
- Contact
- By email
02 / Company overview
A studio organised around clear thinking and legible code.
PENCILTIP LTD works with organisations that need software built or rebuilt with care: internal tools that have outgrown spreadsheets, customer-facing platforms that need a stable foundation, and existing systems that need to talk to one another reliably.
Our working method is deliberately unglamorous. We read the existing code and data before proposing changes. We keep the number of moving parts small. We prefer boring, well-understood technology where it does the job, and we document the places where something less common was genuinely warranted.
We describe capabilities we can deliver rather than claims we cannot evidence. Scope, constraints, and open questions are stated plainly at the start of an engagement so that expectations on both sides are grounded in the same document.
03 / Core technology capabilities
Core capabilities
Six areas of practice that combine differently depending on the problem in front of us.
01
Application engineering
Server-side services, background processing, scheduled jobs, and domain logic written to be read, tested, and changed by other engineers.
02
Interface development
Component-driven front ends with predictable state handling, accessible markup, and layouts that hold together across screen sizes.
03
Data modelling
Relational schema design, migration strategy, indexing, and query work aimed at keeping data consistent as a product grows.
04
Interfaces & APIs
HTTP and event-based interfaces with versioning, documented contracts, and validation applied at the boundary rather than deep inside the code.
05
Infrastructure
Declarative environments, container images, deployment pipelines, and observability so that releases are repeatable rather than manual.
06
Automation
Replacing repeated manual steps — data transfers, reconciliations, notifications — with scheduled or event-driven processes.
04 / Custom software development
Systems shaped to the work they support
Custom development is appropriate when off-the-shelf products force a business to distort its own process. We build applications around the process that already works, automating the parts that are mechanical and leaving judgement where it belongs — with people.
Typical work includes operational back-office systems, internal dashboards, scheduling and inventory tools, document and workflow handling, and services that sit behind an existing product. Business rules are expressed in one place, covered by tests, and named the way the people who use them speak.
Deliverables include source code in your repository, a data model, deployment configuration, automated tests, and written notes on how the system is meant to be operated and extended.
05 / Web application development
Web applications that stay usable under load and over time
Interface
Responsive layouts built from a shared component library, semantic HTML, keyboard operability, and contrast levels chosen for readability rather than fashion. Behaviour is verified at mobile, tablet, and desktop widths.
Rendering & delivery
Server-rendered or prerendered HTML where content should be visible to crawlers and slow connections, with client-side interactivity layered on top rather than required for the page to make sense.
State & data
Explicit data-fetching boundaries, cache invalidation rules that are written down, and error and empty states designed as part of the feature instead of added afterwards.
Performance
Sized and lazily loaded media, careful bundle composition, and attention to layout stability, so that pages settle quickly instead of shifting while they load.
06 / Cloud infrastructure & DevOps
Environments that can be rebuilt from a repository
Infrastructure is described as code so that staging and production differ by configuration rather than by history. Container images are built once and promoted through environments, and deployments run from a pipeline instead of a laptop.
We set up continuous integration that runs linting, type checks, and tests on every change; automated deployment with a clear rollback path; secrets handled through a managed store; and logging, metrics, and alerting configured before a system is relied upon rather than after an incident.
Where an existing platform is already in place, we work within it and improve it incrementally rather than proposing a rewrite by default.
07 / Systems integration & workflow automation
Making separate systems behave like one
Most organisations do not lack software; they lack connections between the software they already run. Integration work replaces manual re-entry, exported spreadsheets, and copy-paste reconciliation with defined interfaces and scheduled or event-driven synchronisation.
We treat integration as a first-class piece of engineering: contracts are documented, payloads validated, failures retried with backoff, and every transfer left with an audit trail that can answer the question “what happened to this record?”.
Interface design
REST and event interfaces with versioned, documented contracts.
Data mapping
Field-level mapping between systems that model the same thing differently.
Reliability
Idempotent operations, retries, dead-letter handling, and reconciliation.
Observability
Transfer logs and alerts so silent failure is not an option.
08 / Architecture & maintainability
Decisions recorded, boundaries respected
We favour architectures that a new engineer can hold in their head: a small number of clearly named modules, dependencies pointing in one direction, and integration points that are obvious from the folder structure.
Significant choices — data storage, transaction boundaries, synchronous versus asynchronous processing — are written as short decision records that state the context, the option chosen, and what would make us revisit it. This keeps future changes from being archaeology.
Maintainability is measured practically: how long it takes to add a typical feature, how confidently a change can be released, and how quickly a defect can be traced to its cause.
09 / Project delivery process
Six stages, repeated per increment
- 1
Discovery
We collect the problem statement, existing systems, constraints, and the outcomes you expect. Assumptions are written down instead of implied.
- 2
Scoping
Work is broken into deliverable increments with a shared definition of done, so progress is visible in working software rather than status reports.
- 3
Architecture
We draft the module boundaries, data model, and integration points, and record the reasoning behind decisions that will be expensive to reverse.
- 4
Implementation
Development proceeds in short iterations with code review, automated checks on each change, and running builds available for inspection.
- 5
Verification
Functional, integration, and regression testing run against realistic data before a release candidate is proposed.
- 6
Release & care
Deployment is automated and reversible, followed by monitoring, defect handling, and planned iteration on the next increment.
10 / Quality assurance & testing
Testing as a design activity
Automated tests are written alongside the code they describe: unit tests for domain rules, integration tests across service and database boundaries, and end-to-end checks for the handful of journeys that must never break.
Beyond automation we carry out exploratory testing on realistic data, review behaviour at the edges — empty states, large inputs, partial failures, concurrent edits — and check interfaces for keyboard operation and readable contrast.
Defects are reproduced before they are fixed, and a regression test is added so the same fault does not return quietly in a later release.
11 / Security-conscious engineering
Security practices we apply by default
Least privilege
Accounts, tokens, and database roles are scoped to the narrowest permission set that allows the task.
Input at the boundary
Requests are validated and typed where they enter the system; trust is never inherited from the caller.
Secrets handling
Credentials live in managed secret storage, never in source control, logs, or client-side code.
Dependency hygiene
Dependencies are kept current, reviewed before adoption, and monitored for published advisories.
Data minimisation
We collect and retain the data a feature genuinely needs, and separate sensitive fields from ordinary ones.
Authentication design
Session handling, password storage, and access checks are implemented server-side against established patterns.
Transport & storage
Encrypted transport as standard, with encryption at rest configured where the platform provides it.
Review discipline
Security-relevant changes receive an explicit second read before they are merged.
These are engineering practices, not a compliance guarantee. Where a project is subject to a specific regulatory regime, the applicable requirements are agreed in writing and treated as project scope.
12 / Collaboration & communication
Written first, so nothing depends on memory
Requirements, decisions, and open questions are captured in writing and kept with the project rather than scattered across conversations. Anyone joining later can read the trail instead of asking for it.
Work is tracked in small, reviewable units. Progress is demonstrated with running software at agreed intervals, and risks are raised as soon as they are visible rather than at the end of a phase.
We work in English, adapt to the issue tracker and repository host you already use, and keep the number of communication channels deliberately small.
13 / Ongoing support & product evolution
After the first release
A delivered system needs attention: dependency and runtime updates, monitoring of error rates and performance, defect handling, and periodic review of the parts of the codebase that have become harder to change.
Evolution is planned in the same increments as initial delivery. We keep a visible backlog that separates defects, maintenance, and new capability, so that upkeep is budgeted rather than squeezed between features.
Where a client team takes over, we prepare handover material — architecture notes, runbooks, environment setup, and a walkthrough of the areas that need the most care — and remain available for questions on agreed terms.
14 / Company information
Written enquiries welcome.
Describe the problem, the systems currently in use, and the outcome you have in mind. A short written summary is enough for us to respond with an informed view of scope and approach.
Company
PENCILTIP LTD
martincolem95@gmail.com
Website
penciltipgroup.com