2026· frontend· ai
An AI assistant that doesn't just answer questions about a business's books — it proposes actions against them, and I built the layer that decides when those are safe to run.
I built Nivram's client on both platforms. On the web the AI interaction layer is entirely mine. On mobile I built both halves: the streaming shell — socket handler, frame scheduler, chunk merge, message list, chat screens, at 88–100% of surviving lines and 100% of the frame scheduler — and the interaction layer the stream feeds, covering the component registry (84%), the structured parser (96%), the PIN gate (83%), the personal/business resolver (75%), and the hidden message that reports a result back to the model (100%). Of the seventy action cards, sixty-one are majority mine — 78% of the lines across them; colleagues wrote the personal bill-pay and transfer cards. I did not build the apps around all this: BrandDrive mobile alone is twelve people and roughly three thousand commits, of which 109 are mine.
Nivram answers questions about a business's own books — receivables ratios, top suppliers, revenue forecasts, when to restock. Those answers take real time to generate, so a request-response interface leaves an owner staring at a spinner wondering whether it has hung. Streaming fixes that, and React Native does not stream: its `fetch` gives you no readable response body, so the pattern every web tutorial assumes simply does not exist on the platform.
With no streamable response body in React Native, the server emits discrete events over Socket.IO — start, thinking, chunk, end — rather than a chunked HTTP body. Nivram attaches its own listener instead of using the app's shared WebSocket hook, because that hook keeps only the latest event in state and would drop chunks the moment they arrive faster than React re-renders.
Tokens arrive far faster than a screen refreshes. Each one is coalesced into a ref and flushed to the store on a `requestAnimationFrame` tick, so the list re-renders about sixty times a second regardless of whether sixty tokens arrived or six hundred. Dispatching per token is the obvious implementation and it makes the UI stutter exactly when the user is watching it most closely.
When a draft is promoted to a real thread the chat key changes underneath an in-flight reply. Re-binding the socket listener on that change would drop the rest of the message, so the handler is held in a ref and reads the current key rather than closing over it. It is the kind of bug that only appears on the first message of a new chat, which is the first thing any user does.
Chunks arrive sometimes as deltas to append and sometimes as cumulative snapshots of everything so far. The merge checks whether the incoming chunk already starts with what is held and appends or replaces accordingly, so a change of server behaviour degrades into a redundant assignment instead of duplicated text.
The envelope carries a message alongside component and data fields. The text is pulled from the partial buffer and rendered as markdown while it arrives, so the answer reads as it is written; anything the user can press mounts only once the object is complete. Those controls are not decorative — they call the same production endpoints as the app's own screens, and some of them move money. A button rendered from a half-parsed payload is a transfer with a missing field behind a confirm the user has already trusted. Arriving a second late is the correct failure.
Component types resolve through a central map, and an unrecognised one renders nothing — a warning in development, silence in production. That sounds like giving up and is the opposite: the assistant releases continuously while the app crawls through two review queues, so a user on last month's build will certainly be offered a card their copy has never heard of. The choice is between a missing card and a crash, and only one of those lets the rest of the answer still be useful.
Money-moving cards are not mounted and then asked for authorisation. A gate component opens the transaction PIN modal first, merges the PIN into the payload, and only then mounts the real action with the authorisation already present — so the component never exists in an unauthorised state. Putting the check inside each card would have meant seventy chances to forget it; this way there is one, and forgetting is not among the available mistakes.
When a card succeeds it does not just close. A hidden message goes back up the same socket carrying what happened, so the assistant's next turn knows the customer now exists or the transfer went through. Fire-and-forget would have been one line instead of the round trip — and would leave the model confidently offering to create a record it just created, because nothing ever told it otherwise. The conversation is the state; anything that changes the world has to say so.
Every assistant card except the most recent is disabled. Scrolling up and pressing a confirm from three answers ago would fire an action against a payload the conversation has moved past — on a financial app, most likely a second transfer. The stale ones stay visible as a record of what was offered, and refuse to do anything.
Gave up
Reusing the app's shared WebSocket abstraction
Bought
Chunks that survive arriving faster than React renders. The house abstraction was correct for every other feature and wrong for this one, which is a harder thing to argue for than writing something new.
Gave up
Up to one frame of latency on every token
Bought
A render rate bounded by the display rather than by the model's output rate. Sixteen milliseconds is invisible; a list re-rendering four hundred times a second is not.
Gave up
Interactive components appearing after the text finishes rather than alongside it
Bought
No possibility of rendering a control from a half-parsed payload. For components that move money, arriving late is the correct failure.
Gave up
A hand-written Android keyboard lift instead of the built-in avoidance view
Bought
A composer that stays above an edge-to-edge IME while the answer streams behind it. iOS keeps the standard behaviour; only Android needed the measurement.
Shipped
App Store · Play Store
in production
Store updates cut
OTA
shipped over the air through EAS Update
Render rate
1 / frame
coalesced from an unbounded token rate
Streaming layer
88 – 100%
surviving lines by git blame across the four core files
Interaction system
75 – 100%
registry, parser, PIN gate, resolver, and the hidden result message
Tests in the module
72+
Jest files under the Nivram tree
Ratios are given as raw counts rather than percentages. A percentage implies a precision that twenty attempts do not have.