How we run a software project

Most failed projects fail from long silences, late surprises and building too much at once. Our process is designed to avoid all three.

First conversation

You tell us what you’re trying to achieve, and we ask a lot of questions. Often the most useful outcome is a clearer view of the problem, or a suggestion that you don’t need custom software at all.

You get: An honest view on fit, and rough costs if we can give them.

Discovery and scoping

For larger projects, we spend a short, paid period with the people who’ll use the system. We map the workflows, look at existing systems and data, and test anything technically risky. Then we agree what the first release should include, and what it should leave out.

You get: A written scope, a technical approach, a release plan and a budget.

Design and prototype

We turn the scope into clickable prototypes and test them with real users. Mistakes at this stage take minutes to correct, rather than weeks.

You get: Tested prototypes and final designs that the developers helped shape.

Build in short cycles

Work runs in cycles of about two weeks. At the end of each one, you see working software in a staging environment and can decide what comes next. Code is reviewed and covered by automated tests, and you can see progress against budget at any time.

You get: Regular demos, a staging site you can use, and clear budget tracking.

Launch

We plan the rollout according to how much risk there is. That can mean a phased release, a data migration rehearsal, or old and new systems running side by side. For websites, it includes redirects and search checks.

You get: A live system, training, documentation and access to everything in your name.

Support and improve

Software is never really finished. After launch, we handle security updates and monitoring, and use real usage data to decide what to improve next. If you’d prefer to take it in-house or move elsewhere, we’ll hand over properly.

You get: Monitoring, updates and a roadmap based on evidence.

What we’ll need from you

Software projects go best with an engaged client, and that doesn’t need to take up all of your time. We’ll ask for one person who can make day-to-day decisions, some time from people who’ll actually use the system, and regular attendance at demos. Slow decisions are the most common cause of delay, so it’s worth arranging this early on.

How we handle change

You’ll learn things as the project goes along, and your priorities will change. That’s normal. We keep a visible, ordered backlog, and when something new comes up, we look at what it replaces or what it adds to the budget. You make that decision with the numbers in front of you.

Frequently asked questions

Do you use agile?

We work in short cycles with frequent feedback, which is what most people mean by agile. We don’t insist on any particular methodology’s ceremonies, and we can fit around how your team works.

How involved do I need to be?

You’ll need someone available for questions and decisions, and for demos every couple of weeks. It’s generally a few hours a week rather than a full-time commitment.

What if we want to stop part-way through?

Working in short cycles means you’ve always got something usable, and you can stop at the end of one. Check your contract covers ownership of work completed so far.

Want to see how this would work for your project?

Tell us what the software has to do. We will read it properly and reply by email with sensible next steps.

Discuss Your Project