Our Approach
How we think before we build —
and stay honest throughout.
Most projects fail not because of inadequate tools, but because of misunderstood requirements, poor scoping, and no knowledge transfer. Our approach is designed to address all three.
The starting point
We are not in the business of shipping code. We are in the business of solving problems.
There is a version of an IT engagement that starts with a statement of work, produces deliverables on schedule, closes the ticket, and leaves the client with a system they do not fully understand and cannot maintain. That version is common. It is also, from our perspective, a partial failure regardless of how clean the code is.
The GreaterHeight approach starts from a different premise: that a project is only successful if the client's situation is genuinely better after we leave than it was before we arrived — and that requires understanding the situation first, not proposing a solution first.
This shapes everything: how we scope engagements, how we structure teams, how we communicate during delivery, and what we hand over at the end. It is not a sales position. It is the only way we have found to do work we are willing to put our name on.
How we differ in practice
Common practice
Propose a solution in the first meeting
Our practice
Understand the problem before we name a solution
Scope based on what the client says they want
Scope based on what they actually need — and say when those differ
Deliver and move on
Deliver, document, transfer, and verify the client can operate it
Use the most advanced technology available
Use the most appropriate technology for this client's context
Optimise for speed of delivery
Optimise for total outcome, including maintainability
How an engagement runs
Five phases. No shortcuts.
Every GreaterHeight engagement — regardless of size or service area — moves through the same five-phase structure. The phases vary in duration and intensity depending on the project, but none of them are optional.
Phase One
Discovery
Before we discuss timelines or costs, we need to understand the problem. Discovery involves structured conversations with the client's key stakeholders, a review of any existing systems or processes, and an honest assessment of what the client has tried before and why it did not work. We are looking for the actual problem, which is often different from the presenting problem.
Discovery is not a courtesy step. It is where we determine whether we are the right fit for this engagement, and whether the engagement is viable as scoped. If it is not, we say so here — not after we have taken a deposit.
Phase Two
Scoping & Strategy
With the problem understood, we define the solution. This phase produces a detailed scope of work — what we will build, what we will not build, what assumptions we are making, and what dependencies exist on the client's side. We are explicit about trade-offs: budget and timeline constraints are real, and the scope document names them rather than hiding them in vague language.
For larger engagements, Scoping also includes an architecture decision record — the rationale for the technical choices we are making and why they are appropriate for this client's context, not just technically defensible in the abstract.
Phase Three
Build & Iterate
This is where the work happens. Depending on the engagement, this phase runs as a sprint-based Agile cycle, a structured waterfall delivery, or a hybrid — determined during Scoping based on what will actually work for this client, not what is fashionable. The client receives regular progress updates, access to a shared project environment, and clear visibility of what has been built, what is in progress, and what has changed from the original plan.
We do not hide problems until they become crises. If a technical obstacle emerges or a scope assumption proves incorrect, we surface it as soon as it is confirmed — not at the end of a sprint when it is too late to adjust.
Phase Four
Deployment & Stabilisation
Deployment is not the end of an engagement — it is the point at which real-world conditions replace controlled ones. We manage the go-live process carefully, with a defined stabilisation period during which we monitor system behaviour, resolve production issues, and confirm that the system is performing as expected under actual load and usage patterns.
Stabilisation length is defined during Scoping. It is not open-ended support, and it is not a safety net for scope that was not completed during Build. It is a structured period of observation and adjustment after go-live.
Phase Five
Knowledge Transfer & Handover
This phase is non-negotiable on every engagement. Knowledge transfer is the deliberate, structured process of moving operational understanding from our team to the client's team — or to whoever will maintain the system after we leave. It includes technical documentation, user guides, administrator guides, recorded walkthroughs, and a formal handover session.
The test for a successful handover is simple: can the client's nominated person answer a question about the system without calling us? If not, the handover is not complete. We do not consider Phase Five done until that test is passed.
What drives every decision
Six principles we apply without exception
These are not aspirations. They are working rules that govern how we engage with every client, on every project, at every scale.
01
Honesty before reassurance
When a client's timeline is unrealistic, we say so. When a proposed solution is the wrong fit for their context, we say so. When we identify a risk that the client has not accounted for, we name it — even if it makes the conversation more difficult. Clients who want someone to agree with them will find it uncomfortable working with us. Clients who want honest counsel will find it valuable.
02
Context above convention
A decision that is correct in a mature tech market may be incorrect in an African operating context — where infrastructure constraints, regulatory environments, connectivity realities, and talent availability are different. We apply global standards with local intelligence. This means some conventional choices are abandoned for context-appropriate ones, and we document the reason every time.
03
Maintainability as a design constraint
Code that works today and cannot be maintained in six months is a liability, not an asset. Every technical decision is evaluated against a maintainability question: can the client's team — or a competent successor team — understand, extend, and operate this system without us? If the answer is no, the architecture needs to change before it ships.
04
Scope discipline
Scope creep is often presented as a client failure. In our experience, it is usually a scoping failure — ambiguity in the original definition of work that creates space for expanding expectations. We invest significantly in Phase Two precisely to prevent this. When scope changes are requested mid-engagement, we process them through a formal change management step with a clear impact on timeline and cost.
05
Client competence-building
Dependency on a single vendor is a strategic risk for any client. Our goal is not to make ourselves indispensable — it is to build client capability alongside the deliverable. Every engagement should leave the client's team more capable than it was before the engagement began. This is not altruism; it is the foundation of a long-term relationship built on respect rather than lock-in.
06
Documented decisions, not tribal knowledge
Every significant technical and strategic decision made during an engagement is documented — with the decision itself, the alternatives considered, and the rationale for the choice. This protects the client if team composition changes, protects us if the rationale is later questioned, and builds an institutional record that survives handover. Documentation is not overhead. It is evidence of rigour.
What you receive at the end
The handover package
Technical documentation
System architecture diagrams, API references, database schemas, environment setup guides, and deployment runbooks — everything a developer needs to work on the system without starting from scratch.
Recorded walkthroughs
Screen-recorded sessions covering system administration, common user workflows, and troubleshooting steps — available for the client's team to reference after the engagement closes.
Training sessions
Live training for the client's designated administrators and end users — covering day-to-day operation, common scenarios, and what to do when things behave unexpectedly.
Monitoring and alerting setup
Configured dashboards, alert thresholds, and on-call procedures — so the client knows what normal looks like and receives notification when something departs from it.
Source code and access credentials
Full source code in a repository owned by the client, all access credentials transferred, and all third-party licences assigned to the client — not held in our name.
The handover package is not a courtesy gesture or a nice-to-have. It is a contractual commitment on every GreaterHeight engagement. We define what it contains during Scoping and we deliver it during Phase Five — not as an afterthought, but as a planned phase with its own timeline and sign-off criteria.
The reason this matters is straightforward: a client who cannot operate their own system is a client who is still dependent on us, whether or not that dependency is costed. We do not consider a project closed until the client can demonstrate operational competence over what we built.
On some engagements, clients elect to keep GreaterHeight on a support or managed services retainer after handover. That is a separate commercial arrangement — and it is one the client enters from a position of competence, not one we engineer by withholding knowledge during the handover.
"The job is not done when the code is shipped. The job is done when the client can operate what we built without us standing next to them."
Want to see this approach applied to your project?
We start every engagement with a Discovery conversation — no pitch, no proposal, no cost. Just a structured discussion about your problem.