How We Work

Most software projects go wrong before anybody writes any code — because nobody spent enough time understanding what the business actually does.

So that’s where we start, and we charge for very little of it until you know what you’re buying.

☎

Initial consultation — free

We’re always happy to visit and fully understand your requirements, then provide a budget cost and an outline programme.

If all you want at this stage is a rough number, we’re equally happy to discuss it over the phone and give you an approximate idea of cost. Plenty of conversations end there, and that’s fine.

Initial requirements report

Usually half a day to a day on site.

• Talking to users about their roles, responsibilities and how the current system works — 15 to 30 minutes each
• A session with a small group of users and managers about the objectives and requirements for the new system
• Assessment of your current data
• Assessment of your current IT infrastructure and whether it’s suitable for hosting the new system

You get a report setting out where things stand now and defining ambitious objectives for the new system. That becomes the basis and the direction for the full specification.

Why we talk to users, not just managers. The people doing the job know where the workarounds are, which fields everyone ignores, and what they’ve stopped bothering to report. That’s the detail that decides whether a system gets used or tolerated.

Full system specification

One to two days on site.

• Further interviews with users and managers
• A detailed look at the functionality and data structure of the existing system
• Full appraisal of transferring data from the old system to the new
• Data structure — what gets collected and how it fits together
• Sections, features and functionality required
• Security specification — user groups, authentication, encryption, monitoring and auditing
• Timetable — development timeline, progress meeting schedule and project milestones
• Testing and training requirements and schedule

The specification gives you a definite price for the development — and the cost of the specification is discounted against it if you go ahead.

That’s deliberate. Nobody can honestly quote a fixed price for a system they haven’t specified, and you shouldn’t have to commit to a build before you know what it costs. This way the work that produces the number is paid for, properly done, and credited back.

The specification is yours either way. If you take it to somebody else, it’ll still be a better brief than most people ever write.

Building it

[IMG-1] — A progress meeting, or a screen being demonstrated to someone who isn’t a developer. Real, not staged.
Alt: Reviewing a system with the people who will use it

In stages, against the agreed milestones. You see working software early rather than at the end.

Tested by the people who’ll use it, before go-live rather than after. They always find things. On one recent project users identified improvements during testing and we built those in before the system went live — which is far cheaper and far less painful than discovering them in week two.

Data migration appraised up front, not left as an afterthought at cutover.

Training and handover planned into the timetable, not squeezed in at the end.

After go-live

Maintenance and support is usually 10–15% of the development cost per year, covering telephone and email support, and minor updates, subject to a fair use agreement.

That deliberately includes the small stuff — a new report, an extra field, a form that needs to work differently because the business does. Those requests never stop, and a support arrangement that bills for each one just means people stop asking and start working around the system.

Bigger pieces of work get scoped and priced separately, so you decide whether they’re worth doing.

Hours: [CDE to confirm — see notes]

→ support

If you’re not starting a project

Plenty of people come to us with a system somebody else built, no documentation, and no intention of replacing it.

That works differently. Rather than a specification, we start by understanding what you’ve got — how it’s built, where the data lives, what’s holding it together and what’s likely to cause trouble next. That gives you something written down, and it makes everything after it quotable rather than guesswork.

From there it’s ad-hoc support, a support agreement, or a managed arrangement — whichever fits.

legacy software rescue · database support

Changing things in stages

We don’t do big-bang replacements unless there’s no alternative.

Where a system needs modernising, we take the part that hurts most, build that, get it working properly, and move on. The existing system runs throughout. If you stop after phase one, phase one still works and still earns its money.

It’s slower to describe and considerably safer to live through.

→ modernise existing systems

What you can expect from us

You speak to the people doing the work. Not an account manager, not a first-line script. The same people, call after call, who know your system.

We’ll tell you when not to spend money. If the fix is cheaper than the project, or the system’s fine as it is, that’s what you’ll hear.

You own everything. Your data, your documentation, your specification. If you take the work elsewhere, it all goes with you.

We’re still here afterwards. Most of the systems we get called out to were built by somebody who’s no longer reachable. We’d rather not become that.

Links block

Case studies

all case studies