DEV Community: Justin Pennington

Buy vs. Build Is the Wrong Ticket. Ask Who Can Change the Workflow.

Justin Pennington — Fri, 23 Oct 2026 15:42:40 +0000

Originally published on penningtonj.com.

If you have shipped internal tools for long enough, you have seen this ticket: "Evaluate buy vs. build for X." Somebody attaches a spreadsheet. One column is a SaaS license. The other is an engineering estimate. Whichever number is smaller wins, and the team moves on.

I run a small product studio in Ponte Vedra, Florida, and I have watched that spreadsheet make the wrong call in both directions. The problem is not the math. The problem is that the spreadsheet measures the cheapest thing to estimate and skips the thing that actually decides whether the project works.

The variable nobody puts in a cell

The question that matters is this: when the workflow changes next quarter, who is allowed to change the system?

It will change. A new service line appears. A customer starts requiring something the current process can't produce. A compliance section shows up in a bid that nobody planned for. A handoff that used to end at "lead created" now has to carry context all the way into delivery.

Whoever can make that change, quickly and without opening a new project, owns the system. Not whoever paid for it.

Two failure modes, same root cause

Bought, and "close enough." Configuration feels like power right up until the thing you need is not a setting. Then you file a feature request, build a workaround, or pay for a customization that belongs cleanly to neither you nor the vendor. Six months later the workaround is the real system and the product is the thing people log into for reporting.

Built, and orphaned. The custom tool matched the business perfectly on launch day. Then the person who built it moved on, nobody was named to keep it matched, and it drifted every month after. Eventually someone trusts a status field that no longer means what the screen says.

Neither one is a software failure. Both are ownership failures.

A better split: common loops vs. specific edges

Instead of "which is cheaper this year," ask whether the workflow is common enough that someone should be improving it as their full-time job, or specific enough that any general product will always be a compromise your team routes around.

A surprising amount of what sounds unique in discovery is a common loop with local nouns:

Work comes in.
It gets assigned.
Someone does it.
Someone else needs to know it's done.
The invoice follows without a human remembering to start it.

That loop wants a product. We stopped rebuilding it as one-off client code at Infraxio and put it into IFX Hub, so task history, approvals next to the work, and closed-deal-to-delivery all live in a system that does not depend on whoever wrote the last version.

The same logic applies to narrower jobs. Dock scheduling is a good example: the appointment at the door is a promise to a carrier and a plan for the crew inside, and it has to change at the speed of the yard. That is why DockOps is aimed at one job instead of being a tab inside a platform that "also does scheduling."

Then there are the true edges: a pricing exception, a crew-to-crew handoff, an approval path that would make no sense at the company next door. Forcing those into a generic product usually means the workaround becomes the system. Those are worth building, on the stack you already run, if someone who still works there can change them when the edge moves.

What each choice really commits you to

	You get	You owe
Buy	Other customers fund the roadmap	Your important changes must match theirs, and arrive before a workaround hardens
Build	Change the workflow without filing a request	You must keep changing it, forever, with a named owner

Buying is a great deal for the boring middle: accounting close, payroll, the standard order path. It is a bad deal for the workflow that makes you different, or one your team has already abandoned twice.

Building without an owner just gets you a more expensive spreadsheet.

Do this before anyone prices anything

Before the license-vs-estimate spreadsheet exists, write down three workflows that will have to change in the next twelve months. Not features. Workflows: who does the work, what they hand off, and what "done" means.

Next to each one, write a name. Not a team. A person who can change how that workflow runs (in the product, the config, or the codebase) without kicking off a new project.

If you can't write a name, you're not ready to buy or build. You're about to design a dependency and call it a system.
If the name is a vendor's customer success manager, be honest that you're waiting on their roadmap, and only buy if that wait is acceptable for this workflow.
If the name is someone on your team, choose whatever lets them change it as part of the job, not as an after-hours favor.
If the name is a contractor who will leave, write down who they hand it to. A build without that handoff is a rental you paid for like you owned it.

The smaller number on the spreadsheet isn't the decision. The name next to the workflow is.

I'm Justin Pennington, founder of Infraxio, a product studio in Ponte Vedra building operational software for businesses across Northeast Florida and beyond. More essays at penningtonj.com.

Make CRM Data a Side Effect of the Work, Not a Chore Next to It

Justin Pennington — Mon, 19 Oct 2026 16:03:22 +0000

If you've ever built or administered a CRM, you've probably seen the dashboard that looks great for two weeks and quietly turns into fiction by week three. The usual diagnosis is people: the reps won't log their calls, ops forgets to move the deal stage, marketing assumes someone else will enter the lead.

I think that diagnosis is wrong, and it leads teams to the wrong fix. The data dies because of where the system sits, not because of who uses it.

