Case studies
The software work behind everyday operations.
Getting an order into the warehouse. Turning a quote into production paperwork. Changing software that staff already depend on. These anonymised case studies explain the operational problem, the constraints that mattered, what changed and the practical result, with client identities kept private.
01 / Existing application support
Supporting a .NET application used for stock, sales and invoicing.
- Working environment
- An established business application managed stock, sales, invoicing, contracts and reporting. Staff used its Windows and web interfaces for daily operational work.
- Technology involved
- WinForms, ASP.NET, SQL Server
The operational problem
The application still served the business, but production faults interrupted work and some workflows needed new functionality. Those issues needed to be addressed within the system staff were already using.
The constraint
The application code and SQL Server database contained business rules shared across multiple workflows. A change to one area had to account for how the same data was used elsewhere rather than treating each screen or fault in isolation.
The approach
I investigated issues across the application and database, corrected faults and developed workflow improvements within the existing Windows and web application. The work covered both the application code and the operational data behind it.
The practical result
Staff could continue using the established stock, sales, invoicing and contract workflows while faults were fixed and functionality extended. The useful system stayed in service rather than being replaced simply to accommodate those changes.
02 / Systems integration
Moving ecommerce orders into warehouse systems with validation and visible failures.
- Working environment
- External order platforms feeding internal warehouse operations. Order, customer and product records needed to arrive in a form the operational systems could accept and use.
- Technology involved
- REST APIs, XML, CSV, SQL Server
The operational problem
Order, customer and product information had to move from external platforms into internal warehouse systems. Repeated manual handling and mismatched records added work before the operation could use the information.
The constraint
The systems used different formats and data rules. Each record needed to be mapped and validated before it could be accepted, and a failed transfer had to remain visible for investigation.
The approach
I built workflows that retrieve records through the interfaces each system supports, including APIs and file transfers. The integration maps and validates the incoming data before passing accepted records into the appropriate internal systems.
- External orders, customers and products
- Mapping and validation
- Internal warehouse systems
The practical result
Validated orders and related records could enter the operational systems without being recreated manually. Failed transfers remained available for investigation rather than disappearing from view.
03 / Custom business software
Replacing spreadsheet quoting with an application that carried job data into production.
- Working environment
- A business quoting custom work, where pricing depended on the details of each job. Customer and job information was needed for both the quote and the paperwork used in production.
- Technology involved
- .NET, SQL Server, Reporting
The operational problem
Staff prepared detailed quotes in spreadsheets while prices, customer details and job requirements varied from case to case. The pricing logic was difficult to control and easy to misread, while production needed the same job information in its paperwork.
The constraint
Replacing the spreadsheet meant preserving the pricing rules behind it. The application also needed to carry the correct details from the quote into production documents so both parts of the job could use the same information.
The approach
I built a .NET application backed by SQL Server that combined pricing calculations, customer details, quote generation and production documentation. The rules and data became part of the application rather than remaining spread across spreadsheet work.
The practical result
Staff could produce quotes and production paperwork from the same underlying customer and job data. Pricing calculations and document generation became one connected workflow.
04 / Application modernisation
Changing ASP.NET hosting and deployment without rewriting the application.
- Working environment
- Existing ASP.NET web applications and SQL Server databases running in an IIS hosting environment. The application remained in use while its hosting and deployment arrangements needed attention.
- Technology involved
- ASP.NET, SQL Server, IIS, Azure
The operational problem
Older hosting, performance constraints and unclear deployment steps made the application harder to support and change. The environment it ran in had become part of the risk.
The constraint
The application needed to be retained. Moving the hosting was only part of the work; its behaviour and database connections also needed to be checked in the changed environment.
The approach
I reviewed the application and database environments, carried out the Azure hosting and deployment work, and checked the application after the changes. Production troubleshooting formed part of validating the transition.
The practical result
The hosting and deployment setup was updated while the existing application remained in service. Validation covered how the application behaved in the changed environment rather than treating a completed deployment as proof that everything worked.
Discuss the work
Does some of this sound familiar?
Tell me what the existing application, data flow or operational process does today, who relies on it and where it needs to work better. I’ll review the context and let you know whether I can help.