Well Drilling Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a drilling build get scoped as a scheduler?

Because scheduling is the pain everybody can describe. Ask an owner what is broken and he tells you about the morning the rig went to the wrong county, not about the completion reports riding around in a truck door pocket. So the brief becomes dispatch and calendars, the demos all show a board, and six months later the paperwork problem is exactly where it was.

The paperwork is the money in this trade, and it is not a paperwork problem in the sense of being administrative. It repeats on every job. A hand written carbon copy form degrades in a truck, gets deciphered weeks later, gets re-keyed into a state portal, and one of them gets filed late. Meanwhile the permit for the next subdivision job is in a different pile and nobody is completely certain it cleared. None of that is fixed by a nicer calendar.

The fix is to scope the first release around the regulated record. A mobile completion log whose fields match your state's report exactly, captured at the wellhead, syncing to the office in real time, with a permit tracker showing which jobs still owe a filing and which have cleared. Dispatch is phase two. It is genuinely better as phase two, because a schedule that knows a well cannot be drilled until its permit clears is more useful than a schedule that does not, and that gating requires the permit tracker to exist first.

What goes wrong migrating a decade of jobs and paper well records?

Two datasets, two different problems. The customer relationship system export is structured and reasonably clean, and it will migrate without drama. The paper is where the value and the difficulty both sit, because a decade of drilling history is the asset that lets you find every pump approaching the end of its service life and every well due for inspection.

The traps are consistent. Addresses do not match, because a rural job recorded as a road name and a landmark in 2015 sits at a numbered address now, and the same property appears three different ways across jobs. Wells are recorded against a customer rather than against a property, so when the house sells, the well history follows the wrong person. Depths, casing sizes and yields exist on the paper log and nowhere digital, so any analysis of aquifer trends or pump age has to start with transcription. And equipment installed is frequently a line item on an invoice rather than an asset record, meaning you know a pump was sold but not which model went where.

The fix is to migrate in two passes. Bring the digital records across first so the system is usable within weeks, then run a transcription pass on paper logs that prioritises the wells most likely to generate work, meaning the ones with pumps approaching typical service life. Model the well against the property rather than the customer from the start, since properties change hands and wells do not move. Accept that some history will be marked unknown and give crews a one tap way to complete it on their next visit.

Why do state portal and existing system integrations break after launch?

State portals are the fragile piece and they are fragile for a structural reason: none of them shares a standard with any other, and each one changes on its own schedule with no obligation to warn you. California's Online System for Well Completion Reports, the Texas well report system and Minnesota's Minnesota Permitting and Reporting System are three different formats with three different field sets and three different submission behaviours. A build that pre-fills all three is maintaining three separate mappings, and when one state adds a required field, that mapping silently produces an incomplete submission until somebody notices.

The existing platform integration fails more mundanely. If jobs can be created in the platform while the new system also creates them, you get duplicates, and duplicate jobs in this trade mean a well recorded twice with two partial logs. Job completion triggers break when crews change how they close work, which they do whenever the office asks them something new.

The fix is to keep a human in the submission loop deliberately rather than as a limitation. The system pre-fills, a person reviews and submits, and the review is where a changed field gets caught. Add a pre-submission completeness check per state so a missing required field blocks rather than passes. On the platform side, name one authority for job creation and instrument the boundary with a daily count of jobs completed against logs captured, because every failure here eventually shows up as work done with no filing behind it.

What happens when permit gating and offline capture are not covered?

Permit gating is the cheapest feature in this category and it is skipped constantly. A rig rolling to a job whose permit has not cleared is an expensive mistake in fuel, daylight and credibility, and it happens because permit status lives in a pile on a desk rather than as a state on the job. Making permit approval a precondition the scheduler enforces costs very little and prevents a category of error entirely.

Offline capture is the one that decides whether crews use the software at all. Wells get drilled where signal does not reach. If the log form requires a connection, the driller fills it in badly, later, from memory, or reverts to the carbon copy pad, and you have paid for a system that produces worse data than the paper it replaced. The subtle part is conflict: a driller who captures two logs offline while the office edits the same jobs creates two versions of the day, and a build with no explicit resolution strategy will pick one silently.

The fix is to require offline first as a stated requirement with a described conflict behaviour, and to test it in the field before rollout rather than in an office with the wireless turned off. Make permit status a job state with the scheduler enforcing it. Both are inexpensive and both prevent failures that no amount of later feature work can undo.

Should you build custom or configure what you already own?

If your pain is genuinely scheduling, invoicing and dispatch, and the drilling paperwork is manageable at your volume, ServiceTitan, Jobber or Housecall Pro is enough and a custom build is the wrong spend. Those products are good at what they were built for, and a shop running one or two rigs with a single state's filing requirements can keep a paper process honestly without it costing much.

They stop at the regulated record. None of them knows what a static water level is, none maps to your state's well report fields, and none will pre-fill a completion report, because they were built for trades whose paperwork ends at the invoice. That is not a criticism of the products, it is a description of their scope.

The signals that justify building are specific. Somebody spends hours a week re-keying well logs into a state portal. You file into more than one state, so the translation work multiplies. Estimates go cold because the office is buried in logs and nobody follows up. You have years of history you have never once queried for pump replacements or inspection due dates. When two or three of those hold, the platform is no longer the bottleneck and the manual work around it is.

The position we take with drilling clients is to layer onto the platform you already run rather than replace it. Keep dispatch and invoicing where they work, add the mobile log, the permit tracker and the filing path through the platform's interface, and only replace the platform if the platform itself is what is failing.

How do hidden costs get into the quote?

The mobile form is the visible cost. These are the ones that arrive later.

• Each state portal. Every state is its own field mapping, its own completeness rules and its own ongoing maintenance when the format changes. Two states is not slightly more work than one.
• Paper transcription. Turning a decade of hand written logs into queryable records is operational time, and it should be prioritised rather than attempted wholesale.
• Offline sync. Building it properly with conflict resolution is real engineering, and it is not optional in this trade.
• Address and property reconciliation. Rural records described by landmark rather than address need human judgement to consolidate.
• Field testing. The app has to be proven at a real wellhead with real gloves and real signal conditions before rollout, and that is time on a rig.
• Portal maintenance. Somebody has to update a mapping when a state changes a form, within days. Price that arrangement before you need it.

Ask for these separately. A single line reading state filing integration will be revised.

What separates a build that works from one that fails here?

Make a prospective developer prove they understand a well completion report before you sign. If they have never heard of a static water level or a pitless adapter and cannot name the portal you file into, they will build a good looking scheduler that does not touch the paperwork, which was the entire point of the project.

Second, insist they work against your existing data rather than starting from a blank slate. A serious developer asks to see your platform export in the first meeting, because your service history is the asset and the whole case for mining it depends on migrating it intact.

Third, ship the piece that stops the biggest daily leak first and prove it on real jobs. For most drilling companies that is the mobile completion log and the permit tracker, because both produce visible results in weeks and both remove work that repeats on every single job. Building outward from a working first release keeps the project honest and keeps the crews on side, which matters more here than in most trades because a field app that annoys a driller gets abandoned quietly.

Fourth, confirm you own the code and the data outright, with the repository handed over. You are buying an asset rather than renting another subscription, and your well records are regulated documents that may need producing years later. The contract should say so before kickoff, not after final payment.