Software built for how you actually run.

Your ERP won't do the thing. The vendor quoted a number with a comma in it, or said the feature is on a roadmap. Somebody is doing the work by hand in the meantime and it's eating a day a week. So you start looking for someone to build something.

Before you pay anybody, check which of three things you're actually looking at. Only one of them is really a build.

Three levels, and most operations need the first two

• Configure what you already own. A surprising amount of what gets quoted as development already exists in a module nobody switched on, or in a report nobody wrote. It's free, so rule it out first.
• Set up AI around the work, with your own knowledge in it. This handles a whole category that used to require building: reading documents, drafting responses, answering questions that were answered before, pulling information out of things nobody wants to read. If the task is mostly reading, retrieving and drafting, this is usually the right level and it's a fraction of the cost of a build.
• Build the piece that has to be exact, or has to run on its own. This is the level you probably came here looking for. It's the right answer when the work must produce the same result every time, or must happen without anybody triggering it, or has to reach into two systems and reconcile them.

I'll tell you which level you need, including when the answer is that you don't need me to build anything. That's what makes it mean something when I do say something's worth building. And if the reason you're here is that you can't fill a role and the work still has to get done, start with you can't hire your way out of this one.

What genuinely does need building

The work that's actually paid for itself in the operations I've worked with looks like this:

• Anything that has to cross a boundary between two systems. The ERP and the accounting package. The mailbox and the ERP. This is where the expensive problems live, because no single vendor owns the space between their product and someone else's.
• Work that has to happen whether or not somebody remembers. Checking that vendor confirmations came back and match. Watching for the order that was never acknowledged. A person can do this and a person will, right up until the week they're busy.
• Reading and checking documents at volume. Customer POs against quotes, requests against history.
• Assembling a number that lives in three places. Which is most of what people mean when they say they can't get a straight answer out of their systems.

What doesn't need building, most of the time: another dashboard, a replacement for a system that basically works, or a general purpose platform to solve a specific irritation.

What to ask whoever you hire, including me

Ask these no matter who you hire. They separate the people who finish from the people who leave you with something half-built and a login that doesn't work:

• "What happens when it breaks at 6am on a Tuesday?" Software that touches a daily operation will fail at some point. Who notices, who fixes it, and is that arrangement written down or assumed.
• "Do you know what a traveler is? A first article? An acknowledgment?" If the answer needs explaining, you're paying to educate somebody about your industry, and you'll pay for it in rework rather than on the invoice.
• "Is this a fixed price or an hourly meter?" An hourly arrangement transfers all the risk of a bad estimate onto you.
• "What does it read, and does it ever write back?" Anything writing into your ERP deserves a much harder conversation than anything only reading from it.
• "What happens if I stop working with you?" Ask it early. The answer tells you a great deal, and you want to hear it before you're committed rather than after.

How I work, plainly

I spent my career in manufacturing, including a decade running a machine shop, and I now build and run software for manufacturers. The order matters. Most people offering this understand software or they understand your operation, rarely both, and the gap between the two is where these projects fail.

It starts with a paid Diagnostic, which is a short scoped piece of work where I look at how the thing actually runs today and decide what's worth doing, including whether anything is. You get a written scope with pricing for whatever earns its place. Then a Build quoted up front, so you know the number before it starts. No hourly billing.

I host it and keep it running on managed infrastructure, working on top of the systems you already run, so nothing moves to a new platform. There's an ongoing care plan after that covering hosting, monitoring, fixes and small adjustments as your operation changes, with term and price by agreement. That ongoing cost is real and I would rather name it here than surprise you with it later.

Common questions

Do you replace our ERP?

No, and I would push back hard on anyone suggesting it as a first move. Your ERP stays the system of record. What I build reads from it, and writes back only where you specifically want that.

How big does a company need to be for this?

Smaller than most people assume. The AI setup level has no real floor. For a build, the question isn't headcount, it's whether there's a specific recurring cost you can point at. One person spending a day a week on something is a real number, and it's already being paid, just not on an invoice.

Can we start small?

You should. One annoying problem, scoped and priced on its own, is the right way in. It tells you whether working together is any good long before either of us is committed to anything large.

What if we already have someone in-house?

Then you may not need me, and I'll say so. Where it usually still makes sense is when the in-house person is covering IT and infrastructure rather than writing software against your ERP, which are genuinely different jobs.

Where this usually starts. Most of the work that gets commissioned begins as one of these: vendor PO acknowledgements slipping through, customer orders keyed in by hand, numbers you can't get on one page, or reports the ERP won't give you. If you aren't sure you need an ERP at all yet, start with running on QuickBooks and spreadsheets.