Algorithm Development - Novel algorithms, from research to production

I build algorithms when off-the-shelf tools do not solve the problem. Sensor fusion, computer vision, Bayesian inference, time-series and geospatial modelling. The work goes through the math, the algorithm, the C or Python that runs it, the cloud or embedded system it lives on, and the product around it. One senior person owning the whole technical problem instead of three specialists who cannot talk to each other.

Where this fits

This work suits problems where research has to meet production reality. Hardware constraints, novel algorithm requirements, models that work on a laptop but break under load. If a standard ML library or a general-purpose consultant has already failed, that is usually the right starting point.

  • Research depth. PhD in Automatic Control, 16 peer-reviewed publications, 500+ citations. I read the papers and I have written some of them. The algorithm choices are made on substance, not familiarity.
  • Production reality. Embedded C on Nvidia Jetson and microcontroller targets. Serverless GCP for GenAI workloads. Two GCP professional certifications (ML Engineer, Data Engineer). The algorithm has to ship, not just demo.
  • Senior, not staffed. I work as one person on a small number of clients. No junior layer, no handover problems, no margin for translation loss between research and engineering.

Understanding and planning

Most algorithm projects fail in the first two weeks because the problem is wrong, not because the model is wrong. Before any code, I work to understand what success actually looks like, what data exists and what it cannot tell you, and what the deployment target imposes on the algorithm choice.

  • Defining success: What is the metric that matters to the business, not just to the model. What level of performance triggers a decision to ship or to stop. What edge cases would make the system unsafe or unusable.
  • Data audit: What data is available, how clean it is, what is missing. Whether new data collection is needed before anything else makes sense. Whether the dataset can support the kind of model the problem suggests.
  • Infrastructure and constraints: Where the algorithm runs (cloud, edge, embedded), what compute and latency budgets it has, what dependencies it can carry. These constraints decide more than people expect.

The output of this phase is a clear written scope: what is being built, what defines done, and what the realistic risks are. If the project should not happen at all, this is when I will say so.

Included in this phase

  • Stakeholder interviews
  • Data audit
  • Algorithm survey
  • Infrastructure review
  • Scope definition

Prototyping and iterative development

With the scope defined, I build the algorithm in Python or MATLAB, iterating against real data. The aim of this phase is not a finished product but a working prototype that proves the approach is right and exposes what production will actually need.

  • Data preparation: ETL, feature engineering, labelling strategy where needed. Often half the work. Production performance lives or dies here.
  • Iterative model building: Multiple candidate approaches, evaluated against the success metric from phase 01. Bias toward the simplest model that meets the bar, with the option to go deeper when it does not.
  • Fit-for-purpose design: Models chosen for the actual deployment target, not for what is fashionable. A small XGBoost that runs on the embedded board often beats a transformer that does not.

Included in this phase

  • Data preparation
  • Feature engineering
  • Iterative evaluation
  • Model selection
  • Edge case analysis
  • Python
  • MATLAB

Production deployment and handover

The prototype becomes a deployed system. Embedded C generated from MATLAB and integrated into a real codebase, or a serverless cloud architecture with the appropriate CI/CD around it. By the end of this phase the algorithm is running where it needs to run, with monitoring in place and documentation good enough for someone else to maintain.

  • Robust productionalisation: Code generation, integration with existing systems, performance optimisation against real constraints. C and C++ when needed, Python and Go for cloud workloads.
  • Monitoring and documentation: Enough instrumentation to know when the system drifts. Documentation written for the team that will own it after I leave.
  • Handover: I am not the long-term operator. The phase ends when your team can run, monitor, and modify the system without me.

Included in this phase

  • Code generation and integration
  • Performance optimisation
  • Monitoring
  • Handover
  • Embedded C
  • GCP

Let's Talk

Tell me about the problem. I will say if there is a fit.

Say Hej