Straight answers about working with Corply

Corply is a software and AI consultancy for manufacturers, recyclers, shippers, distributors and established family-owned businesses. We modernize legacy systems, build custom software, connect data between systems, and put practical AI to work in operations.

Corply, LLC is based in Saint George, Utah, and works with clients across the United States. Most work is remote, with on-site visits for floor walks, kickoffs and cutovers.

Email info@corply.ai or use the contact form. We will set up a 30-minute call to understand the problem. Most engagements then begin with a 2–3 week fixed-fee assessment that produces a written roadmap.

Usually not. Most of our work connects, extends or gradually replaces parts of what you already run. When a full replacement is the right call, we help you choose and implement it and migrate the data carefully.

No. We are paid only by the companies we work for, so our recommendations about platforms and vendors are not influenced by referral fees.

Assessments are a fixed fee and builds are scoped as fixed-scope or phased work, with an ongoing retainer for run and support. We do not publish prices because the right shape depends on document volume, systems and review needs. The assessment ends with a written scope you can take to anyone.

It is routed to a person before it can do harm. Every agent has confidence thresholds, a review queue that shows the source document next to the extracted values, and an audit trail of who approved what. We also measure error rates on your real documents before go-live, so you know what to expect.

The goal is to remove retyping and chasing, not to remove the people who understand the business. Staff move from keying data to reviewing exceptions, which is the part that needs judgment. We design the review step with the people who will use it.

No, we configure model providers so your documents are not used for training, and we tell you which providers touch which data. Where a document should never leave your network, we can run open models inside your own environment. You own the prompts, evaluation sets and code we build.

Build when your process is a real source of advantage or no package fits it, and buy when a product already does the job. We will tell you which applies during the assessment, and we are comfortable recommending a purchase. A common outcome is a package for the standard parts and custom tools around the edges.

You do. The source code, the data and the documentation are yours at delivery, held in repositories your company controls. We favor widely used, open technology so any competent developer or in-house team can take it over.

Yes, we design for it from the start when the site needs it. Offline-capable apps store work locally, queue changes and sync with conflict handling once the connection returns. We test in the actual yard or plant, not only at a desk.

Alongside them. We agree on hosting, identity, security review and support handoff at the start, and we include your IT people in design reviews and weekly demos. If you want them to own the system after launch, we plan the handover from the first week.

No, we avoid big-bang cutovers. The strangler approach moves one function at a time while the old system keeps running, and the two are reconciled in parallel. Switching a function over is a small, reversible step rather than a weekend gamble.

Yes. We read and document RPG, COBOL, VB6, FoxPro and Access applications, and we connect to IBM i data through standard drivers. If a piece of the old stack needs a specialist, we say so up front and bring one in.

It depends on how much of the logic is specific to your business. The assessment compares rewriting, buying and a hybrid against your actual processes and risks, and gives you a written recommendation. Often the answer is a package for the commodity functions and custom code for the rest.

That is the normal starting point. We recover the logic from the code, the data and the people who use the system every day, and we write it down as we go. You end up with documentation you never had, whichever path you choose.

A spreadsheet is enough until several systems must agree or someone spends days a month assembling reports. At that point a warehouse pays for itself in trust and time. For smaller operations we start with a single PostgreSQL database rather than an expensive platform.

We are tool-neutral and recommend whatever fits your team and licenses. If you already use Power BI or Tableau, we build there, and if you do not, we suggest an open option like Metabase. The data model underneath stays the same either way.

We measure it first, then fix it at the source where possible. Automated checks flag missing or impossible values daily and send each one to the person who owns the record. We do not hide bad data behind a polished dashboard.

You do. The warehouse runs in your cloud account or your data center, and the pipeline code, data models and dashboards are delivered to you with documentation. You can switch providers or take it in-house at any point.

Either works, and the right choice depends on your partners and volume. We can connect over AS2 or SFTP directly, or work through a VAN or EDI provider you already pay for. We recommend the simpler option during the assessment and explain the trade-offs.

We integrate with SAP, NetSuite, Epicor and Microsoft Dynamics, and with older systems through database or file interfaces. If your ERP has a supported API we use it. If it does not, we look for the least fragile alternative and tell you the risks.

Messages are queued and retried automatically, and anything that cannot be delivered lands in a visible exception queue with the original payload. Alerts go to whoever you choose. Under a retainer we monitor the flows and respond to incidents so your team does not have to.

Yes, in most cases. Modern indicators and PLCs expose data over Modbus, OPC UA, serial or Ethernet, and we put a small gateway on site to read it and forward it securely. Older or proprietary devices sometimes need extra hardware, and we confirm that on a site visit before committing.

No. Some workloads belong in the cloud, some belong on site, and some belong at the edge for speed or reliability. We recommend the split that fits your sites and risks, and we are happy to keep systems on premises when that is the better answer.

We are vendor-neutral and pick the platform that suits the workload, usually Cloudflare, AWS or Azure. If your company already has an enterprise agreement with one of them, that weighs heavily. We build with infrastructure as code so the setup is documented and portable.

