Software should fit the organization. Usually it is the other way round.
Custom applications, database engineering, and systems integration — shaped to how your organization already works, and built with what you already run. On open technology, so the result is yours to host, change, and keep.
Built for the situation you actually have
No organization gets its process out of a manual. It is built from choices somebody made for a reason, from optimizations worked out by trial and kept because they held, and from requirements that were imposed from outside and had to be absorbed. Very little of it is arbitrary, even where the reason is no longer documented.
The software has grown the same way. Something bought for one purpose, something else written in-house, a third thing inherited in a reorganization, and connections added between them as they were needed. Each piece arrived to solve something.
New work does not enter a blank page or a reference architecture. It enters that arrangement, so we work to understand the processes and treat what we find as part of the specification. What comes out of that is a written account of why the process is the way it is, including the parts that are no longer documented. A statutory requirement, a filing deadline, an approval that has to come before the next step: constraints like those belong in that specification too, and the software is shaped to them. Working that closely also shows where a process could be more efficient, and we identify those opportunities as part of the same job. And where something genuinely blocks the job, we report it early rather than let it arrive late as a surprise.
A packaged product cannot tell which of that is essential and which is merely habit. It is built for the average of its market, and no organization is the average, so everything particular gets treated as deviation. Off-the-shelf software is often the right answer. It is just rarely a free one, and the part it costs does not appear on the quote.
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 licence, 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 licence 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
- Anything in the design has to be licensed, patched, backed up, monitored, upgraded, and staffed by someone who understands it. Complexity is not settled once at delivery. It is an operating cost with no end date.
- 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.
What you already run is an asset rather than an obstacle — the platforms you license, the applications that work fine, the staff who know how the current system got that way. The work is written to use them. Sometimes a product makes that impossible: a closed format, no way in, licence terms that forbid it. That is a finding, not an argument for replacing 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 licences, 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 path existed and would have worked. It was not necessary, and the cheaper answer is the one still running.
The line between building and buying has moved
For a long time the arithmetic favoured buying, and for good reason. Building the specific thing was slow and costly, while a licence was a known number on a known date. Anything custom had to clear a high bar before it was worth attempting.
That bar has come down. Current tooling — including AI assistance, used with the checks that make its output trustworthy — has cut the cost of building software that matches one particular organization. What it has not cut is the cost of contorting. That is still paid in workarounds, in duplicate entry, and in the person whose real job is bridging two systems, and it is paid every year the system runs.
So the comparison that used to settle the question — licence cost against build cost — is no longer the whole comparison. The better question is what fit is worth across the life of the system, and how much of the difference you are willing to absorb in the way people work. Where a product genuinely fits the work, buying it is still the right answer, and we will say so.
What looks chaotic is usually a routing problem
Organizations apologize for their own processes. There is a strange thing the numbering scheme does, a spreadsheet sitting in the middle of it, a step that exists because of something that happened in 2009. The apology is a reflex, and it is usually wrong. Much of that awkwardness is the business itself — the adaptation to a rule, or the part that has survived twenty years of contact with reality.
Not all of it, though, and the two kinds have to be told apart. Some of it is a workaround for a limitation that no longer exists, a reconciliation that survives only because two lists were never joined, or three people keeping partial copies of one record because no single place would hold it.
Telling one from the other is the first piece of work, and it is done by watching how the job is actually done rather than asking for an account of how it is supposed to go. The written version is always tidier than the real one, and the difference between them is where the problems live.
What usually emerges is that the process was never chaotic. It is a small number of real decisions with a great deal of manual routing between them — carrying, re-keying, checking, and chasing. Once the routing is the system's job, the decisions are what is left, and those are the parts that wanted a person all along.
Where a step turns out to be accidental, saying so plainly is part of the work. A reason that has lapsed means the step can go. Two lists that were never joined can be joined. A reconciliation that exists only to cover a gap stops being needed once the gap is closed. Sometimes a process is doing more work than the result requires, and the useful thing is to say so rather than quietly build around it. That comes as a recommendation with its cost attached; whether it is worth doing is your decision.
What we build
-
Custom application development
Web applications and internal tools, built end to end — interface, API, and database.
-
Database engineering
Schema design, query performance, and migrations that finish with the same data they started with.
-
Systems integration
Interfaces between systems that were never designed to exchange data: REST and XML services, scheduled transfers, and field-level mapping between schemas.
-
Legacy systems
Software that still runs the organization and is not going to be replaced this year. Keeping it in service, getting data in and out of it, and giving it interfaces to current systems — including running the original application under emulation when the platform it was written for no longer exists. Where replacement is the goal, it happens in stages, with parallel operation and reconciliation against the system of record while the work continues.
-
Reporting and automation
Scheduled data pipelines, generated documents, and operational dashboards.
-
Cryptographic engineering
Systems whose security properties have to be demonstrable rather than asserted: signed and verifiable exchange, client-side encryption, and key handling. Including migration to post-quantum signature schemes, which federal guidance has now put on a schedule.
-
Language-model systems
Getting structure out of text that never had any. Dates, obligations, entities, and classifications pulled from documents, correspondence, and regulatory prose, then turned into something a system can act on — a schedule, a queue, a ranked list of what matters first, a check that runs against a rule. With the evaluation harness and decision trail that make the output reviewable rather than merely impressive.
Open technology, and the result is yours
Given the choice, the firm builds on open-source foundations. That is a practical preference rather than an ideological one, and it comes down to what happens to your system over the years after it is delivered.
- Nothing can be withdrawn
- Products get discontinued, relicensed, and acquired. An open component cannot be taken away from you — the version you are running keeps working, on terms that cannot be revised later.
- 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 and the data model, hosted wherever you choose. Continuing with the firm should be a decision you make on the merits each time, not one the architecture already made for you.
None of this is a condition of working together. Plenty of organizations run on commercial platforms for good reasons, and have licences, staff, and policies already built around them. Where that is the case, the work is written to fit what you have — the recommendation is offered once, and then it is 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 the point rather than a list of services. Most engagements are ordinary application and data work, and the breadth is what makes unfamiliar territory a normal part of the job instead of a risk to be priced around.
Delivery is the small part. The systems we build tend to stay in service for years, so the real work is the migrations, schema changes, and regulatory updates that arrive afterward.
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.
Where correctness has to be demonstrable rather than asserted, it is built that way — behaviour checked against fixed expected results, and automated decisions recording what they did and why. How much of that a job warrants depends on the job.
Where the firm goes deepest
Some work rewards years spent in one subject. The firm's is regulated data — systems carrying federal schemas and statutory deadlines, where the reporting is the reason the system exists and it changes when the rules change. Drinking water is the deepest of those — SDWIS/State, the DW-SFTIES transition, and EPA reporting — and has its own page.
Firm details
- Entity
- Berryman Data Systems, LLC
- Form
- Limited liability company
- Jurisdiction
- Georgia
- NAICS
- 541511 — Custom Computer Programming Services
- Principal
- Randall Smith, sole member
- Phone
- (888) 288-4775
- 5665 Atlanta Hwy 9, Ste 102B, PMB 267
Alpharetta, GA 30004