Reservoir optimization MVP
An optimizer that worked but took a day to configure. The MVP was about making it demonstrable, not making it better.
An existing reservoir production optimizer required extensive manual configuration for every single simulation. The algorithm was not the problem. The problem was that nobody outside the team could run it.
Context
May to August 2025, through Sonat AS.
The MVP was a prototype application to streamline demo sessions and testing scenarios for stakeholders, cutting configuration time and presenting results more legibly. The purpose was commercial as much as technical: showcasing a new approach to optimizing reservoir production for potential customers and investors.
This is a familiar and underrated category of work. A capability that cannot be demonstrated is, commercially, a capability that does not exist.
My role
Solo architect and developer.
Key decisions
The requirements were decided before I got the assignment. Specific parts was wished for, but only parts of it should be delivered in this project
This MVP was full of configurations and running a blackbox algorithm based on those configs. In addition to displaying the results in real time.
Tradeoffs
It was a continuous pressure for having more and more functionality to this MVP to squeeze the money spent on this project. What started as MVP requirements slowly tried to translate to more. I was going to die on that hill because early on in the project i made a software development plan where I got the signoff on what to build and not.
Outcome
The outcome was a fully working MVP where the user could configure reservoir simulations and run them. The issue was that due to a language barrier between the scientist ordering this functionality and what was agreed on the requirements and signed off for, there was a gap. The reason for this gap was because early on, before I was involved some of the involved parties did talk about a bigger scope. However, that scope was cut and I managed to document it and got a signoff for it.
Lessons learned
Always have the agreement in paper and get a signoff so there is no ambiguity on what is promised for a delivery. Never trust scientists. C# · ASP.NET Core · NextJS