Most software projects go wrong before anyone writes any code, because nobody took the time to understand what the business does.
So that’s where we start. You see a definite price for a build before you’re asked to commit to it, and the specification that produces the price is yours whichever way you go.
The first conversation is free. After that, CDE Systems does the work, in stages, and stays on to look after it.

The first conversation is free
We’ll happily come and see you, find out what the business needs, and leave you with a budget cost and an outline programme.
If all you need for now is a ballpark figure, a phone call will do. Many conversations stop there, and that’s fine.
The requirements report
Expect half a day to a day of us on site. Most of it is spent with the people who use the current system, 15 to 30 minutes each, finding out what they do and how the system fits into it. A shorter session with a few users and managers then pins down what the new system has to achieve. We also look over your existing data, and whether your servers and network can host it.
The report describes where things stand today and sets out what the new system should achieve. The full specification is built on it.
Why the users, and not only the managers. The people doing the work know where the workarounds are and which fields everyone skips. They know what they’ve quietly stopped recording. That’s the detail that decides whether a new system gets used or merely put up with.
The specification sets the price
This takes one to two days on site. It covers:
- Further interviews with users and managers
- How the existing system works, and how its data is structured
- What it would take to move the data from the old system to the new
- What the new system collects, and how it fits together
- The sections, features and functions it needs
- Security: user groups, sign-in, encryption, monitoring and auditing
- A timetable, with milestones and progress meetings
- Testing and training, and when they happen
The specification gives you a definite price for the build. Go ahead, and what you paid for the specification comes off that price.
It works this way because nobody can honestly fix a price for a system that hasn’t been specified, and you shouldn’t be asked to commit before you know the cost. The work that produces the number gets paid for and done thoroughly, then credited back. You keep the specification whatever you decide. If you take it to another developer, it will still be a better brief than most of them see.
Building it
A project meeting with a client
Built in stages, to the agreed milestones. You see working software early on, not just at the end.
Tested by the people who’ll use it, before go-live. Users always find something. At Lilleker Engineering they spotted several improvements during testing, and those went in before the system went live. Finding them then costs far less, and hurts far less, than finding them in week two.
The data move is planned from the start. It isn’t left to the switch-over weekend.
Training and handover have their own place in the timetable, so they aren’t squeezed in at the end.

After go-live
Once the system is live, maintenance and support usually costs 10–15% of the development cost a year. That covers support by phone and email, plus minor updates, under a fair use agreement.
The small requests are included deliberately. A new report, another field, a form that needs to match how the job is done now. They keep coming for as long as the system is in use. Charge for each one and people stop asking, and start working around the system instead. Larger pieces of work are scoped and priced on their own, so you can decide if they’re worth it.
If you’re not starting a project
A lot of people arrive with a system somebody else built, no documentation, and no wish to replace it. For them the first step is different.
There’s no specification. We get to know what you have instead, including how it’s put together, where the data is kept and what’s likely to go wrong next. That’s written down for you, and from then on any work can be properly quoted. Support then runs as ad hoc help, a support agreement or a managed arrangement, whichever fits.
Legacy software rescue Database and inherited system support
Changing things in stages
Unless there’s truly no alternative, we don’t replace a whole system in one go. When something needs modernising, we start with the part causing the most pain. We build it and settle it in, then move on to the next. The current system keeps running the whole time, and if you stop after the first stage, what’s been built still works.
It’s slower to describe and considerably safer to live through.
What you can expect from us
You speak to the people doing the work. No account manager and no first-line script, and the same people each time.
You’ll hear when not to spend money. If the fix costs less than the project, or the system is fine as it is, that’s what we’ll say.
You own everything. The data, the documentation and the specification all go with you if you take the work elsewhere.
We’ll still be here afterwards. Most of the systems we’re called out to were built by someone who can no longer be reached, and we’d rather not become that.
Something to send your manager
How a project with CDE Systems works
- Free first conversation, by phone or on site, giving a budget figure.
- Requirements report: half a day to a day on site, talking to users and managers.
- Full specification: one to two days on site. It gives a fixed price for the build, and its cost is credited if we go ahead. We keep the specification either way.
- Build in stages, tested by our own users before go-live.
- Support: usually 10–15% of the development cost a year.
Case Studies
Commercial Catering Service & Maintenance (field service)
Aire Valley Catering
Field service apps that work with no signal
Aire Valley Catering’s engineers work in commercial kitchens across the UK, often with no usable signal, and every job still has to be recorded. We built four production…
View case study
Transport and logistics
ACC Worldwide
A faster SQL Server system, noticed on day one
ACC Worldwide’s staff used one business system all day, every day, and it was slow. We worked on the SQL Server environment behind it. The speed-up was immediate,…
View case study
Travel and leisure (adventure travel and expeditions)
Jagged Globe
Keeping bookings, customer records and the website in step
Jagged Globe runs on an internal database and a booking website that have to agree every day, and sometimes they didn’t. We traced and fixed the transfers between…
View case study
Start with a conversation
Tell us what the business needs to do. We’ll come back with an outline of what’s involved and a budget figure, on the phone if that’s enough or in person if it’s worth it.
