Kalce AI

AI content, by design. An open-core canvas for building visual workflows that generate images, video and text with any model you choose.

Responsibilities: Product, research, architecture, UI/UX, engineering
Stack: Next.js, Supabase
Year: 2026

---

Every model wanted a subscription. I just wanted to try them.

New image and video models were shipping every few weeks, and each one lived behind its own app, its own credit system and its own monthly plan. To compare three models on the same prompt I needed three accounts, three token balances and a spreadsheet to remember which output came from where.

Most of those providers also expose an API. Paying per generation with my own key was cheaper and had no artificial limits. What was missing was a place to use those APIs together.

Kalce started as that place, for me only.

A raw tool for personal use

The first version was deliberately rough. A few hardcoded calls to the models I wanted to test, a prompt box, and a grid of results. No accounts, no storage, keys in a local config file.

It did its job, and it showed me the real pattern in how I worked. I rarely ran a single prompt. I chained steps: write a prompt, generate an image, upscale it, animate it into a short clip. I was building pipelines by hand, one copy-paste at a time.

That pattern became the product: a visual canvas where each step is a node, and a workflow is just nodes connected together.

Research: where Kalce fits

Before scaling the idea, I mapped the space. Node-based tools for AI generation already existed, but they split into two camps:

• Local and technical. Powerful graphs, but tied to your own GPU and a steep setup curve.
• Hosted and closed. Polished canvases, but locked to the platform's credits, model list and pricing.

Nobody was combining a hosted, designer-friendly canvas with full freedom over where the generation actually runs. That gap defined Kalce's position: provider-agnostic, bring your own key. Use an external API, your own model instance, or a third-party provider, and pay them directly.

From tool to product

Once the canvas worked, the scope grew in steps, each one forced by the previous:

• Agnostic nodes. The first nodes were tied to specific models. Every new model meant a new node. I rebuilt them around capabilities instead (text-to-image, image-to-video, upscale), with the provider chosen per node.
• Multiple providers. External APIs, self-hosted instances and aggregator platforms all plug into the same node, behind one adapter interface.
• Bucket storage. Generated assets outgrew the browser. Every output now lands in object storage, so workflows can reference earlier results and nothing is lost on refresh.
• Google login. Accounts made workflows, keys and history persistent across devices.
• Open core. The engine and node system are open source. Hosted features, team workspaces and managed infrastructure form the commercial layer.

What began as a weekend utility became a full-featured open-core product, built with a Series A trajectory in mind.

Planning for agents

Kalce was built with AI agents doing most of the implementation. The work that mattered most happened before any code was written.

For every feature I wrote a plan: the goal, the architectural constraints, the interfaces it touches, and what it must not break. Bigger changes got a written architecture decision first, so the agent worked inside boundaries I had already set rather than inventing new ones. Plans were split into small, verifiable steps, each with a clear definition of done.

That discipline is what let the codebase grow from a script into a multi-provider platform without collapsing. Agents are fast, but they follow the shape you give them. The architecture had to be explicit enough to be followed.

Architecture

The core decisions:

• Nodes as typed contracts. Each node declares its inputs and outputs (text, image, video, parameters). The canvas only allows connections between compatible types, so a workflow that can be drawn is a workflow that can run.
• Provider adapters. Every provider is wrapped in an adapter that translates one common request format into its own API. Adding a provider means writing an adapter, not touching nodes or the canvas.
• Workflows as graphs. A workflow is a directed graph executed in dependency order, with independent branches running in parallel.
• Bring your own key. User keys are encrypted at rest, and requests go straight to the provider. Kalce never resells tokens.
• Storage by reference. Nodes pass references to assets in the bucket, not the files themselves, which keeps large video outputs out of the execution path.

What's next

Kalce is coming to GitHub soon, along with a hosted alpha.

Your models. Your keys. Your workflow.