Who Should Build It?
Once a distributor decides a fragile process has to be replaced, the next question is who should build the replacement. There are usually four options on the table. You can take it to Epicor, hire a software firm, hand it to an in-house developer, or let someone on the team try it with an AI tool.
I have an obvious interest in this question, since I am a fifth option. So I will say up front that each of the four is sometimes the right call, and I will tell you when I think it is.
Before that, I want to talk about what happens when the first choice goes badly, because that is where most of the cost hides.
What a failed first attempt leaves behind
I have cleaned up after a lot of failed first attempts. The money that was spent is rarely the worst part.
Usually the team has become severely risk-averse. Once a project has failed in front of them, people cannot take even safe bets anymore. Every proposal has to show there is zero chance of failure. No project can show that, so good ideas get stuck right alongside the bad ones.
Often the data is damaged. I once followed a group that had tried to put orders into the ERP by inserting records directly into its database. It left a trail of carnage that was nearly impossible to clean up, and it had to be dealt with before any new work could be trusted.
Sometimes I have to give the client bad news about what they already paid for. More than once, I have been handed a partial project with a lot of time and money already in it. I have had to explain that building on it would cost more and be less reliable than starting over.
Whoever builds the second attempt starts with all of that. There is less trust and less budget, and sometimes the data has to be repaired first. That is why I think price and speed, the two things people usually compare, are the wrong place to start. I would start with three questions.
Question one: will it survive the move to cloud P21?
A few years ago, this question barely came up. Now it may be the most important one.
Epicor's final on-premises Prophet 21 release is 2028.1, and active on-premises support ends June 30, 2029. The way forward is Epicor's cloud, and the cloud does not allow a lot of what custom P21 work has been built on. You cannot write directly to the database, run scripts on the P21 server, or depend on a particular machine, folder, or service account.
That changes how the four options stack up.
Writing directly with SQL has always been the quickest way to get data into P21. An insert into oe_hdr and oe_line works the first day and looks great in a demo. But it skips the logic P21 runs when an order is saved through the application, and that is how you end up with the kind of cleanup I just described. It also will not run in the cloud. Plenty of in-house and firm-built integrations took that shortcut, usually for reasons that made sense at the time, and many of them now stand in the way of a migration.
AI tools are the most likely to take the shortcut today. If you give a model access to the database and ask it to create orders, it will write straight to the tables, because the schema is right in front of it and nothing tells it not to. It will work in testing and then break rules nobody thought to mention.
Epicor has a clear edge on this question, because what they build is designed around what their platform supports. Anyone else should be building on the P21 API, the standard import processes, and read access that works the same on-prem and in the cloud. If a proposal does not say which of those it uses, ask.
Question two: where do the business rules come from?
Every critical process in a distribution business runs on rules nobody wrote down. One customer needs the PO number on every invoice line, not just the header. One vendor's price file comes in a different unit of measure than the one you stock. One ship-to gets a manual adjustment every month, and nobody quite remembers why, but nobody wants to stop doing it either.
Writing the software is the easy part. Finding those rules is most of the project.
This is where the four options look very different from each other.
A software firm usually has capable developers who have never worked in P21 and have never run a distribution business. They learn both on your project. That learning tends to show up late, as questions asked after the design is already set. You can end up with software that is well built and still wrong for how you operate.
Epicor knows the product better than anyone. What they do not know is your customers, your vendors, or your billing partners, and a lot of the rules that matter live in those relationships rather than in P21.
An in-house developer who has been with you for years is often the strongest option here. They know the exceptions because they have lived through them.
AI fills in the gaps with guesses that sound reasonable. It will not stop to ask what should happen when the PO number is missing. It will just assume something.
Question three: who can run and change it in three years?
If a process works today but nobody can change it next year, you have just rebuilt the fragile process you were trying to get rid of.
In-house development tends to be weakest here, and I do not mean that as a knock on in-house developers. The problem is structural. One capable person builds something important, maintains it alone, and eventually moves on. What they knew goes with them, and you are left with the same key-person problem, only with newer code.
Firms have more continuity, though not always with the same people. The developer who understood your rules might be working for a different client next year.
Code written by an AI that nobody on staff understands has the same problem. There is nobody to ask, because the only thing that ever "knew" the code was a chat session.
Who builds it matters less here than how it gets built. The rules should live somewhere people can see them. The system should tell an operator exactly what is wrong when something is wrong. And more than one person should be trained to run it.
When the answer is not me
Someone independent who knows both P21 and distribution is the best fit when a project leans on all three questions at once. It has to survive the move to the cloud, it depends on rules nobody wrote down, and it matters enough that one person needs to be accountable for getting it right. It also helps when the project is substantial but has an end, and especially when a first attempt has already failed and the next one cannot afford to.
There are plenty of situations where I am not the right fit.
If what you need is close to standard P21 functionality, Epicor is often the better choice. A supported solution that keeps working through every upgrade has real value.
If you have years of steady development work ahead of you, rather than one or two projects, a good in-house developer is usually the better long-term investment. Just set standards that keep the work on supported interfaces and understandable by more than one person.
If the project is a large application that barely touches P21, like a broad customer-facing product, a firm has capacity that one person does not.
If the stakes are low, try the AI tool first. An internal report or a one-time analysis is a fine place to experiment. I would just keep it away from anything that moves money until someone has thought through how it can fail.
Before you sign anything
Whoever you pick, ask them three things before any work starts. How will this get data into P21, and will that still work in the cloud? How will you find the rules we have never written down? Who besides you will be able to run and change this after you are gone?
If you get good answers to all three, you are much less likely to need a second attempt.
If you are weighing these options for a specific process, or trying to decide what to do with a first attempt that stalled, request a call. I will tell you plainly which approach fits. If it is not me, I will say so.