Business application development
Engineering software development for technical and regulated work
Free consultationNDA on requestReply within one working day
Project documents
This week
Next
Trusted by global clients and organisations
The situation
When a spreadsheet is doing engineering work
Technical work often runs on tools built by an engineer years ago. They usually work. The risk is what happens when they do not, or when that engineer leaves.
- Calculations in a spreadsheet nobody has independently checked
- Results that cannot be traced back to the inputs that produced them
- Instrument or sensor output transcribed by hand
- Different versions of a model in circulation at the same time
- Approvals recorded in email rather than against the work
- A critical tool maintained by one person who wrote it
What it covers
What an engineering software build covers
Calculation and modelling
Domain logic implemented against a specification and tested against known cases, rather than transcribed from a working spreadsheet and hoped for.
Traceability
Inputs, versions, assumptions and results recorded together, so any output can be reconstructed later.
Instrument and data acquisition
Reading from equipment, sensors and files directly, removing the transcription step and the errors that come with it.
Validation and verification
Test suites covering the technical cases, including the edge conditions that matter in this domain.
Visualisation
Charts and outputs an engineer can actually interrogate rather than a dashboard designed for a boardroom.
Approval workflow
Review and sign-off recorded against the work itself instead of in a separate email thread.
How we work
How an engineering build runs
The specification does most of the work. We expect to spend real time with your engineers before writing code, because in this domain the requirement is the hard part.
- 01
Specify
Work with your specialists to write down what the software must do, including tolerances and the cases where it must refuse.
- 02
Prove the core
Build and validate the calculation or acquisition core first, against known results, before anything is built around it.
- 03
Build the application
Interfaces, storage, reporting and integration around a core that is already proven.
- 04
Verify and hand over
Test evidence, documentation and training, so the result can be defended to an auditor or a client.
Outcomes
What you are left with
- Calculations implemented against a written specification and tested
- Results traceable to inputs, versions and assumptions
- Instrument data captured directly rather than transcribed
- Domain knowledge documented instead of held by one person
- Evidence you can show an auditor or a client
- A tool the business owns and can continue to develop
Platforms and tooling
What we build with
Languages
- Python
- C#
- C++
- Java
- MATLAB interop
Technical
- NumPy
- SciPy
- Pandas
- Time-series stores
Interfaces
- React
- Desktop
- REST
- OPC UA
- MQTT
Named as platforms we work with, not as formal partnerships.
Questions we are usually asked
Not as well as you do, and we will not pretend otherwise. What we bring is the ability to turn your specialists' knowledge into software that is specified, tested and maintainable. Expect us to ask a great many questions and to write the answers down.
Yes, and the important part is proving equivalence. We validate the new implementation against known results from the old one before anything is switched over, so the change is demonstrable rather than a leap of faith.
Test evidence is produced as part of the build rather than assembled afterwards. If you work to a specific standard or qualification process, tell us at the start so the documentation is generated in the form you will actually need.
Usually. Direct acquisition from equipment, sensors and instrument files removes the transcription step, which is where a large share of technical data errors originate.
Engineering software often outlives the project that produced it, so it is documented and structured for another team to take on. We can also support it ourselves.
The methods and the code are yours. We work under NDA where you want one, and you receive the source and documentation.
Talk to us
Talk to someone who has built this
Not a salesperson working from a form. Tell us what the problem looks like and someone who has delivered this kind of work will come back to you, usually within one working day.
Tell us what you need
No obligation, and nothing is shared outside Geecon Global.
Not sure where to start?
Where this usually connects
Bespoke business applications
Software shaped around how you work, when nothing off the shelf fits.
Learn moreSoftware and hardware integration
Connecting devices, equipment and sensors to business systems.
Learn moreBespoke databases
For the operational data that has ended up in a spreadsheet.
Learn moreOperational systems
The systems that run the day-to-day work of the business.
Learn moreApplication development and maintenance
Building it, then keeping it running and current.
Learn moreBusiness analysis
Mapping how the work actually runs before anything is built.
Learn more