We run the critical software on a small server or gateway at the site, so weighing, receiving and tablets keep working locally. Data is queued and synced when the connection returns. We design the failure mode with your operators and test it by pulling the cable.

We apply least-privilege access, multi-factor authentication, encryption at rest and in transit, patching and tested backups, and we document each control for your own reviews. We work within your security policies and alongside your IT team. Findings are written up plainly with a fix order.

A fractional CTO provides senior technology leadership for a fixed monthly commitment instead of a full-time salary. That means owning the roadmap, guiding vendor and build decisions, managing technology risk, and reporting to ownership. You get the judgment of an executive for the part of the week you need it.

A project ends with a deliverable, while advisory is an ongoing relationship. After the assessment we meet on a regular cadence and are available as questions come up. A common path is to start with an assessment and move to advisory once the roadmap is agreed.

Yes. We do not take referral fees or resell software, and we tell you when our own build services are not the right answer. If we recommend that we build something, we state that conflict plainly and you can take the specification to anyone.

Yes. We review the target's systems, data, security practices, licensing and key-person dependence, then write a short report with the risks and likely integration costs. Timelines are set by the deal, and we work under NDA with your deal team.

Usually yes. Most truck scale indicators expose weight over a serial or network connection, and we read it directly so no one types the number. Older indicators sometimes need a small gateway device, and we confirm what your scales support during the assessment.

Not necessarily. If your current system handles tickets and pricing well, we leave it in place and build around it: reports, a driver app, a buyer reconciliation tool or an integration to accounting. We recommend replacement only when the system is the actual bottleneck.

In narrow cases, yes, as a second opinion for a human grader rather than a replacement. It works best on clear categories with consistent camera angles and lighting, and it works poorly on heavily mixed material. We test it on your own photos in the assessment before anyone commits to building it.

We build reports from the ticket, inventory and shipment data you already record, so required records come out of daily work. We do not give legal advice or certify compliance, so your compliance lead still decides what each report must contain, and we build to that specification.

No. In most plants the ERP stays as the system of record, and we add a floor-facing layer that reads from it and writes back to it. A replacement only makes sense if the assessment shows the ERP itself cannot support the processes you need.

Often yes, though the method depends on the controller. Many can be read over industrial protocols such as OPC UA or Modbus, and machines with no network can use a simple sensor or signal tap. We survey what you have in the assessment and tell you plainly which machines are easy and which are not worth the effort.

Yes, for the repetitive parts: reading RFQ packages, extracting part details, finding similar past jobs and drafting a quote for an estimator to check. It does not replace estimator judgment on new or unusual work, and we build the review step into the workflow so the estimator stays in control.

We pilot on one line or cell during normal production, and run the old and new methods side by side until the floor trusts the new tool. Working software is shown to supervisors and operators every week, so changes come from the people using it.

Usually yes, through whatever the TMS offers: an API, EDI, database access or scheduled file exports. We check the options in the assessment and recommend the least fragile path. If the TMS has no workable integration point, we tell you before any build begins.

Yes. We build 204, 214 and 210 mappings for your trading partners, work with your EDI provider or run the translation ourselves, and monitor for failures. Each new partner spec is a defined piece of work, not an open-ended project.

Yes, in a draft-and-review setup. The system reads the request, pulls lane and rate history, and prepares a quote for a rep to approve. It works well on clear lane requests, and it hands off to a person when the request is ambiguous or unusual.

Yes. A portal can read shipment, document and invoice data from the TMS and present it to your customers with their own logins. The TMS stays the system of record, and the portal does not change how your team dispatches.

Yes, for most formats, with a person reviewing the exceptions. The system extracts the lines, matches them to your items and flags anything uncertain, such as an unknown part number or a price that differs from the contract. Clean orders go through, and the odd ones go to a short review queue.

No. The portal reads items, prices, availability and order history from your ERP and writes orders back to it. The ERP remains the system of record, and the portal is a front door for your customers.

We start by writing the rules down as they are actually applied, including the exceptions, then build them into a pricing service that quotes consistently across the counter, the portal and email orders. The first step is finding out how many versions of the rules exist today.

Often yes. Many accuracy problems come from receiving, putaway and counting practices rather than from the software. Scan-based workflows, cycle counting and discrepancy tracking on top of your current ERP can go a long way, and we recommend a WMS only when the layout or volume calls for one.

Not necessarily. Some systems should be wrapped and kept, some replaced in pieces, and some left alone. The assessment sorts your systems into those groups, based on risk, cost of change and what the business needs next.

That is common, and it is a good place to start. We work with that person to document how the system behaves and why, and capture it in writing and in tests. It reduces risk right away, whether or not you modernize anything afterward.

Yes. We map the systems at each company, set up a shared reporting layer first, and then decide which systems to consolidate and in what order. This works for single acquisitions and for roll-ups with many entities, and we work alongside your finance and IT teams.

Yes, if it continues to do its job. IBM i is stable and well supported, and we can connect it to modern web, mobile and reporting tools instead of replacing it. We help you plan around the real risks, such as hardware age, scarce RPG skills and undocumented programs.