Everyone in this trade knows the project: a new developer starts, "just running it locally" takes three days, the README points to a colleague who left last year and the only working configuration lives on one laptop. The misconception is that this simply comes with custom software. It does not. How long it takes before someone who has never seen the project can make their first change, the time-to-first-commit, is a quality metric, and we manage to it in everything we build.
This is a client's problem
Time-to-first-commit sounds like developer comfort, but the bill lands with the client:
- The bus factor — if one person can run the project, you do not have a supplier but a hostage situation with good intentions. That one person's holiday, illness or departure becomes your risk.
- Every handover costs days — onboarding time is paid time not spent on your product, with us and with every party after us.
- Incidents do not wait — fixing an outage starts with being able to run the project. Every day of setup time sits in front of the first line of the fix.
- A second opinion becomes impossible — anyone asking another party for a quote discovers that "transferring the project" is a project in itself.
What we deliver so day one is actually day one
- One described route up — the environment is built from what is in the repository, with one command or one short, accurate set of steps. No oral tradition, no "just ask…".
- Seed data — a development database with realistic, anonymised content. An empty application looks fine and hides everything; with real volumes and edge cases you see immediately what is going on.
- Configuration without memory work — settings are explicit in the project, with an example configuration in the repository and secrets in an agreed place. Nothing lives only in someone's head or shell history.
- Documentation that cannot go stale — the environment description is not a document about the project but a part of the project: the same description a developer starts with locally is used by the deployment. Documentation that is executed daily stays true by itself.
The fresh machine does not lie
The only honest measurement is a machine with no history. On the builder's laptop it always works; that is where the forgotten dependencies have been sitting for years. That is why our CI pipeline is more than a test runner: every change is built and tested on an environment that comes up from zero. If the pipeline can run the project without prior knowledge, a new developer can too; and wherever the pipeline would need manual work, that is exactly where the project secretly runs on memory.
What you notice
Very little, and that is the point. Development does not stall on who happens to be available, an urgent fix starts at the fix instead of at the setup, and if you ever want to continue with another party, you receive a project that is transferable instead of a box of parts. Like error tracking, this is not an extra on the quote but the standard shape of what we deliver.
Curious how your project scores?
An honest first test costs an afternoon: put someone who does not know the project behind a fresh machine and time how far they get. If that disappoints, or you want what we build or take over to meet this from day one: get in touch and we will look at where the setup time currently goes.