I have a simple rule for deciding when client work should become a product: if I have built substantially the same system for three different companies, it is no longer a project. It is a pattern, and patterns deserve a permanent home.
I am Justin Pennington, founder of Infraxio, based in Ponte Vedra in St. Johns County, Florida. Before we had a product line, we had a client list: custom systems, integrations, and operational fixes delivered one engagement at a time. This post is a developer-flavored rewrite of a longer essay on my site, From Client Work to Products: What Agency Pain Taught Me About Software That Ships. More on me and what we build: infraxio.com/justin-pennington.
The third rebuild is the signal
The first time you build a post-sale handoff workflow for a client, it feels like custom work. The second time, you reuse a few pieces and call it experience. The third time, you are copy-pasting schemas, renaming fields, and re-fixing bugs you already fixed twice.
That third rebuild is where I started asking a better question: why am I solving this from scratch every time?
If you do agency or consulting development, you probably have one of these sitting in your repos right now. The same webhook glue. The same "sync the CRM to the project tool" job. The same reporting view the owner keeps asking for. It just lives in five private repos with five slightly different names.
What client work shows you that product teams miss
Pure product teams often learn about pain through discovery calls and feature requests. Client work shows you something rawer: what breaks on a Wednesday afternoon when the system someone bought eighteen months ago does not match how their team actually works.
The failure modes repeat with almost boring consistency:
- A CRM that tracks pipeline beautifully and has no idea what happens after the deal closes.
- A project tracker that works for the PM and leaves the owner with a reporting dead zone.
- A marketing stack that generates leads, with the handoff into operations being a chat message and a hope.
Each one is fixable with a custom build. We fixed them, repeatedly. But custom builds have a ceiling. They solve the problem for one company, in one context, at one moment. When the team changes or the business grows, the custom solution starts to drift.
How that turned into actual products
Every product we run at Infraxio traces back to a pattern we kept rebuilding:
IFX Hub came from stitching CRM, project management, invoicing, and operational tracking together for client after client. The post-sale workflow is where context dies, because the CRM knows the client, the project tool knows the tasks, and the accounting system knows the invoices, but none of them know the whole picture. Usually one operations lead holds it together with a spreadsheet and a remarkable memory. Hub is meant to be the system that person wishes they had. We ran our own business on it first.
Growth7 came from growth work for clients. Campaigns produced results, but the client's operational systems could not absorb them, so leads stalled. Growth7 connects growth activity forward into delivery instead of stopping at the conversion event.
IFX Bid came from government procurement work, where the options were enterprise software priced for defense contractors or a shared drive of old proposals. The real pain of bid response, past performance narratives, compliance sections spread across people, overlapping deadlines, was living in spreadsheets and email threads.
DockOps came from dock and yard operations where clipboard and radio were still the state of the art. Scheduling, carrier check-in, yard inventory, and dock assignment are coordination problems with real cost when they go wrong, and mid-size operators were stuck between ancient tools and software built for a much larger scale.
When custom should stay custom
The rule of three cuts both ways. Not everything should be productized.
Some workflows are the competitive advantage. They are tied to one company's structure, one niche, or one operating model, and generalizing them would sand off the exact thing that makes them valuable. If I have built something once and the requirements were deeply tied to that client, it stays bespoke.
Forcing a product shape onto a genuinely custom problem gives you software that is mediocre at everything instead of excellent at one thing. That is a worse outcome for the client than an honest custom build.
Shipping the code is about forty percent of it
The other lesson from years of client delivery: writing the software is maybe forty percent of the job. The rest is adoption.
CRMs fail because the sales team never uses them consistently. ERP rollouts fail because the implementation ignored how the warehouse actually processes orders. Growth tools fail because their output never lands in anyone's daily workflow.
So our definition of done includes a question that has nothing to do with test coverage: will the person opening this at 7 AM on a Monday actually use it instead of going back to their spreadsheet? If the answer is no, the feature is not done, no matter how clean the code is.
Why the shift is worth it
We still consult, and we still build custom systems when that is the right call. But the center of gravity has moved toward products that encode the patterns we kept rebuilding.
A custom engagement ends when the statement of work is complete. A product compounds. Every improvement reaches every customer, and every customer's usage shapes the next improvement. The feedback loop is tighter, and the work outlasts any one engagement.
If you run an agency or a dev shop, here or anywhere else, and you keep solving the same problem in different wrappers, the product probably already exists in your repos. You just have not extracted it yet.
Justin Pennington is founder of Infraxio, based in Ponte Vedra, Florida. Writing: penningtonj.com. About: infraxio.com/justin-pennington. Original essay: From Client Work to Products.
Top comments (1)
Good rule. Three paid builds of the same thing is solid evidence. Before productising, I'd also ask those three clients what they'd have cut and what they'd pay for again, since the product is rarely the union of all three projects. I built chatform.in for quick asks like that: a short form that follows up when the answer is vague.