Database-driven software, end to end.

Most of what we build is a line-of-business application: something that captures work, enforces rules, stores it properly and reports on it. We'll pick the delivery model that fits the job rather than the one that's fashionable — a fast desktop client for heavy data entry, a browser application for people spread across sites, or a service with no interface at all.

• Windows desktop applications in WPF and WinForms
• Web applications with ASP.NET Core, MVC and Blazor
• REST / JSON APIs and Windows or background services
• Extending, refactoring and rescuing existing .NET codebases
• Entity Framework or hand-written SQL — whichever the workload warrants

• C#
• .NET
• ASP.NET Core
• Blazor
• WPF
• WinForms
• Web API

A good schema is quietly worth more than any front end — it is the thing that will still be there in fifteen years when the interface has been rewritten twice. We design data models that reflect the business honestly, then make them fast.

• Relational design, normalisation and sensible constraints
• Stored procedures, views, functions and complex T-SQL
• Index strategy, execution plan analysis and query tuning
• Data cleansing, de-duplication and bulk import routines
• Backup, recovery and integrity checks that someone has actually tested
• SQL Server on premise, or Azure SQL in the cloud

• SQL Server
• T-SQL
• Azure SQL
• SSIS
• Indexing
• Query tuning

We have written FoxPro, Clipper and dBASE systems ourselves, which means we can read yours. That is the difference between a migration that preserves your business rules and one that quietly loses half of them.

• Assessment of the existing system: what it does, what it's worth, what a move involves
• Data migration from DBF, Access, Paradox, flat files and older SQL editions
• Business rules extracted from the old code, documented, then re-implemented
• Staged cut-over with parallel running, so trading never stops

More on how a migration runs →

• Visual FoxPro
• Clipper
• dBASE
• MS Access
• VB6
• DBF → SQL

Almost every business has a job that runs on somebody exporting a file, editing it, and importing it somewhere else. It works right up until the day that person is on leave. Those are usually the cheapest and most satisfying problems we get to solve.

• System-to-system integration over REST, SOAP, files or direct database links
• Scheduled imports and exports with proper error handling and alerting
• ETL and data warehousing feeds
• Accounting, payroll, e-commerce and third-party API connections
• Replacing spreadsheet-and-email processes with something that runs itself

• REST / JSON
• XML & CSV
• EDI feeds
• Scheduled services
• ETL

The reporting requirement is nearly always the same: the right numbers, quickly, in a form somebody outside IT can read without a training course. We build the operational reports people open every morning, not the dashboard nobody looks at twice.

• Operational and management reporting with SQL Server Reporting Services
• Power BI datasets, models and dashboards
• In-application reporting, print layouts and PDF output
• Scheduled report distribution by email
• Excel exports that are actually structured for further analysis

• SSRS
• Power BI
• Dashboards
• PDF output
• Excel

Most businesses don't have a reporting problem so much as a data problem: the numbers live in four systems and two spreadsheets, and no two of them agree. The fix is unglamorous — clean it, structure it, and load it somewhere purpose-built.

• Data cleansing, de-duplication and validation of existing records
• Dimensional modelling and data warehouse design
• Repeatable ETL pipelines that load on a schedule and tell you when they fail
• Consolidating data from separate systems into a single reporting source
• Data analysis to extract the insight that's already sitting there unread

• Data warehouse
• ETL
• Dimensional modelling
• Data cleansing
• Analysis

A surprising amount of our work starts with an orphaned application: no documentation, no source control, and the developer who wrote it long gone. We are comfortable there. First we stabilise it, then we explain it back to you in plain English, then you get to make an informed decision about its future.

• Taking over applications from departed developers or wound-up vendors
• Diagnosing intermittent faults, corruption and performance collapses
• Documenting what exists — often for the first time
• Ongoing maintenance, enhancements and small change requests
• Getting the code into source control and the deployment onto a repeatable footing

• Orphaned systems
• Diagnostics
• Documentation
• Source control
• Handover