About Us
An IT company organised around engineering judgement
Hitch and Hike builds and maintains software for organisations that depend on it daily. We work as one team across discovery, design, implementation and operation, and we choose our engagements so that the people who plan the work are the people who deliver it.
Mission
Make dependable software an ordinary outcome
Our mission is to give organisations software they can rely on without needing to think about it — systems that behave predictably, fail visibly rather than silently, and can be changed safely as the business changes. We measure our contribution by how little friction the software creates for the people who use and maintain it.
Vision
Technology work that explains itself
We want technical work to be legible to the people paying for it. That means plain descriptions of what is being built, honest reporting of progress and problems, and artefacts — documentation, tests, infrastructure definitions — that let any competent team continue where we left off.
Values
The commitments we hold each other to
Honesty about trade-offs
Every technical choice costs something. We name the cost instead of hiding it in a proposal.
Craft over speed theatre
Fast delivery matters, but not the kind that borrows from next quarter's maintenance budget.
Shared understanding
Nothing important lives only in one person's head. Decisions get written down.
Care for the end user
The person using the software at 4pm on a difficult day is the real client.
Restraint
The best system is often the one with fewer moving parts, not more.
Responsibility after launch
Shipping is the middle of the work, not the end of it.
Working principles
How we actually work
- 01
Understand before building
We start with the workflow as it actually happens, including the exceptions people work around.
- 02
Design the interfaces first
Data contracts and boundaries are agreed early, because they are the hardest things to change later.
- 03
Automate the repeatable
Builds, tests, environments and deployments are scripted so results do not depend on who ran them.
- 04
Measure before optimising
Performance work follows profiling. Guesswork tends to move the bottleneck rather than remove it.
- 05
Keep changes small
Short-lived branches, frequent integration and reviewable diffs reduce the cost of being wrong.
- 06
Leave the codebase readable
Naming, structure and comments are written for whoever maintains the system next.
Approach to technology
Boring technology, carefully applied
We favour mature, widely supported tools and reserve novelty for the places where it earns its keep. A familiar database with a well-designed schema outperforms an exotic store with a careless one, and it is far easier to hire for.
New technology enters our stack after it has been tried on something contained, reviewed against the alternatives and documented. We are equally willing to remove tools: unused services, dead feature flags and abandoned dependencies are liabilities, and we clean them up rather than route around them.
Team culture
A small group with written habits
We work remotely and asynchronously, which makes writing the default medium. Proposals, decisions and reviews are recorded, so context does not depend on who happened to be in a call. Meetings exist to resolve disagreement, not to broadcast status.
Code review is a normal, expected part of every change, and it is directed at the code rather than the person. Engineers are given time to learn the domain they are building for, because software written without understanding the work it supports tends to be technically correct and practically wrong.
Quality and security
Built in, not bolted on
Quality mindset
Automated tests accompany the code that needs them, and the suite is kept fast enough that people run it. Definition of done includes documentation, error handling and the operational view — not only a passing build.
Security mindset
Least-privilege access, secrets kept out of repositories, dependency and vulnerability review as part of the pipeline, and data handling designed around what genuinely needs to be stored. Security decisions are documented alongside the architecture.
Collaboration process
What working together looks like week to week
- 01
Kick-off
We agree the outcome, the constraints, the people who decide, and how we will know the work succeeded.
- 02
Weekly rhythm
A short planning conversation, continuous written updates and a demo of working software each iteration.
- 03
Shared backlog
Priorities are visible to both sides; scope changes are discussed with their consequences attached.
- 04
Direct access
Clients speak with the engineers on their project, not only with a coordinator.
- 05
Review and adjust
At the end of each phase we look at what slowed us down and change the process accordingly.
- 06
Handover
Documentation, runbooks and credentials transfer cleanly whether or not we continue with support.
Company details
Contact information
- Company
- Hitch and Hike
- olivemccoy61@gmail.com
- Website
- hitchhikeclub.com
https://hitchhikeclub.com