Designing for the user who didn’t want my software — ACY Connect, twelve clients, one IT director

Section 1 — The context

ACY Connect is the institutional FIX 4.4 API. Where the retail trading platform serves 100K+ traders via a web and mobile UI, ACY Connect serves a smaller and more demanding audience: institutional clients who do not log into a screen, who run their own order-management systems, who connect to ACY’s venue routing over a TCP socket carrying FIX 4.4 messages, and whose unit of trust is the message log not the design layout. Twelve clients onboarded between 2022 and 2024 — mid-tier proprietary trading firms, family-office trading desks, two regional brokers integrating as introducing-broker partners. The case study at project-acy-connect.html covers the FIX architecture, the order lifecycle, and the design choices behind the developer surface. What that case study does not document is the political-skill arc that each onboarding actually was.

The structural reality of B2B enterprise design. The retail user opens the trading platform because they chose to. The institutional client’s IT director did not choose ACY Connect — the business development team did. The IT director receives a credential pack and a migration timeline. His incentive structure is: minimise downtime, minimise his team’s retraining cost, minimise the risk of a session-stability incident that lands on his desk during a market open. He is being measured on uptime, not on enthusiasm. The AMD brutal-review critique was correct: every senior B2B designer accumulates one of these stories per onboarding, and most case studies suppress them because they are politically delicate. This page does not suppress.

Why I am naming the pattern not the person. The protagonist’s identity is not the point and revealing it would be a betrayal of professional trust. The firm is anonymised as “the third onboarded client” throughout. The pattern of his three objections, the design moves, and the turn at month nine are all accurate. The composite is recognisable to anyone in the institutional FIX world; the individual is not.

Section 2 — The IT director who didn’t want ACY Connect

The third client’s IT director was a fourteen-year veteran of his firm. His last three FIX-vendor evaluations had each produced a written internal playbook on what to look for, what to test, and what to reject. Inside his firm, those playbooks were known as the reason the firm had a vendor-evaluation discipline at all. He did not announce that he did not want ACY Connect. He did not have to. The pattern showed up in the first kickoff call: he sent the most junior engineer on his team, the credential-receipt step took three weeks instead of three days, and his clarifying questions on the FIX dialect arrived in batches of forty rather than as a conversation.

The business-development read on this was “the IT team is busy.” The accurate read was different. He was making the cost of migration visible by slowing the migration down. His team had eight years of muscle memory on the incumbent vendor’s FIX dialect. His team had a custom adapter layer they had written and maintained for the incumbent’s idiosyncrasies, and that adapter represented internal institutional knowledge that a migration would devalue. He had been burned twice in his career by new vendors claiming session-stability properties they could not deliver under load — once during a London open, once during a Fed announcement. The third migration was not an evaluation he wanted to be remembered for losing.

I did not learn this in a meeting. I learned it by reading the forty-question clarifying batches he sent and noticing that they were not stupid questions — they were the questions someone asks who is trying to find the reason to say no.

Section 3 — His three objections

Objection one: muscle memory and sunk cost. His team’s eight years on the incumbent platform represented institutional knowledge that the migration would devalue. The custom adapter his team had written for the incumbent’s idiosyncrasies — the field-ordering quirks, the heartbeat-interval defaults, the cancel-replace state-machine edge cases — was real engineering work that would have to be re-done against ACY Connect’s dialect. He was not being parochial; he was accurately representing his team’s cost of change. Any answer that pretended this cost was small would have ended the conversation immediately.

Objection two: scepticism about session stability under load. ACY Connect was new in the institutional FIX market. He had been burned by new vendors twice before. The two specific incidents he named in our second call were precise: a mid-session disconnect during a London open at 08:01 UTC that left twenty-seven orders in an unknown state for forty-five minutes; a stale-quote propagation through his FIX feed during a Fed-statement window that produced a fill on a stale price his firm had to manually reconcile. His scepticism was earned. ACY’s session-stability claims were exactly the kind of vendor marketing he had learned to read past.

Objection three: vendor-lock-in concern. ACY Connect’s order-management semantics were tighter to ACY’s downstream venue routing than the incumbent’s. Specifically, the way ACY Connect handled cancel-on-disconnect, the way ACY’s ExecutionReport state machine carried venue-routing metadata, and the way ACY’s tag conventions made certain multi-venue smart-order- routing strategies harder to implement than they were on the incumbent’s more permissive architecture. His concern: adopting ACY would make it harder to add a third venue later if his firm decided to diversify counterparty risk. He was not anti-ACY; he was anti-irreversibility.

