A lot of business systems are built from a wish list for the interface. It looks right on the first day. Then the business changes, the data model doesn’t fit how the work is actually done, and the next few years go on working around it.
What most people want is fairly simple to describe. One place where the information lives, entered once and checked as it goes in, and something every part of the business can rely on, from the office to the people out on site.
CDE Systems has designed and built custom systems on Microsoft SQL Server for businesses and for local and central government since 1999. We start with how your work moves through the business, design the database around that, and give you a fixed price before you commit. You don’t need to know what a schema is. That’s our job.
Where it tends to go wrong
- The same customer exists in three places, with three slightly different addresses
- Two reports that should agree don’t, and nobody can say which is right
- Every new feature needs a workaround, because the data was never shaped for it
- Several applications write to the same tables, each in its own way
- An off-the-shelf package does most of the job, and the rest lives in spreadsheets
None of that means anyone chose badly. A business moves on from the one the system was designed for, and the database is usually the last thing to catch up.
We design before we build
The first conversation isn’t about SQL Server. We want to understand how a job, an order or a case moves through your business from start to finish, including the steps people have stopped mentioning because they’ve always done them.
Then we design the data model around that. It’s normalised where it should be and denormalised where performance needs it, and the keys, constraints and indexes are decided at the start instead of being added later when something gets slow.
That work usually turns up two or three things worth changing before any code is written. It’s also where you find out what the build will cost.
One database, several ways in
SQL Server often sits behind something else, such as a web application, a mobile app, an Access interface or a set of reports. Sometimes it’s all four, working from the same data.
We design the database to serve all of them, with one version of the truth and APIs over the top, so each application goes through the same front door. When a new way in is needed later, it’s added to the same data. See SQL Server integration and APIs and web applications for existing systems.
What we build
Business systems on SQL Server, each one planned and designed for the business that will use it. They include:
- Job and works management
- Stock, product and parts databases
- Supplier and contractor management
- Quoting, ordering and invoicing
- Scheduling and resource planning
- Compliance and checks, including display screen equipment (DSE) assessments
- Asset and equipment tracking
- Reporting and management information
They’re designed to change, because the business will.
What we build with
Most of what we build runs on Microsoft SQL Server or Microsoft Access, and often both together. That’s where our 25 years sit, and for most businesses it’s where the investment goes furthest.
- SQL Server and Azure SQL, for systems with a lot of people in them at once, heavy reporting or strict security
- An Access interface over SQL Server data, which gives staff familiar forms with a heavier-duty engine underneath. It’s one of the most common and cost-effective things we build. See Access migration and upgrades
- Around them. C# and .NET, Node.js and NestJS, and TypeScript on the back end. React and Next.js for the web. React Native, or native Swift and Kotlin where scanners, cameras or offline working need it. Azure for hosting, with environments defined in Terraform
- Still supported. PHP, classic ASP.NET, VB.NET and Java. Plenty of working systems are built on these, and we’d sooner keep yours running than tell you it needs replacing. See legacy software rescue
What you get
- A fixed scope and a fixed price for the build, agreed before we start
- Your data, in a format you own, in the cloud or on your own hardware
- Documentation of the design, so you don’t depend on us to understand your own system
- Testing with the people who’ll use it, before it goes live
- Someone to ring afterwards who remembers building it
- Software escrow if you want it, with the source code held by an independent third party
The last two matter more than they look. Most of the systems we’re called in to look after were built by someone who can no longer be reached, and we’d rather not become that.
Is SQL Server the right choice?
Not always, and we’ll say which way we’d go. If it’s one site, a modest number of users and Office is already paid for, a Microsoft Access system may do the job for less. See Access design and development.
SQL Server earns its place when a lot of people work in the system at once, when the reporting is heavy, when security requirements are strict, or when a web or mobile application needs the same data. There’s more in why use SQL Server?
Built around the people using it
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
Tell us what the business needs to do
Leave the interface to us. Tell us what gets done by hand, what goes wrong and who it affects. We’ll come back with how we’d design it and what it would cost, before you commit to anything.