Discovery
Understand the problem before proposing a solution.
A process designed to remove surprises
Most software projects do not fail on technology. They fail because nobody wrote down what was actually being built, who decides, and what "done" means. Our process exists to make those things explicit early, while changing them is still cheap.
01 — The phases
From first conversation to production
Each phase ends with something you can read and approve. Nothing moves forward on a verbal "sounds good".
Design
Decide the architecture on paper, where changes are free.
Development
Build in short iterations with a working build at the end of each.
Delivery
Release, document, transfer knowledge, then support.
Phase 01
Discovery
We start by asking uncomfortable questions: what happens today, who is affected when it breaks, which parts genuinely cannot change, and what budget reality actually allows. Where an existing system is involved, we read its code and its data before forming an opinion about it.
Discovery ends with a written brief: the problem stated plainly, the scope we recommend, the risks we can see, and an estimate with the assumptions it depends on. If we think the project should be smaller — or should not happen at all — this is where we say so.
Deliverables
- Problem and scope statement
- Constraints and risk register
- Estimate with stated assumptions
- Recommended engagement model
Phase 02
Design & architecture
Before the first feature branch, we settle the shape of the system: the data model, the service boundaries, the interfaces between components, the authentication and authorisation model, and how it will be deployed and observed.
Significant choices are captured as short architecture decision records — what we chose, what we rejected, and why. Months later, when someone asks why the system works this way, the answer exists in writing rather than in someone's memory.
Deliverables
- Architecture and data model documentation
- Interface and API contracts
- Architecture decision records
- Environment and deployment plan
Phase 03
Development
We work in short iterations, each ending with a build you can actually use. Every change goes through peer review and an automated test suite before it is merged; nothing reaches the main branch on trust alone.
You get a written summary each iteration: what was completed, what moved, what we learned, and anything that now threatens the plan. Bad news travels immediately — a schedule risk raised early is a scheduling problem, and raised late it is a crisis.
Rhythm
- Working build at the end of each iteration
- Written progress and risk summary
- Peer review on every change
- Tests and static analysis in CI
Phase 04
Delivery & care
Handover is a process, not an email with a zip file. We deploy through the same automated pipeline you will use afterwards, hand over credentials and infrastructure into accounts you own, and walk your team through the system until they can operate it without us.
From there you can take it in-house entirely, or keep us on under a maintenance agreement with an agreed response window. Either way, everything needed to run the system belongs to you.
Deliverables
- Production deployment and runbook
- Administrator and operations documentation
- Credential and account transfer
- Support terms and escalation path
02 — Engineering standards
The rules we do not negotiate
These apply to every project regardless of size, budget or deadline. They are the reason our work can be handed to someone else.
STANDARD 01
Everything in version control
Application code, infrastructure definitions, database migrations and documentation all live in a repository you own. No configuration exists only on a server.
STANDARD 02
Review before merge
No change reaches the main branch without a second engineer reading it. This catches defects, but more importantly it means at least two people understand every part of the system.
STANDARD 03
Automated tests as a gate
The test suite runs on every commit and a failing suite blocks the merge. Coverage targets are agreed per project, but the gate itself is never switched off to hit a date.
STANDARD 04
Reproducible environments
Any environment can be rebuilt from the repository. If a machine is lost, that is an inconvenience rather than an incident.
STANDARD 05
Secrets stay out of code
Credentials live in a managed secret store, scoped per environment and rotatable without a code change. They are never committed, and never sent by email.
STANDARD 06
Documentation ships with the code
A system without a runbook is not finished. Setup, deployment, backup and recovery instructions are written as the work happens, not reconstructed at the end.
03 — Working together
Written by default, in English
Decisions made in a call are decisions nobody can find in six months. We confirm anything that matters in writing, in a place both sides can search.
- One named contact on our side who is accountable for the engagement, not a rotating account manager.
- A shared tracker you can read at any time — no waiting for a status meeting to learn where things stand.
- Iteration summaries in writing: completed, in progress, blocked, at risk.
- Calls when they help, followed by a written note of what was agreed.
- Escalation path defined before you need it, with response windows in the contract.
1
Accountable contact per engagement, from first call to handover
24h
Target first response to written enquiries on business days
2
Engineers minimum familiar with every part of your system
0
Undocumented steps between your repository and production
04 — Practicalities
Common questions about the process
Can you start without a full specification?
Yes — that is what discovery is for. A complete specification written before anyone has looked at the systems involved is usually wrong anyway. We scope discovery as its own small engagement, and you are free to take the resulting brief elsewhere.
What happens when the scope changes mid-project?
Scope changes are normal. We handle them explicitly: the change is described, estimated, and its effect on the timeline is stated before it is accepted. What we avoid is silent scope drift, where work expands and only the deadline notices.
Do we get access to the repository during development?
Yes. Unless you ask otherwise, development happens in a repository under your organisation from day one. You can read every commit as it lands, and your own engineers are welcome in review.
Can our in-house engineers work alongside your team?
Often the best arrangement. We agree on shared conventions, review each other's changes and treat it as one team. It also makes handover almost a non-event, because your people were never outside the process.
What if we want to stop the engagement?
The notice period is set out in the agreement. On termination we complete a handover of code, infrastructure, credentials and documentation for everything delivered and paid for. Nothing is held hostage — the commercial framework is described in our Terms and Conditions.
Start with discovery
A short, scoped engagement that ends with a written brief you own — whether or not you build it with us.
HALDIR LTD · HE 459882 · Nicosia, Cyprus