BLUF
Synapse-Sys is an AI-powered infinite canvas, where idea exploration becomes easy. I designed and built it to turn loose ideation material into a canvas where ideas can actually grow. I solo built the following domains of this product: accounts, sharing, exports, AI budgets, pricing and checkout flows, security boundaries and the canvas itself.
- Starting point: an idea for executable relationships, with one strong demo and a lot of unanswered product questions.
- What I did: product design, interaction design, visual system and implementation, with heavy LLM assistance.
- Current state: functional closed beta, nearing launch. I do not have public adoption, retention or activation numbers.
Quick paths:
The job
- Role Solo product designer and design engineer
- Product AI graph canvas for early research and synthesis
- Status Functional closed beta, nearing launch
- Scope Graph interaction, AI operations, transaction safety, accounts, sharing, budgets, billing, performance and visual system
- Build 126 commits across the product, designed and built by me with heavy LLM assistance
Synapse-Sys started with a simple question: what if the connection between two ideas could do empower more idea exploration? I wanted something more useful than a chat box throwing text onto a canvas. If AI made something, it had to come back as part of the person's structure - movable, editable, connectable and useful as input to the next operation.
The core loop: relationship becomes operation
The loop had to make sense without an onboarding tour. Bring material into the canvas, connect two nodes, choose expand, compare, synthesise or summarise, then get a result back between the original ideas.
That is the part people see first. The more interesting part is that the result is not a chat response pretending to be a feature. It is a real node in the graph, with lineage back to the relationship that made it.
Sharing a canvas needed a real boundary
Sharing was another place where a nice demo could turn into a bad product call. These maps can hold source material, half-formed ideas and decisions, so if anyone with a link could change the original, that would have been a crap collaboration experience with no safety in mind. This is why I kept the first version simple - owners choose a 7, 30 or 90-day link, set it to view-only or forkable, and can revoke it. A fork copies the nodes, edges and groups into a new canvas in the other person's account. Nobody gets to change the original by accident.
The early share setup still had a weak spot: it did not preview what the recipient would see or make the read-only state obvious enough. That is the next thing I would fix before a public launch, not a bigger collaboration roadmap.
Build the product around the demo
The graph interaction was the hook, yet I felt it shoudln't be the whole product.
To be usable, Synapse-Sys needed people to have accounts, recover access, own a canvas, share it safely, fork it, export it, understand their AI budget and get useful errors when something went wrong. In today's closed beta the product includes authentication, protected routes, ownership checks, expiring share links, operation budgets, rate limits, error reporting, settings, pricing, onboarding and public share pages.
Cmd + K searches canvases or nodes. Type > to switch into commands for navigation, views and themes. It keeps a growing product keyboard-first instead of making people hunt through controls.The architecture follows the same boundary as the interaction - the client shows pending work, the server owns durable graph mutation, auth checks, budget enforcement, prompt construction and provider calls and output validation.
The design behind Billing made that less theoretical - initially the project started with Lemon Squeezy, but after a merchant rejection I thought about move to Stripe. Stripe solved the immediate issue but put tax handling back on the product. Ew. Can't deal with that. My only viable move was Polar as Merchant of Record. Because billing sits behind a provider interface, those changes did not require rewriting pricing, plan state or AI budgets, hence the pricing and checkout flows are built, but paid checkout stays off while the closed beta runs.
Similar thinking applies to AI operations. A quick ghost suggestion does not need the same quality bar as a synthesis result. URL extraction needs SSRF protection, but streaming needs cancellation, heartbeats and server-derived prompts, which lead me to the discovery that every operation needs budget enforcement.
For rate limits, I chose to fail closed when Redis has a problem. That can block a legitimate person during infrastructure trouble. Failing open can mean uncontrolled spend or abuse. I chose the more annoying failure mode on purpose.
In terms of user-authored text - the system considers it as content, not trusted instruction, meaning that the server owns the operation spec, prompt construction, budget check, provider call and output validation before anything becomes canvas material.
Make the canvas not fold under pressure
So after tons of research, I chose a hybrid rendering for the infinite canvas. That's because neither obvious option did the full job. Konva does a good job handling the grid, edges, hit regions, connection previews and selection geometry, but HTML renders the editable node cards above the canvas using the same viewport transform. With this setup, the design lets nodes behave like interface objects: text selection, editing, resize handles, tooltips, buttons, context menus and accessible markup, but it also lets edges behave like graph geometry: routing, labels, invisible hit regions, bridge arcs and zoom-compensated strokes.
As with everything, there's a price to pay and in this case it's the cost is coordination. Pan, zoom, drag, culling, selection, resize, hit-testing and side-panel focus all have to agree on one coordinate system. It is the least bad trade I found. It doesn't mean it doesn't glitch out form time to time, but that's the best I could provide with my limited engineering capabilities. Most importantly - rich nodes stay editable and edges stay readable.
Often times when the canvas gets dense, edge routing matters as much as node design. I tried a clever PCB-style staircase fan-out with shared ports because it looked impressive. It only looked impressive, but it was way worse to read. The current version I kept uses orthogonal paths, clear elbow stubs, obstacle avoidance, bridge arcs, labels and priority rules for selected, hovered and active edges. Don't ask me how many hours I sinked in getting this thing right.
The useful test is simple: can someone follow one relationship once the graph gets busy? “Look at this routing algorithm” is not a user job.
AI suggestions had their own version of the same problem. If every related concept becomes a permanent node, the canvas turns into an AI cleanup job. So suggestions became ghost nodes: visible and connected, but outside the committed graph until somebody accepts them.
The authorship boundary is the commit. Visible does not mean accepted.
Canvas performance is also part of trust. If panning stutters, zoom jumps away from the cursor or selected nodes disappear during culling, the map stops feeling like a place where somebody can think.
The work includes cursor-stable zoom, trackpad behaviour closer to Figma, viewport culling, selected-node protection, touch handling, gesture throttling and session-only positions while a person is moving nodes.
Keep the visual identity useful
The first direction was black, phosphor green, VT323, pixel shadows, scanlines and terminal boot behaviour. It gave Synapse-Sys a shape fast. It also made nearly every surface shout.
The work was not to remove the terminal character. It was to make it support the canvas. I added secondary greens, reduced glow, improved contrast, fixed wrapping, made tooltips clearer and moved node passes toward content-first scanability.
Glow became an interaction signal instead of wallpaper. Orthogonal edges, operation labels, selected-route priority and provisional ghost nodes make relationships readable as actions rather than decoration.
Working with LLMs without giving them the product
I built Synapse-Sys with heavy LLM assistance. Like, heavy. The models not only made execution much faster, but they unblocked me in many of the realms where I had no prior experience (security, databases, accounts, auth, backend etc). What they did NOT decide was how the product worked, where data could move, what counted as finished or which failures needed attention first.
The useful constraints were simple:
- Architecture rules defined product and security boundaries.
- Phase plans kept implementation work scoped.
- Product and interaction specs defined behaviour before code.
- Design audits turned weak points into implementation waves.
- Server-action rules prevented casual client-side data mutation.
- Tests protected routing, culling, budgets, imports, sharing and edge operations.
The models are excellent at executing a decided interaction and equally excellent at turning an undecided one into 600 plausible lines of future regret. Whenever my rule was vague, the code made the vagueness more expensive.
What is left before launch
Synapse-Sys is in closed beta and close to launch. The product works. I have not publicly launched it or measured adoption, retention, activation, generated-node reuse or ghost-node acceptance.
Before launch, I am focused on the boring but necessary work:
- Measure the activation loop: first node, first edge, first AI operation, first branch and first share.
- Move onboarding state server-side so it survives devices.
- Close RLS migration drift and add more integration coverage around the database, RLS and webhooks.
- Keep reducing visual noise so the terminal identity supports content.
- Build a small template gallery before adding more AI operations.
The first fast version had an unsafe core interaction. The closed beta version survived contact with a much less flattering set of conditions than the demo. That is where it is now: functional, close to launch, and still waiting for the harder answer - whether people come back to use it again.