Blog
Geologists drill wells and write readings into paper logs. Then they copy the numbers into a specialized program. Then they load device data into a second program. Then they manually copy tables from both programs into a third.
Three programs. All Windows-only. All manual. Every day, in the field.
This is the kind of problem that existed for decades without a custom software solution — not because no one saw it, but because no company would pay for something that specific. That changed.
Geoekoproekt runs geotechnical surveys. Their process before we touched it:
Every step is a handoff. Every handoff is a potential error. Every error requires going back to the original log to check. And all of this happens after the fieldwork, so mistakes discovered in the office mean calling the drilling crew for clarification.
The software existed. The process was just built around it rather than the other way around.
The redesign started with a simple question: what do these programs actually do?
After analyzing the workflows, the answer was: they convert device readings into standardized formats and output them as tables. That’s it. The “specialized” software wasn’t doing anything that couldn’t be replicated with enough domain knowledge and the right implementation.
Data entry — simplified.
Everything can now be entered on a tablet, phone, or laptop directly in the field. No paper log required. For situations where paper is unavoidable — the geologist photographs the completed log. The app reads the handwriting and fills in all fields automatically.
Device readings — automated.
The readings that used to require loading into a Windows program are now processed by the app. After running several dozen experiments to understand the conversion logic, the application learned to produce the same output. The geological domain knowledge needed to make this accurate is real — this was the part that took the most iteration.
Output — one step.
Instead of compiling from two programs, the final report is generated directly. The whole team works in the same cloud app. One data entry step. Finished report at the end.
This tool could have existed ten years ago. The underlying technology — databases, cloud apps, optical character recognition — was available. The reason it didn’t exist is simpler: no company would have paid for custom software to solve a problem this specific.
The economics of custom software development require either a large addressable market (build once, sell to many) or a client large enough to justify the full cost. A custom geotechnical field tool for one company’s specific Windows programs is neither.
What changed: we built this folded into our regular monthly engagement with the client. The development time was low enough that it became viable as part of an ongoing relationship rather than a standalone project. AI-native development compresses the time to build something specific from months to weeks.
The result is a tool that solves an exact problem for this exact client’s workflow — something that would have been economically impossible five years ago.
The geotechnical project is representative of a category of automation that’s now opening up:
Highly specific, niche workflows that don’t fit general SaaS tools and weren’t economically viable as custom projects. Field data collection for specialized industries. Internal process tools for companies with unusual requirements. Integrations with legacy systems that predate modern APIs.
These problems have always been real. The constraint has always been cost. AI-native development changes that constraint.
If you have a process like this — specific enough that no off-the-shelf tool handles it, but specific enough that you can describe exactly what you need — it’s probably buildable now. Get in touch and we’ll tell you how we’d approach it.
Related: What is an AI-native web studio · n8n vs Claude Skills
ilf.studio — custom AI automation and web development. Gdansk, Poland.