Section 4 — How I designed around each without compromising the architecture

Design move one: a field-mapping reference document, tag by tag. Not a sales-asset comparison sheet. A forty-page technical document that mapped ACY Connect’s FIX 4.4 message dialect against the incumbent’s tag by tag, value by value, edge case by edge case. Where ACY’s behavior matched the incumbent’s, the document said so plainly. Where ACY’s behavior differed, the document said so plainly, named the specific difference, and explained the architectural reason for the choice. This was the move that earned the first hour of credibility. His clarifying- questions batch dropped from forty to nine on the next round. The first batch had been him probing for things ACY was hiding; the second batch was him reading a document that did not hide.

Design move two: a session-health page with real-time heartbeat instrumentation. Inside the ACY Connect onboarding UI, a dedicated session-health surface that exposed real-time heartbeat lag distribution, FIX message-rate histograms with one-minute and one-hour rolling windows, sequence-gap detection events with the full session-resume protocol log, and FIX-level latency percentiles (P50/P95/P99) computed from the client’s own session traffic against ACY’s timestamps. His team could verify session stability themselves without taking ACY’s marketing claims as input. The surface was specifically designed to make it possible to refute ACY’s claims if the claims were wrong. We did not hide a session-stability gap behind a marketing dashboard; we built the surface that would have exposed it had one existed. After six weeks of parallel-run, his team’s own verification showed ACY Connect’s heartbeat-lag distribution matched the incumbent’s at the median and beat it at the 99th percentile. That was not my claim; that was the heartbeat data on his screen.

Design move three: onboarding sequence mapped to his playbook. Rather than imposing the ACY Connect onboarding flow on his team, I worked with him to map each step in the ACY sequence to the equivalent step in his team’s existing vendor-evaluation playbook — credential receipt, first session bring-up, smoke test on the test environment, parallel run against the incumbent on a paper-trading account, controlled cutover on a small slice of production flow, full cutover. Every checkpoint he was used to running was a checkpoint in the ACY Connect onboarding sequence, just instrumented with ACY-specific metrics. The onboarding sequence respected his team’s discipline rather than displacing it. This was the move that converted him from passive to active. His clarifying-questions batches stopped arriving in batches and started arriving as inline comments on the playbook document itself.

Section 5 — The turn at month nine

Three things happened between month four and month nine that converted the protagonist from obstacle to internal advocate. First, at month four, he asked for a feature that was not on the ACY Connect roadmap: a specific cancel-replace state-machine variant his strategies relied on, where the replace acknowledgment carried the original order’s cumulative-quantity rather than starting fresh. The incumbent supported it; ACY did not. I escalated to engineering, the feature shipped within eight weeks, and the implementation was clean enough that two other institutional clients later adopted it. This was the move that established the relationship as bidirectional rather than one-way.

Second, at month six, his team identified a session-resume edge case during a planned ACY-side maintenance window where the sequence-number reconciliation produced a 3-second gap his strategies could not tolerate. We fixed it. The fix was tested against his test environment before ACY shipped it to production. He had warned us about the edge case; we listened; we shipped the fix; we credited his team in the release notes. This was the move that established credibility as durable rather than situational.

Third, at month nine, his firm’s CRO challenged the migration cost in a quarterly review. The CRO asked why the firm had spent the engineering effort to migrate when the incumbent was still operating fine. The IT director answered with the heartbeat-lag distribution chart from the session-health surface (ACY P99 30% better than incumbent), the field-mapping reference document showing the tag-level equivalence that had made the migration tractable, and the cancel-replace feature ACY had shipped that the incumbent still had not. The CRO closed the question. The IT director was not selling ACY; he was presenting his own evidence to his own firm. The design moves had made that evidence collectable.

Section 6 — What design-for-resistance looks like as a pattern

The pattern across all twelve ACY Connect onboardings, applied with varying intensity depending on the client: design for the user who did not choose your product by giving them the tools to verify their own objections rather than persuading them to suspend them.

