Liberty Ships Built in 4 Days. Your Implementation Just Crossed Month Eleven.

What a wartime shipyard can teach a modern AI rollout about speed, risk, and letting a team grow into what it built.

On November 12, 1942, a full sized cargo ship slid into the water at the Permanente Metals shipyard in Richmond, California. Four days, fifteen hours, and twenty nine minutes earlier, its keel did not exist. Two hundred fifty thousand parts and fourteen million pounds of steel, assembled by a workforce where most people had never built a ship before that year.¹ The SS Robert E. Peary was a complete, seaworthy Liberty ship when it launched, ready to carry cargo across an ocean where U-boats were actively sinking American shipping, the same as every other ship in the fleet.

Most companies today are eleven months into an AI implementation that still is not live.

How long we expect a complex project to take is the subject of this piece. Shipbuilding and software have little in common on the surface. The shipyard proved something every implementation team still forgets: speed and quality do not have to be in tension. The tension that matters is between speed and the habits nobody actually needs to keep.

Proxigee Services helps companies speed the results from technology implementation: choosing the AI capability worth deploying first, fitting it into how a team already works, and building the muscle to keep shipping long after the first release. The pattern below comes from that work, and from a story most American schoolchildren used to know by heart.

How did Liberty ship production compress from 230 days to 4 days?

Liberty ship production compressed from an industry standard near 230 days for the first ships in the program to a Kaiser shipyard average near 42 days, and eventually under three weeks, by standardizing the design, prefabricating sections away from the ways, and replacing riveting with welding so crews could assemble in parallel instead of in sequence.² The Robert E. Peary was the record, not the routine, and it was set on purpose. The yards were in open competition with each other, partly for pride and partly to make a public point: the United States intended to build ships faster than an enemy navy could sink them.

Here is the detail worth sitting with. The ship's design did not change to make this possible. The Liberty ship was already a proven, unglamorous cargo vessel, engineered once and repeated more than twenty seven hundred times over the course of the war. Kaiser did not reinvent the hull. He reinvented how fast an already proven hull could be assembled. The innovation lived entirely in the deployment method.

Why does a modern AI implementation take eleven months when the technology itself moves in weeks?

A modern AI implementation takes the better part of a year for a simple reason: most companies scope the project as if they were building the whole of "AI," instead of shipping one specific capability. McKinsey's research on enterprise AI agents found deployments running eight to fourteen months from strategic assessment to production, and Deloitte puts typical implementation timelines at five to nine months, stretching toward twelve when the integration touches multiple systems.³⁴ Month eleven sits close to the median, not the outlier it feels like from inside the project.

AI as a category is genuinely a multi year undertaking. A company's overall capability, its data foundation, its governance, its culture, grows and compounds over years, and that timeline deserves real planning of its own. A specific, well scoped implementation, one workflow, one decision, one team, is a different kind of project entirely. It is the one quietly being stretched to match the schedule of the larger undertaking it happens to live inside.

What does "center of the curve" AI capability actually mean?

Center of the curve AI capability means the well understood, widely proven, low risk part of what AI can already do reliably. It does not mean a use case chosen because it is average or safe. The curve is the distribution of tasks companies actually ask AI to do. At its center sits the common, high frequency work the models have seen countless times in training and handle dependably. Out at the edges sit the rare, specialized cases where reliability drops off and risk concentrates.

That distinction is playing out publicly right now in the debate over GLM-5.2, an open weight model that benchmarks competitively with Claude on much of this everyday work.⁵ The analysis keeps arriving at the same split: the free challenger excels at center of distribution tasks like content generation, coding, and data synthesis, while the premium frontier models keep their edge in the unusual, specialized cases. Read that as an implementer and the lesson is direct. The center of the distribution is where the risk has already been wrung out of a capability. The value has not been wrung out along with it.

That center is enormous right now. Document extraction, structured data cleanup, scheduling and routing agents, forecasting against clean historical data, agentic workflows built around messaging tools people already use. None of it is cutting edge, and all of it is worth real money when pointed at the right problem inside a specific business. McKinsey's most recent research on agentic AI found that only 5.5 percent of organizations are seeing real financial returns from their AI investment, and the companies that do share one trait: they redesigned a real workflow end to end around something already proven, backed by strong leadership engagement and clear human oversight.³

