Process & Standards

Our software development process

Discovery, estimating, build, testing, launch, handover, and what happens once the work is live. Each stage names the artefact it produces, so you know what lands on your side and when.

Overview

How our software development process works

Every project we take on runs through the same 8 stages. The stages do not change, but the weight given to each one does. A greenfield product spends longer in discovery and design than an integration into a system you already run. A rescue of a stalled codebase starts with an audit that a new build does not need. The shape stays constant so that everyone involved knows what comes next and what has to be true before it can start. We publish the reasoning behind these decisions in our engineering notes.

The reason we publish the process in this much detail is that most delivery problems are not technical. They come from unstated assumptions about who decides what, when feedback is due, and what counts as finished. Writing the process down removes most of that ambiguity before it costs anybody a week. The commercial side of that same question, what you own, how an engagement ends, and what a retained relationship looks like afterwards, is covered in full in our engagement models and exit terms.

We are deliberately technology agnostic. The stack is chosen during design, based on what the problem needs and what your team can maintain after we leave. The process is identical whether the answer turns out to be a web application, a mobile app, an automation layer over tools you already pay for, or a rebuild of something that has outgrown its original design. More on who runs this process day to day is on our about page.

Layered purple and blue wave forms folding over one another against a black background

The engagement lifecycle

The 8 stages of every project

Opening phase

Discover the actual problem

We start by understanding the business, not just the feature request. Stakeholder interviews, a map of how the work is done today, an audit of any system already in place, and an honest conversation about constraints. Most briefs describe a solution somebody has already picked. Our job in this stage is to check that it is the right one before anybody spends money building it.

OutputA written problem statement, a list of constraints, and a scope you can sign off on before any code exists.

Before build

Design the system and the interface

Architecture, data model, user flows, wireframes, and the stack decision. We do not start coding until this is settled. Changing a wireframe costs an afternoon. Changing a data model after six weeks of build costs weeks. This stage is where the expensive mistakes get made cheaply, on paper, where they can be undone.

OutputA technical specification, wireframes or prototypes, and an approved architecture, all signed off by you.

Before build

Estimate and lock the plan

With the design settled we can size the work properly. Each piece of scope is broken down, estimated against comparable work, and given a confidence level. Anything we cannot size confidently is flagged as a spike to be investigated rather than buried inside a larger number that looks precise and is not.

OutputA scope document with per item estimates, stated assumptions, and an explicit list of what is out of scope.

Main phase

Build in reviewable increments

Short sprints, each ending in a demo of software you can actually use. You see working functionality rather than a status report, and you can reprioritise the next sprint based on what you just saw. Nothing is a black box, and no sprint ends with a promise that something is nearly done.

OutputWorking software deployed to a staging environment, with automated tests covering the critical paths.

Continuous

Test against real conditions

Automated tests run on every change. On top of that we do exploratory testing, cross browser and device checks, accessibility passes, and load checks where traffic matters. We also test the unhappy paths, because the way software fails matters more to your users than the way it succeeds.

OutputA test report covering what was verified, what was found, what was fixed, and any known limitations.

Release

Launch with a rollback plan

Production deployment, security review, performance check, monitoring and alerting configured before the release rather than after it. Every launch has a documented way back. Releasing without a rollback route is not confidence, it is a gamble taken with somebody else's business.

OutputA live product, monitoring and alerts in place, and a rehearsed rollback route if the release needs reversing.

Release

Hand over the knowledge

Documentation, a runbook, an architecture overview, and a working session with whoever will own the system next. Handover is a deliverable, not a courtesy. If your team cannot change the thing we built without calling us, we have not finished the job we were paid to do.

OutputA runbook, architecture notes, environment and access documentation, and a recorded walkthrough for your team.

Ongoing

Run, measure, and improve

Most clients stay with us after launch, on a retainer, for the next block of work, or for managed support. We know the codebase, we are available, and we would rather tell you an idea is not worth building than bill you for it. Support after launch is where a supplier becomes a partner or does not.

OutputA support window after launch, then whatever ongoing arrangement genuinely fits, including none at all.

Your side of the work

What the client is responsible for

Projects rarely stall on engineering. They stall waiting for a decision, an access credential, or a piece of content. Here is what we need from you, stated up front so it can be planned around rather than discovered late.

One named decision maker with the authority to decide

Someone who can approve scope, resolve conflicting internal opinions, and say no. Reviews by committee without a tiebreaker are the most common cause of a project drifting, and it is a problem only you can solve for us.

Feedback inside the agreed review window

Each demo comes with a window for feedback so the next sprint can be planned. Late feedback does not disappear, it lands on work that has already been built on top of it, which is how a small comment becomes an expensive change.