I'm Justin Pennington, founder of Infraxio, based in Ponte Vedra in St. Johns County, Florida. We build operations software for mid-size businesses and run our own company on it. This is a builder-oriented rewrite of an essay on my site, Nobody Lives in the CRM. More about me and what we're building: infraxio.com/justin-pennington.

The tab test

Watch what someone on an operations team actually has open at 9 AM on a Monday: chat, email, maybe a project board. The CRM is one tab away, and that tab may as well not exist.

When a prospect replies, the instinct is to answer in the thread where the conversation is happening and move on. Updating a record is a second action that happens later, if at all. Humans are very good at deleting second actions from their day, and they're right to be. It's overhead that helps someone else run a report.

So the question I ask when reviewing any internal system is simple: is this tool on the path of the work, or next to it? Tools on the path get adopted without a mandate. Tools next to the path need enforcement forever.

Enforcement is a symptom

The standard response to a dying CRM is a stack of enforcement mechanisms:

Required fields that block saving a contact until twelve boxes are filled
Weekly pipeline reviews where the manager asks why nothing was updated
Automated nag emails from the admin
A quarterly "data cleanup day"

Every one of these produces compliance, not adoption. You get data that's late, minimal, and grudging. If you're the engineer asked to add yet another validation rule, that's a signal the architecture is wrong, not that the validation is missing.

Re-entry is where data quality goes to die

From a systems point of view, the bigger problem isn't motivation. It's that the CRM is downstream of several other systems and depends on humans to copy data between them.

Every manual hop is a lossy transform:

Hop	What typically gets lost
Campaign tool to CRM	Source, engagement history, score
CRM to project tool	Scope notes, promised dates
Project tool to invoicing	Completed milestones, billable time
Inbox to CRM	The actual conversation

A transposed phone number here, an abbreviated company name there, an optional "lead source" field left blank because the rep was in a hurry. Multiply by every lead, every week, and within a month nobody trusts the data. Once nobody trusts it, nobody updates it. That feedback loop is the week-three cliff.

The design principle: state transitions create the records

The fix I keep coming back to is architectural. Put the relationship data inside the workspace where the work happens, and let the records get written as a byproduct of people moving work forward.

Concretely, that means designing around transitions people already perform, not forms they're asked to fill in:

A lead qualifies. It should arrive in the workspace with its context attached: which campaign sourced it, what it engaged with, how it scored. Nobody retypes it.
A deal closes. The delivery tasks should be generated in the same workspace, linked to the same client record.
A milestone completes. The billing data should already be there, because the work and the time were tracked in the same place.

Each step is something the operator was going to do anyway. The data trail is a consequence, not a separate job.

This is the pattern we built IFX Hub around: the deal, tasks, client updates, time entries, and invoices live in one operational workspace rather than three tools wired together. Upstream, Growth7 handles outbound campaigns, lead scoring, and qualification, and routes qualified leads into that workspace with their history intact. I'm biased, obviously. But the principle holds whatever stack you use, including a homegrown one.

A checklist if you're building or picking one

If you're designing an internal ops tool, or evaluating one for your company, these are the questions I'd ask:

Does work happen inside it? If tasks, client communication tracking, and billing live elsewhere, the record will always lag.
Does data enter exactly once? Count the places a client's name gets typed. More than one is a bug.
Is the first screen useful to the person doing the work? Not the VP. The coordinator opening it at 7 AM. If the landing page is a pipeline chart they don't care about, they'll close it.
Are reports derived or demanded? Forecasts and client health should fall out of real activity, not be assembled by someone filling in fields for a meeting.

Why the industry keeps shipping the side-trip CRM

Most CRMs are optimized for the person who buys the software, usually a sales leader or CEO who wants pipeline visibility, rather than the person who uses it all day. That's why they demo well in a conference room and stall in the field.

I see it constantly with service businesses and contractors across Northeast Florida, from Ponte Vedra to downtown Jacksonville. These are sharp operators. They bought a well-known CRM, did the implementation, did the training. Six months later the most reliable pipeline source is a text thread between the founder and the sales lead.

That's not a discipline problem. It's a design problem, and design problems are the kind engineers can actually fix.

So before you add another required field, ask the better question: where does this team already spend its day, and can the CRM function live there instead?

Originally published on penningtonj.com. I'm Justin Pennington, founder of Infraxio in Ponte Vedra, Florida. More writing at penningtonj.com.

What's the worst "required field" you've ever been asked to add to keep a CRM alive? I'd like to hear it in the comments.

Model Your AI Agent as an Assignee, Not a Chat Session

Justin Pennington — Tue, 13 Oct 2026 15:52:42 +0000

Most internal AI rollouts I see die the same quiet death. Someone wires up a chatbot, a few people try it, the answers are decent, and six weeks later the tab is closed and nobody misses it. The model was fine. The integration point was wrong.

