Most teams pick rod pump design software the same way they pick a restaurant in a new city: they ask someone who was there last and go with that. The last company used RODSTAR, so the new company uses RODSTAR. No evaluation. No comparison. Just inertia dressed up as a decision.
That works until it doesn't. You end up locked into a tool that doesn't match how your team actually operates, and the friction compounds quietly for years.
The questions that actually matter
Forget feature matrices. Every vendor has one and they all look impressive. The real questions are about how the tool fits your operation, not what it can theoretically do.
Where do your engineers sit?
One office, one hallway, everyone on the same network - desktop software is fine. The moment you have engineers in two offices, or people who work from the field, or a single remote team member, desktop tools create friction. License servers, VPN requirements, version mismatches. Every one of those is a reason someone opens a spreadsheet instead.
Cloud tools eliminate that problem entirely. Browser, login, done.
Do you run deviated wells?
This is where vendors get creative with pricing. Some include deviated well calculations in the base package. Others sell it as a separate module - sometimes at a price that rivals the core product itself. Ask upfront. If you run deviated wells now, or your portfolio is headed that direction, this isn't optional.
Beyond pricing, check how the tool actually handles directional surveys. Some do a surface-level approximation. Others model rod-tubing contact forces along the full wellbore path and adjust guide spacing accordingly. The difference shows up in rod failures.
Does your IT team have opinions?
They should, and you should ask early. SSO integration, role-based access, audit trails - these aren't nice-to-haves for most corporate IT departments. They're requirements. Desktop tools rarely support any of them. That means IT either makes an exception (they won't like it) or you spend months on workarounds.
If your company has gone through SOC 2 or similar compliance, the IT conversation will filter your options fast.
Are you an international operator?
Language support and native metric units narrow the field quickly. If your field engineers in Argentina or Oman aren't comfortable in English, a tool without multi-language support creates a training bottleneck that never goes away. Same with units - if reports generate in imperial and your regulatory submissions require metric, someone is converting by hand. That's where errors live.
Can you bring your existing work?
Your team's existing design files represent years of field-validated configurations. RODSTAR .rst files, SROD .inp files, whatever format you're in now - that library has real value. Before you commit to anything, verify the new tool can actually import those files with all parameters intact. Not "we support import" in a marketing sense. Actually import a file and check.
Also ask about export. If you can get data in but not out, that tells you everything about how the vendor views the relationship.
What most teams get wrong
They evaluate software based on a demo. A vendor walks through a polished example well, everything works perfectly, the interface looks clean, and the team is impressed. Then they buy it, try to use it on their own wells, and discover the experience is completely different.
Demos are marketing. They show the happy path. Your wells aren't the happy path.
The practical test
Pick one well you've already designed. One where you know the inputs, you know the output, and ideally you have field data confirming the design worked. Run that well through any tool you're evaluating.
Compare the results to what you already have. If the outputs match closely, good - the tool's physics engine is solid. If they differ significantly, ask the vendor why. The answer will tell you whether the tool is more or less rigorous than what you're using now.
Time the whole process. Not just the simulation run, but everything: creating the well, entering the deviation survey, setting up tubing and rod strings, running the calculation, reviewing the output. That total time is your real cost per design.
Then hand it to the least experienced engineer on your team without any guidance. If they can produce a reasonable design within an hour, the tool is intuitive. If they can't, factor training cost and ramp time into your decision.
The tool should match your workflow, not the other way around. If you find yourself rearranging how your team works to accommodate the software, you've picked the wrong software.
