How we choose — Berryman Data Systems, LLC

Step 1: Understanding the problem and how you work

Before we recommend anything or write any code, we learn the problem and what you already have: how the work is done now, what systems are in place, and what your people are good at. Those set the terms any solution has to meet. Knowing them keeps the answer aimed at what you asked for, not at what would be interesting to build.

How the work is done means how it is actually done, not how the procedure manual describes it: the real order of the steps, who checks what, and which exceptions get handled differently and why. Most of it has never been fully written down, and none of it can be guessed from outside.

Software chosen without that knowledge carries costs nobody sees when the decision is made. They show up after the contract is signed.

Product demonstrations make this worse. A demo shows what the software can do. It can't show what the software has no place for, and only someone who knows the work in detail will spot those gaps. That person is often not in the room.

The gaps get filled with workarounds, and they come in two kinds. Some live in the software: heavy customization to approximate what you need, or a second product bought to cover what the first won't do. Others live in the organization, where people change how they work to suit the software. Both cost money every year, and neither showed up in the evaluation.

Understanding the work first avoids both. It also turns up effort that is being spent for no result, which is worth knowing whatever gets built afterward, or whether anything does.

The best tool for the job is not always the best solution in your situation

Off-the-shelf software is often the right answer. It is rarely as cheap as the quote. Below is what we weigh when deciding, laid out so you can check the reasoning and tell us where you know something we don't.

Commercial off-the-shelf software never fits perfectly, and the gap is not in the price

Fitting the product to you is a project of its own: Configuration, data migration, and mapping your fields onto its fields. Then the meetings where somebody decides which of your practices to drop, because the product has nowhere to put them. That work is quoted separately from the license, or not quoted at all. Either way your own staff absorb it.
The workarounds do not go away: Workarounds harden into policy. A spreadsheet appears to hold the fields the product would not accept. The same figures get entered twice, and eventually somebody's real job is being the bridge between two systems. None of that is in the license cost, and all of it is paid every year.
It is easier to install than to leave: A product that only partly fits can be lived with, and after ten years the process has formed around it. Getting out then is a project of its own, usually larger than the one that installed it.

What gets built should be no larger than the job needs

The right tool is the one the load calls for: A relational database earns its cost when the schema is complicated, many people write at once, and the figures have to agree. Where that is not the situation, a simpler store does the job and keeps doing it.
Unnecessary layers are paid for annually: Every part of a design has to be patched, backed up, monitored, upgraded, and looked after by someone who understands it. Every extra piece costs money for as long as the system runs.
Right-sizing can be undone; over-building cannot: A modest store can be grown into a full database if the load ever justifies it. Going the other way means unpicking a design that everything else has since been built on.
Licensing terms shape the design: Per-processor or per-user pricing decides how many people can use the system and where it can run. That limits the design as firmly as any technical constraint, for as long as the system is in service.

We design around what you already have. Sometimes a product makes that impossible: a closed format, no way to get the data out, license terms that forbid it. When that happens we'll tell you, and it still isn't a reason to replace everything.

Two examples

A filing problem across scattered regional offices looked like it needed a document management system. It was solved with the digital copiers already standing in those offices and a naming convention — no new hardware, no new licenses, and nothing for staff to learn beyond what they already did with a copier.

Laboratory results arriving in a dozen shapes from a dozen instruments and software packages looked like a dozen integration projects. It became a set of parsers that read what the laboratories already produced — no direct integration with any instrument, no per-vendor expertise to maintain, and nothing for the laboratories to change.

In both cases the expensive option would have worked. It wasn't needed, and the cheaper solution is still in use.

The line between building and buying has moved

For a long time the arithmetic favored buying, and for good reason. Building software for one organization was slow and costly, while a license was a known number on a known date. Anything custom had to clear a high bar before it was worth attempting.

That has changed. Modern tools, AI among them, have made it much cheaper to build software for one organization's needs. They haven't made it any cheaper to contort an organization to fit software that doesn't. That cost is still paid in workarounds and duplicate entry, every year the system runs.

So comparing license cost with build cost no longer settles the question. The better question is what a good fit is worth over the life of the system. Where a product genuinely fits the work, buying it is still the right answer, and we'll say so.

Open technology, and the result is yours

When we have the choice, we build on open source. The reason is practical: it's about what happens to your system in the years after delivery.

Nothing can be withdrawn: Products get discontinued, relicensed, and acquired. The open version you are running keeps working under the license you received it with, whatever happens to later versions.
Cost does not follow success: No per-seat, per-core, or per-record licensing, so adding users or seeing the system succeed does not increase what you pay to keep it running.
It can be inspected: Every layer is open to reading. For work that gets audited, that is the difference between showing how something is determined and pointing at a closed component.
You can hire from anywhere: Widely used tools mean a large pool of people who can maintain it, rather than a short list of certified partners.
Leaving stays possible: You get the source code and the data model, hosted wherever you choose. If you keep working with us, it should be because you want to, not because the system makes it hard to leave.

You don't have to use open source to work with us. Many organizations run on commercial platforms for good reasons, with licenses, staff, and policies built around them. In that case we build for what you have. We'll make the recommendation once, and after that it's your call.

Made to be inherited

The firm's principal has spent more than twenty-five years building and maintaining production systems. A long run of that has been for public agencies, alongside microcontroller and embedded work, distributed infrastructure, cryptographic protocol design, and applied machine learning.

That range is not a list of services. Most engagements are ordinary application and data work.

Most of a system's life comes after delivery: migrations, schema changes, new regulations. We build for that.

We document the data model, write for whoever inherits the code, and keep the system operable by people who did not build it. Clients work directly with the engineer doing the work.

When results have to be demonstrably correct, we build the evidence in: automated checks against known answers, and a record of what each automated decision did and why. How much of that a job needs depends on the job.

How we choose, and why ownership matters