I'm Justin Pennington, founder of Infraxio, based in Ponte Vedra in St. Johns County, Florida. We build operations software for mid-size businesses, and we run our own company on it. This is a developer-oriented rewrite of a longer essay on my site, Put AI on the Task Board, Not in a Chat Window. More about me and what we build: infraxio.com/justin-pennington.

The short version: if you're building AI into an operational tool, stop modeling the agent as a conversation and start modeling it as a user who can be assigned work.

We've shipped this bug before

Anyone who has implemented a CRM has watched this movie. The CRM was a place you had to go to, not a place where the work already lived. Reps kept their real pipeline in a spreadsheet, the CRM became a reporting surface for management, and adoption numbers looked great right up until someone checked the data.

Bolt-on AI chat has the same architecture problem. It's a side trip. Side trips don't survive a busy Tuesday.

People don't abandon tools because the tools are bad. They abandon tools that aren't on the path of least resistance. In most companies, that path is the system of record: the board or tracker where tasks get assigned, statuses change, and work gets reviewed.

Chat is the wrong primitive for operational work

Chat is great for brainstorming, ad-hoc questions, and first drafts. But look at what a chat session lacks compared to a task:

Property	Chat session	Task
Owner	None	Assignee
Deadline	None	Due date
State	Scrollback	Status column
Review	Optional, manual	Built into the workflow
History	A transcript nobody searches	Activity log on the record
Downstream links	Copy-paste	Dependencies, parent project, client

When operational work happens in chat, you've quietly created a parallel system. The real system of record never learns the work happened, and the decision it informed isn't recorded anywhere that matters.

The design: the agent is just another assignee

This is how we approached AI inside IFX Hub, our operations platform. A task can be handed to a person or to an AI agent, and the mechanics are deliberately identical:

Assign the task, with the same fields any task has: description, due date, context.
The agent picks it up and does the work.
Status moves to review when it's done.
A human approves it or sends it back with comments, exactly like reviewing a colleague's work.

If you're designing this yourself, the main implication is in your data model: the assignee field shouldn't care whether it points at a human or an agent. Same task table, same status machine, same comment thread, same permissions checks. No separate "AI results" screen.

That one decision buys you three things for free.

An audit trail. Every agent action is logged where human actions are logged. You don't need a separate dashboard to answer "what did the AI do, when, and who signed off?" The task history answers it.

Review by default. Agent output lands on the same board as everything else, so it enters the same review loop. The ops lead who scans the board every morning sees AI-completed and human-completed work side by side. There's no extra step to go check on the bot.

Accountability. When something goes wrong, and something always goes wrong, you can trace it: assigned at this time, produced this output, reviewed by this person, approved or rejected. That chain of custody matters for quality, for compliance, and for not losing track of what happened.

What to route to the agent first

Not every task belongs on an agent's queue. The filter we use internally, and with clients, is three questions. A task is a good first candidate only if it passes all three.

Repetitive: it follows the same pattern every time. Status updates from structured data, a report from a template, background research for a bid response, a follow-up email triggered by a project milestone.
Well-specified: you can check the output without senior judgment. The extraction captured the right fields or it didn't. The report matches the template or it doesn't.
Reversible: if it's wrong, fixing it is cheap. A draft that needs editing is fine. Deleting records, sending a client communication, or submitting a bid should stay with a human until you have real confidence in that specific workflow.

Anything that's novel, ambiguous, and consequential stays with people: strategy, client relationships, calls that depend on context the system doesn't capture. The point is to take load off people so they can spend time on the work that actually needs them.

Build for the 7 AM Monday, not the demo

A natural-language query bar or a generative dashboard looks great in a demo. The features that survive are the ones that remove a step from a workflow the user is already doing. "Assign this to the agent" is one click on a board people already open every morning. "Open the AI tool and explain the context" is a new habit, and new habits lose.

That's the same lesson I've seen with clients across Jacksonville and Northeast Florida for years, whether the tool was an ERP, a CRM, or now an AI agent: the software has to live where the work happens, create less friction rather than more, and make it obvious what happens when you use it.

I'm curious how others are handling this. If you've put agents into a production workflow, did you model them as users, as background jobs, or as something else, and what broke?

Originally published on penningtonj.com. Justin Pennington is the founder of Infraxio in Ponte Vedra, Florida.

The Rule of Three for Turning Client Work Into Products

Justin Pennington — Tue, 06 Oct 2026 15:47:30 +0000

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.

Your Growth Stack Is Blind After the Close

Justin Pennington — Wed, 30 Sep 2026 15:46:24 +0000

Most growth tooling I have evaluated in the last few years sells the same story: more leads, smarter sequences, cleaner scoring, a prettier handoff to sales.

Then the deal closes.

