What the Retainer Looks Like After Month Three

In month one, we're doing most of the driving. We ask the four questions, push for a measurable KPI, argue for the tighter scope, and decide which module ships first. The client knows their business; we know what makes a portal extensible vs. what paints you into a corner by month four.

By month two, something shifts. The client has seen the first module move a real number. They understand, in concrete terms, what "the portal can do this" actually means. They start proposing things: "could it also handle the work order?" or "what if providers got an alert before their authorization ran out?" The proposals are rough, but they're grounded.

By month three, on the portals that are going well, the client is filling in all four scoping questions themselves. Bucket, KPI, baseline, 60-day target. They've done it enough times to know the format, and more importantly, they've seen what happens when any of those four is missing: the module ships and nobody can tell if it worked.

At that point, our job has narrowed to two things.

Build order. The client knows what they want next. What they don't know is which dependencies have to ship first. On Freedom Ag, Derek outlined the invoicing module before the application log was complete. The invoice has to reference what was actually applied in the field, not just what was quoted, because field deviations are common: a rep adjusts a rate, substitutes a product, treats a different block. The invoice needs that finalized log record to pull from. We built the application log first. When the invoice shipped two weeks later, it generated from the completed log rather than from the original quote, which meant Derek could send it without manually reconciling field deviations against what he'd promised. If we had built them in the order Derek proposed, we would have had to rebuild the invoice data model when the log arrived.

Build order is the expertise clients can't develop on their own, because they haven't built ten of these. They know their workflow. We know which architectural decision made two portals ago turns into a headache at module six.

Build quality. Every module we ship has to extend, not break, what already exists. If the first module was built record-backed, the fourth module should read from the same record without requiring a schema migration. If we got lazy in month one and built something standalone, month three becomes a refactoring project disguised as a feature build. Clients don't see this directly, which is exactly why it matters: the hidden cost of bad architecture shows up as "why is this taking so long?" six months in.

On Homefront, every module reads from the IFSP record: session notes, authorization tracking, due dates, the supervisor dashboard, billing documentation. When the director proposed the supervisor dashboard, it took three days to build because the authorization and due date data was already structured and queryable. A supervisor dashboard built before those two modules would have had nothing to read from, or it would have required maintaining a separate data layer that would drift from the source records over time.

The retainer, from our side, is not a subscription for features. It's continuous access to a team that knows the data model, knows the dependency graph, and can say "not yet" when a module is proposed before its foundations are in place.

The client owns the what and the why. We own the when and the how. That split is what makes a portal grow rather than sprawl.