Two years on one product, four days on another: why we build our own software

Peich Technologies sells websites and web operations on a subscription. That is the business. Alongside it we build and run three pieces of software that have nothing to do with any of that: ForgeMRP, a production planning system for machine shops, Caribooks, a connector between QuickBooks and an AI assistant, and Type Parts, a parametric CAD part generator.

The question comes up often enough to deserve a written answer. Why does an agency that bills for websites spend its time on products nobody asked it for?

The short version is that an agency, structurally, stops learning at the invoice. And a product you run yourself is the only mechanism we have found for carrying on.

The short answer, for the busy

A web development agency is judged on delivery day. That is when it gets paid, so that is what it optimizes for. If the architecture it picked was wrong, the client is the one who finds out in month eight. Building and running your own software closes that loop: you pay the hosting bill, you answer the support email, you watch a signup die at the OAuth consent screen. At Peich Technologies three products play that role. ForgeMRP, a production planning system, has been running for two years and teaches what software becomes once real data piles up inside it. Caribooks and Type Parts were built in a matter of days, as tests. The gap between those two timelines is not a question of talent. It is the skill a client is actually buying: recognizing in advance which of the two categories a project falls into.

An agency stops learning at the invoice

Look at the incentives without flinching. An agency is judged on what is visible the day the site goes live: the design, the demo, the handoff. That is when it gets paid, and that is when the verdict sets. Nothing in that structure pushes it to care about month eight.

The client cares. But the client has no way to connect what they are living through to the choice that caused it. A form breaks, the site gets slow, an update takes a page down. They see the symptom and never the architecture decision made eighteen months earlier by someone who has moved on. That is how a properly delivered site ends up quietly rotting.

An agency can run for years without ever receiving that feedback. It produces, it delivers, it invoices, and it starts again with the same reflexes. Nobody here is being negligent. The feedback loop simply is not there.

Running your own product rebuilds that loop by force. We pay the Caribooks hosting bill every month. We answer the email asking why the QuickBooks connection expired. Every irritation of that kind is a decision made one afternoon that we are now attached to.

What two years on the same system teach

ForgeMRP is the long case. The project is two years old and already on its second repository: the first was abandoned after a large migration, and its replacement carries 4,200 changes since the summer of 2025. It handles production planning: quotes, jobs, work orders, purchasing, outside operations. A dense domain, users with real data in it. We got to start again from a clean repository; we never got to start again from clean data.

Two things found inside that system in April 2026 say more than any statement of values.

The model in the code drifts away from the model in the data. The hand-written `WorkOrderStatus` type declared nine possible states for a work order. The matching database enum held five. Counting the actual rows in production turned up exactly those five, and zero rows carrying any of the other six. Interface components had therefore been handling states, for months, that had never existed anywhere but in someone's head. The decision was to narrow the code down to the database rather than the reverse, and let the compiler find the rest.

A living system accumulates things nobody uses. A schema audit surfaced eight objects with no reference anywhere in the code: views superseded before multi-tenancy even arrived, a column holding sixteen rows of data that no screen ever let anyone enter. You do not find that by reading code. You find it by crossing what is referenced against what actually holds data.

There is a third lesson, less dramatic and more useful. The repository carries a glossary that pins down the vocabulary of the domain, with a list of words to avoid for each term. A Job is not a Work Order, an Operation is not a Process. It can read as fussiness. Two years in, it is infrastructure: when the words blur, the schema blurs, and the screens follow.

None of those three lessons arrives in a project that is delivered and handed over. They require staying attached to the system while real data piles up inside it.

What a few days teach

Caribooks and Type Parts are the other extreme. Caribooks went from an idea to a live product taking payments, at caribooks.com, inside a single working day. Type Parts was built in four days, from 3 to 6 September 2026.

The lesson is not the obvious one. We had been estimating the wrong thing.

When we stood Caribooks up, the design and development work was not what set the launch date. What set it was the run of steps that require a human or a third party to act: an OAuth consent screen to get approved, a DNS propagation, a payment account detail, a form to fill in at a supplier. Each one is short. Strung together and dependent on each other, they are the calendar.

Since then, when a client asks how long something will take, we stop counting features. We count gates: who has to click what, which external approval is needed, how many times we will be waiting on an answer that is not ours to give. The answer is usually more honest, and occasionally less pleasant to hear.

Knowing which of the two you are looking at

A four-day project and a two-year project are not told apart by their requirements. They are told apart by what happens when you get it wrong. Type Parts gets it wrong and we rebuild it: no users with data to preserve, no history, nothing downstream that breaks. ForgeMRP gets it wrong and a machine shop schedules its production against false information.

The expensive part of software is not writing it. It is being wrong in production, with real data and real users sitting on top. That cost has not come down, and it is what separates the two timelines.

The practical consequence states easily. Facing a project in the first category, the right answer is to build the thing for real and put it in front of someone, instead of running three months of validation interviews. Facing one in the second, caution is entirely warranted again: migrate in stages, keep a way back, never replace a system in service overnight.

Getting the category wrong is expensive in both directions. Treating a test like a critical system costs months. Treating a critical system like a test costs data.

What it changes for your project

Three things we do differently because of these products.

We estimate in gates, not features. The timelines we quote count the approvals, the accesses and the third parties we depend on, because that is what will actually set the date.

We stay attached to what we ship. That is the underlying reason for our subscription model rather than a project fee. If the real cost sits after launch, the commercial structure has to sit there too.

We say when a project is a test. Type Parts is four days old as this is written and it may well not exist in a year. That is the project's category, and saying so up front beats billing a test at the price of a system.

If you are wondering which category yours falls into, that is exactly the question we start with. Write to us, or first run a free audit on your current site to see where it stands today.