The verification surface is the product. The field-mapping reference document is not documentation; it is the product surface that lets the IT director’s team confirm or refute the migration cost themselves. The session-health page is not telemetry; it is the product surface that lets his team confirm or refute the stability claim themselves. The onboarding sequence is not a process; it is the product surface that lets his team verify ACY Connect adopts his discipline rather than imposing its own. Each surface is engineered for the protagonist’s scepticism, not for the buyer’s enthusiasm.

This is a design discipline, not a sales tactic. The buyer wants to be persuaded; the protagonist wants to verify. A B2B fintech designer who optimises for the buyer ships a product that does not survive the protagonist’s evaluation. A B2B fintech designer who optimises for the protagonist ships a product that earns adoption from the inside. The buyer signs the contract; the protagonist’s team uses the product every day for the next eight years. Designing for whoever signs the contract is a category error common enough in the institutional fintech market that it constitutes a competitive opening for anyone who designs the other way.

Section 7 — What I’d do differently today

If I were specifying the ACY Connect onboarding surface today, the design plan would change in four directions, each derived from the political-skill cost of the original twelve cycles.

1. Build the verification surface first, not last. In the original timeline, the session-health page was shipped in month two of the first onboarding. It should have been shipped before the first client received credentials. The protagonist needs the verification surface during the credential-receipt conversation, not eight weeks later. Reordering the product roadmap to ship verification surfaces ahead of marketing surfaces is the single highest-leverage change.

2. Treat the field-mapping reference document as a versioned product deliverable. In the original engagement, the reference document was a one-off I produced for the third client and reused with minor edits for the next four. It should have been a permanent versioned product artifact, updated with every dialect change to ACY Connect, with explicit changelog discipline showing what changed between versions. The cost: one engineer-week per quarter to maintain. The benefit: every future onboarding starts with a current document rather than a stale one.

3. Pre-register the integration playbook with the client before kickoff. In the original engagement, the playbook mapping emerged from collaboration with the protagonist over the first six weeks. It should have been pre-registered with the protagonist before the first technical call — the proposed mapping committed to in writing, the protagonist’s adjustments solicited explicitly, the final mapping signed off by both sides. The political-skill cost of the emergent process was that the protagonist did not know whether ACY was going to respect his playbook until midway through the onboarding. Pre-registration shifts that uncertainty to the first week, where the cost of resolving it is lowest.

4. Treat the protagonist as the design partner, not the obstacle. The single biggest mistake of the original engagement, which I corrected by the fourth onboarding but cost time on the earlier three, was framing the IT director’s objections as resistance to manage rather than as design input to incorporate. The forty-question clarifying batches were not noise; they were the requirements document the protagonist did not know he was writing. Reading them as requirements rather than as obstacles is the discipline that converted the relationship from adversarial to collaborative twice as fast on later clients.

How to read this case study

If you are evaluating this work for a hiring decision in B2B enterprise fintech, this is what the political-skill work looks like over a multi-client cycle. The AMD brutal-review critique was that the ACY Connect case study did not name the user who did not want the product. This page names the pattern of that user across twelve onboardings, anonymised at the individual level out of professional respect but accurate at the discipline level.

The reason this work belongs in a Senior PD portfolio is that the discipline transfers. The verification surface as adoption mechanism is the pattern. It applies to any enterprise product where the buyer is not the daily user, and to any fintech product where the regulatory or technical scepticism of the daily user is the binding constraint on adoption. The IT director at the third client is now the composite reader this discipline is designed for — the recruiter at the next firm, the design director reviewing the portfolio, the CRO who needs to challenge the hiring decision in a quarterly review. The surface you are reading is the verification surface for the work it describes.

Continue reading

• ACY Connect case study → — the technical design behind the FIX 4.4 onboarding surface this political-skill arc lives inside.
• FIX 4.4 latency order entry design → — the field note on the protocol-level design constraints that shape what is and isn’t possible at institutional latency budgets.
• ACY post-launch iteration disclosure → — the parallel honest-disclosure note for the retail surface (RG 268 cross-border disclosure). Same register: what shipped, what changed in production, what didn’t move that I expected to.
• Finlogix methodology disclosure → — the parallel disclosure for the Cohen’s d = 2.47 number.
• Accessibility audit disclosure → — the parallel disclosure for the WCAG 2.1 AA claim.
• All field notes →