On 7 March 2025 I started a long-running experiment: build something closer to a practical Jarvis-style personal AI than a normal chatbot.

The pipeline behind the assistant

The architecture grew into speech input → transcription → model/router → memory/context → queued tool actions → confirmation gates → text or speech output.

Later versions explored Groq-based speech transcription and reasoning, local and cloud model routing, memory/context storage, browser and URL actions, queued work, and explicit permission gates.

Intent is not permission

An assistant can infer that deleting a file, sending money, or changing a sensitive setting might help. That does not mean it should have silent authority to do it.

← Back to writing index

On 30 January 2026 I started an inventory-software project. The important shift came when I stopped treating inventory visibility as the product.

From dashboard to workflow

The design moved toward store integration, safety stock, lead-time-aware stockout logic, reorder proposals, and human approval. A dashboard tells you what happened; operations software helps decide what happens next.

← Back to writing index

The concept started in December 2025: connect sellers that need distributed storage and fulfillment with people or businesses that have unused local space.

The marketplace begins after the match

The project expanded into seller and host workflows, requests, approvals, inventory states, QR-based movement, and a fulfillment lifecycle. The durable part of a marketplace is the operating system that makes repeated transactions trustworthy.

← Back to writing index

In May 2026 I built a working SaaS prototype for analyzing startup ideas, surfacing risks, generating execution plans, and tracking progress.

Speed is useful when it changes the question

Once the prototype existed, the next uncertainty was not more engineering. It was whether anyone in the target market would care enough to try it. Build fast enough to reach the next real uncertainty, then learn from it.

← Back to writing index

I explored a Shopify-oriented returns and refunds system where the interesting problem was not generating a refund decision. It was deciding when software should be allowed to act.

Rules first, AI second

Deterministic policy constraints should stay separate from softer model judgment. The system should expose the model suggestion, the applicable rules, and the final human action so consequential automation remains auditable.

← Back to writing index

Administrative actions are different from ordinary product actions. I explored that idea through a separate WebCanBe AdminKey application rather than placing every privileged operation inside the main product.

Separate capability from convenience

The application centered on explicit operation descriptions, manifests, validation, and rendered action details. Privileged actions deserve enough friction that the operator can see what will happen, which target it affects, and whether the operation matches the intended manifest.

← Back to writing index