Access to systems, accounts, and environments

Credentials, repository access, DNS control, and contacts for any third party we need to integrate with. These are usually simple to arrange and frequently take longer than the work they block, so we ask for them during discovery rather than on the day we need them.

Content, data, and anything only you can supply

Copy, images, product data, legal text, and any migration source. We can build around placeholders for a while, but a launch date depends on real content existing. We flag exactly what is needed and when, early enough for it to be planned properly.

Scope changes

How change requests are handled mid project

Scope changes are normal. Pretending they are not is what turns them into arguments. We expect them, we have a route for them, and that route is the same whether the request comes from you or from something we learned during the build.

Raised in the open, against the written scope

Anyone can raise a change, including us. It goes on the board against the original scope document so the comparison is visible rather than remembered differently by each side a month later.

Sized with its knock on effects included

We come back with the effort, what it displaces, and any consequences for the architecture or the timeline. Some changes are genuinely free because they replace work not yet started. Others are not, and we say so plainly rather than absorbing them quietly and resenting it.

Approved, swapped, or deferred, never assumed

You decide whether to add the change, trade it against something already in scope, or park it for a later phase. Nothing is built on a verbal maybe, and nothing already agreed is quietly dropped to make room for something new.

Post launch

What happens after launch

The weeks after go live are the ones that decide whether a project was worth doing. Real usage exposes things no staging environment can, and somebody has to be there when it does.

A support window included after go live

The first weeks in production surface the things staging never could. That window is part of the project rather than a separate purchase, and it exists so that real world issues get fixed by the people who wrote the code.

Monitoring watched by someone, not just configured

Alerts are only useful if a human is attached to them. Where we run the infrastructure, we watch it. Where your team runs it, we make sure they know what each alert means and what the first response to it should be.

Measurement against the baseline agreed at the start

In discovery we wrote down what success looks like. After launch we go back to it and check honestly whether the change happened. If it did not, that conversation is more useful than any feature we could add instead.

An ongoing arrangement only if it is warranted

Retainer, next phase, occasional support, or nothing at all. We would rather have a client who comes back when they need us than one paying monthly for a service they are not using. Where a retainer makes sense we say why, and where it does not we say that too.

Honest differentiation

What our delivery process deliberately avoids

We do not disappear after launch, every project includes a support window, and most clients stay with us beyond it.

We do not hide behind junior developers, the people you talk to are the people who write the code. There is no bait and switch between the pitch and the delivery.

We do not over engineer, we build what is needed rather than what is impressive. The simplest thing that solves the problem is almost always the right thing.

We do not take on projects we cannot resource, when we say yes we mean it. We would rather turn work down than accept it and under deliver on it.

We do not lock you in, the code, the accounts, and the documentation are yours, and you can take them elsewhere without asking us for permission.

We do not bury changes in an invoice, if scope moves you hear about it when it moves and you decide what happens next.

Questions

Software development process FAQs

How long does the software development process take?

It depends on scope and how much already exists, which is why we size the work after design rather than before it. What we can commit to is the shape, a discovery phase, a design phase, then reviewable increments where you see working software regularly rather than waiting for one delivery at the end.

Do I need a specification before we start?

No. Discovery exists precisely because most clients arrive with a problem rather than a specification. If you already have one we will review it, but we will still check the assumptions inside it before treating it as the plan.

What happens if the estimate turns out to be wrong?

You see the assumptions behind every estimate, so when one proves wrong we can point at the specific item that moved and why. We tell you as soon as we know rather than at the end, and you decide whether to adjust scope, timeline, or both.

How often will we actually see progress?

Every sprint ends with a demo of software running in a real environment that you can use yourself. Between demos, the project board is open to you, so progress is visible continuously rather than only at scheduled checkpoints.

Who owns the code and the documentation?

You do. Code, infrastructure configuration, documentation, and the accounts they run on are yours. Handover is designed so that another team could pick the work up without needing us, which is the only honest test of whether a handover was real.

Can we change direction partway through a project?

Yes, and most projects do to some degree. Changes are raised against the written scope, sized with their knock on effects, and then approved, traded, or deferred by you. What we avoid is silent scope drift, where nobody agreed to anything but the timeline moved anyway.

Next step

Ready to start your project?

Every engagement starts with a conversation. Pick the one that fits where you are. If you would rather see the outcomes first, the solutions and services pages cover what we build.

Get a quote Have questions? Contact us

[email protected]
[email protected]

Lahore, Pakistan · London, U.K · Austin TX, U.S · Toronto, Canada