The Peary makes the same point in steel. Kaiser did not chase a new hull design to set his record. He picked the most proven part of the curve, a design already tested across dozens of prior ships, and innovated entirely on how fast it could reach the water. Reaching for the unproven edge on your first deployment is not ambition. It is unnecessary risk wearing ambition's clothes.

Why does frictionless adoption matter more than avoiding new logins?

Frictionless adoption matters because it fits a new capability into habits and toolkits a team already has. A new login is only the most visible symptom of asking a team to change how it works before it has seen any value. The point was never to ban new interfaces on principle. The point is that adoption should not force a workforce to relearn how it operates before the benefit shows up.

Kaiser's shipyards lived this out of necessity. Most of the wartime workforce, including thousands of people with no shipbuilding background at all, had never set foot in a shipyard before 1941. Standardized, prefabricated sections meant each worker mastered one repeatable task rather than the full craft of shipbuilding. The process was built around the skills the workforce actually had, not the skills a peacetime yard would have preferred they arrive with.

We saw the same principle with a convenience store client. The original pitch featured a voice agent, and it was genuinely impressive in the room. Once we understood how the team and their customers actually communicated, a texting function replaced the flashier option, because it matched an existing habit instead of asking anyone to adopt a new one. Small businesses already hold a real speed advantage over larger competitors for a related reason: a much smaller company can put a new tool into real work in a few weeks, while a much larger one spends months on procurement and change management before anyone logs in at all. That friction, more than any technical constraint, is what stretches a timeline from weeks into months.

Does shipping in weeks mean shipping something unfinished?

Shipping in weeks still means shipping something complete. The Robert E. Peary that launched on day four was a fully rigged cargo ship, ready for the ocean, the same as every ship built to the standard forty two day schedule. Speed did not lower the bar for what counted as finished.

The definition of a real, finished release has not moved. What moves now is the speed at which the next improvement follows the first one. The old assumption held that a serious enhancement required living without it for the better part of a year, so teams learned to treat that wait as the price of doing things properly. AI has compressed the cost and speed of building the next iteration along with everything else it touches. A properly scoped first deployment should already be doing measurable work in the business the day it ships. What comes after it now arrives in days or weeks, not at the next annual budget cycle.

Why should a company expect the solution to grow in directions no one planned?

A company should expect its AI solution to grow in unplanned directions because nobody, including the team that built it, knows the best end state when a genuinely new capability first lands. That uncertainty is the normal condition of real innovation, and planning for it should be an explicit expectation from day one, not a fallback for when the first version comes up short.

Liberty ships bear this out too. The same standardized hull Kaiser built in four days was later adapted into colliers, tankers, hospital ships, and boxed aircraft transports, uses the original design was never built to anticipate.⁶ The platform held. What it was asked to do kept expanding as the people using it found needs the original drafting table never saw.

The same pattern holds inside a company that deploys AI well. The team closest to the work will find uses for the capability that the implementation plan never listed, because they are the ones actually living inside the problem it touches. That is the return on giving people a real tool early, instead of waiting until every future use case has been mapped in advance. It is also why the people using the tool need real fluency in it, not a login and a shrug, a case we have made at length elsewhere.

Why is speed an innovation in itself?

Speed is an innovation in itself because how fast a proven capability reaches real work determines how much of its value a company actually captures. The Liberty ship program did not win its place in history on naval architecture. It won it on tempo.

This week marks two hundred fifty years since a small group of colonists decided they were done waiting for permission from a system that moved at its own pace, on its own schedule, with no urgency to match theirs. They did not have the luxury of eighteen month rollouts. Neither did the workers at Kaiser's yards eighty years later, racing a war against the clock. Somewhere between then and now, a lot of American enterprises decided that slow was the same thing as careful. The shipyards prove it never was.

The innovation was never the hull. It was how fast a proven hull could reach the water.

Your implementation does not need four days. It does need to stop mistaking eleven months for diligence. Pick the capability that is already proven. Fit it into how your team already works. Ship something complete, and let your people discover what it is actually good for. That is how Proxigee helps companies compress that timeline.

The Peary sailed on day five. What is your team still waiting on?