The nurtured lead becomes a row in a different system, owned by a different team, with no memory of the twelve touchpoints that got them there. Campaign dashboards stay green. Delivery starts cold. That seam — marketing to operations — is where B2B companies quietly lose context, trust, and hours.

I am Justin Pennington, founder of Infraxio, based in Ponte Vedra in St. Johns County. This is a Dev.to rewrite of a longer essay on my site; the full version is here: Where Marketing Stops and Operations Start — and Why That Gap Costs Deals. More on me and what we build: infraxio.com/justin-pennington.

The seam nobody owns

In a typical org, marketing owns the qualified lead. Sales owns the deal cycle. Ops — onboarding, projects, delivery, invoicing — inherits the result.

Specialization is fine. Broken context is not.

The CRM knows deal value, close date, and owner. It usually does not know the scope that was promised, the timeline the buyer expects, or the pain points that actually drove the purchase. That lives in emails, call notes, and proposal docs. Delivery excavates it — if they know to look.

I have watched this in companies around Jacksonville and Northeast Florida and far outside it. A services firm closes real revenue, then the client's first delivery call is a re-interview of everything they already told sales. That is not one clumsy kickoff. It is an architecture problem.

Why the stack stops at the signature

Marketing automation, project tools, and billing rarely share a buyer. The VP of Marketing buys growth. The COO buys the PM suite. The CFO buys invoicing. Each vendor optimizes their slice. Almost nobody designs for the transition.

So you get:

A lead-scoring model with no concept of a project or deliverable
A task board with no concept of campaign attribution
An invoice system that only wants a line item and a due date

The "integration layer" is Zapier glue, CSV exports, and the one person who remembers how the pieces fit. When they are out, the handoff breaks.

If you have ever maintained that glue — webhooks that fire late, field maps that rot, silent sync failures — you already know this is an ops reliability problem wearing a growth costume.

Three concrete leaks

Context loss. Every time a client repeats themselves to a new person on a new form, trust erodes. That is data continuity failing, not a missing welcome email.

Attribution gap. If growth never sees on-time delivery, renewal, or LTV, you optimize for lead volume or close rate while funding campaigns that produce fast closes and high churn. Half-blind dashboards feel precise until retention shows up.

Operational drag. Manual project setup — copy details, assign team, set timeline — is often thirty to sixty minutes per deal. Twenty deals a month is a full workweek of admin that exists only because two systems do not share a schema.

Bridging growth data into delivery

That gap shaped how we build at Infraxio.

IFX Hub started as the operational spine: CRM, projects, invoicing. Clean ops still fails if marketing and sales data arrives incomplete, inconsistent, or late. That is a big reason Growth7 exists the way it does. Growth7 launched publicly this week — not as another campaign bolt-on, but as a layer meant to connect forward into Hub and the delivery stack so first-touch data survives into fulfillment.

Saying that is easy. Building it is not. A marketing "lead" is probabilistic — engagement signals, score, maybe. An ops "client" is concrete — contract, scope, timeline, invoice schedule. Bridging those models takes real schema work, not a webhook on deal-won.

Agency hours vs. product infrastructure

When we ran growth as agency work — custom campaigns, bespoke reporting — we saw the same failure mode everywhere: marketing produced heat, ops could not absorb it cleanly. Hot leads cooled in onboarding queues with no system to catch them.

Product thinking asks a different question. Not "how do I run a great campaign for this client," but "how do I connect growth activity to operational delivery for every client, repeatably." That is the difference between selling hours and building infrastructure.

Growth7 is our product answer. Sequences and ad optimization are table stakes. The value is what happens when the lead converts and the system does not lose its memory.

What "working" looks like

When the marketing-to-ops boundary is designed on purpose:

Delivery opens a project that already carries sales-cycle context — carried forward, not copy-pasted
Attribution reaches project completion and retention, so marketing can optimize for LTV
Capacity planning sees pipeline before close, not after
The client stops re-explaining themselves at every stage

You do not need one monolithic platform. You need systems that treat the handoff as a first-class interface — the same way good APIs treat contracts between services.

Build for the seam

Growth7 is live and the Hub integration is working. There is still a long roadmap of tightening that connection. The same philosophy applies across the Infraxio tools: each domain should be strong, and the leverage should come from clean data between them.

If you are running B2B ops out of Jacksonville, St. Johns County, Ponte Vedra, or anywhere else and you recognize the pattern — converts that stall in onboarding, campaigns that look great until you measure delivered revenue, a team burning hours on handoff work that should be automatic — the fix is rarely "buy another marketing tool" or "buy another ops tool." It is connecting what you have, or replacing pieces with systems built to stay connected.

That is what we are building. That is what launched this week.

Justin Pennington is founder of Infraxio, based in Ponte Vedra. Writing: penningtonj.com · About: infraxio.com/justin-pennington · Original essay: Where Marketing Stops and Operations Start.