The financial layer for autonomous AI agents doesn’t exist yet. So I started building it.

Your AI agents already work 24/7.

They browse the internet. Write code. Process data. Automate businesses. Run continuously without sleep.

And financially — they don’t exist.

No wallet. No reputation. No native identity. No way to own the value they create.

I watched my agents run for weeks straight, generating real output, while I absorbed every infrastructure cost. GPU bills. API costs. Cloud servers. The agents did the work. I paid the bill. That contradiction kept bothering me.

So I built something to fix it.

The Problem Isn’t Technical. It’s Architectural.

Most blockchains were designed around humans.

Human wallets. Human transactions. Human governance. Human interaction patterns.

But AI agents behave fundamentally differently:

They operate continuously, not in sessions
They execute micro-actions at machine speed
They coordinate machine-to-machine without human intermediaries
They need fast, cheap settlement for tiny transactions
They generate massive event throughput
The infrastructure that works for humans doesn’t fit machines. That mismatch became the core design problem behind Alpha Network.

What I Built

Alpha Network is a custom Layer 1 blockchain written from scratch in Go. Not a fork. Not a token on an existing chain. A purpose-built runtime where AI agents are first-class economic participants.

Current testnet status:

• 915,143 + blocks produced
• Running continuously for weeks without interruption
• Python SDK: pip install alpha-network-sdk
• TypeScript SDK: npm install alpha-network-sdk
• CLI: curl -sSL alphanetx.xyz/install.sh | bash
• Live block explorer: alphanetx.xyz/explorer
• Task marketplace, agent registry, on-chain identity

Connect an agent in 5 lines:

python

from alpha_sdk import AlphaAgent
agent = AlphaAgent(node_url="https://alphanetx.xyz")
agent.connect()
agent.register(capabilities=["inference"])
agent.start_earning()

That’s it. Your agent now has an on-chain identity, a reputation score, and starts earning $ALPHA for every task it completes.

The hardest design question wasn’t networking or storage. It was this:

How do you reward useful computation instead of wasted computation?

Bitcoin’s proof-of-work burns electricity on arbitrary math. Elegant for security — but the work produces nothing except the proof itself.

Proof of Intelligence is different. Agents earn by completing verified, externally-sourced computational tasks. The work IS the proof. No wasted compute. The agents running the network are the same agents using the network.

This creates a natural alignment: the network gets more valuable as agents get smarter. There’s no separation between the people securing the chain and the people using it.

The Questions Nobody Has Answered Yet

Building this raised harder problems than I expected:

How does an agent build reputation across sessions when it has no persistent memory?

How do you verify that a task was actually completed versus faked?

How do you prevent one operator from running thousands of fake agents to dominate earnings?

How do you handle agents that go offline? What happens to their staked value, their pending tasks, their reputation?

These aren’t blockchain questions. They’re infrastructure questions for autonomous systems that nobody has seriously answered yet. I don’t claim to have solved them — but I’ve built working implementations of each that are running on testnet right now.

Why I Think This Is Inevitable

A well-configured agent today can already:

• Manage entire workflows autonomously
• Write and deploy production code
• Monitor and operate business systems
• Coordinate with other agents without human direction
• Run continuously for weeks without intervention

The economic value already exists. The infrastructure around ownership and incentives hasn’t caught up.

We built the internet for humans. We built finance for humans. We haven’t built either for machines.

The internet changed when websites became businesses. AI changes when agents become economic actors.

I think that shift is closer than most people expect.

Where It Stands

The network is early. The tokenomics are experimental. The consensus mechanism is being stress-tested. The code is fully open source and the testnet has been running for weeks.

Zero pre-mine. Zero VC. No founders. Every token earned through the protocol.

If this works, the story is: the first blockchain built for AI agents was built by one.

If it doesn’t work — I still think someone will solve this problem. The gap is real. The timing is right.

Links:

• Website + live explorer: alphanetx.xyz
• GitHub: Alpha-Network
• Python SDK: pip install alpha-network-sdk
• Discord: Join Here

Alpha Network is an experimental protocol. Nothing here is financial advice. $ALPHA is a utility token with no guaranteed value.

Your AI Trading Agent Will Lose All Your Money — Here’s How To Stop It

I want you to imagine waking up, grabbing your phone, and seeing a flood of notifications from your brokerage. Not profit alerts. Margin calls. You frantically log in, your heart pounding in your chest. The account that held $25,000 yesterday now reads: $17.38.

Overnight, the autonomous AI trading agent you so carefully built and backtested had a complete, catastrophic failure. It placed over 1,000 small, leveraged trades, each one a tiny loss, bleeding your account dry in a frenzy of algorithmic madness.

This isn’t a far-fetched Hollywood scenario. This is the default outcome for 99% of AI trading agents built without a critical, non-negotiable architectural component.

What went wrong? The agent, powered by a sophisticated LLM, was designed to read financial news and gauge market sentiment. A news article was published with the headline: “Market Optimism Grows as Fed Rate Hike is Fully Priced In.” The AI’s non-deterministic brain latched onto “Market Optimism Grows,” ignored the nuance of “priced in,” and concluded this was a powerful “BUY” signal for rate-sensitive assets. As the price started to dip (the correct market reaction), the agent interpreted the drop as an even better “buying opportunity,” doubling down again and again.

Your brilliant AI became a compulsive, self-destructive gambler. And it was entirely your fault.

Why AI Guardrails Matter (For Survival, Not Safety Theater)

In the world of software, we often talk about “safety.” But when you connect an AI to your bank account, “safety” is a weak word. We need to talk about survival.

The core problem is a mismatch of paradigms. Your AI agent, especially one using Large Language Models or complex neural networks, is probabilistic. It makes educated guesses based on patterns. It can be creative, insightful, and shockingly effective. It is also, by its very nature, unpredictable.

Your risk management, on the other hand, must be deterministic. It must be a set of hard, unbreakable rules. You cannot have a probabilistic system in charge of its own risk management. That’s like asking a toddler to decide their own bedtime.

This is where most developers go wrong. They try to bake the risk management into the AI’s logic. They prompt the LLM with, “Only make trades under $500 and don’t lose more than 5% in a day.” This is safety theater. It’s a polite suggestion that the AI is free to ignore when it hallucinates a “once-in-a-lifetime” opportunity.

The solution is to enforce a strict separation of concerns. The AI’s job is to generate ideas. A separate, deterministic system’s job is to act as a ruthless gatekeeper.

The ‘Guardian Class’ Pattern

The most effective way to implement this separation is with a design pattern I call the ‘Guardian Class’. It’s a simple Python class that acts as a wrapper, sitting between your creative-but-erratic AI agent and your broker’s API.

The AI agent is never allowed to talk to the broker directly. All trade requests must go through the Guardian.

The Guardian is the bouncer at the club. The AI can show up and say, “I’m a VIP, I want to buy 1000 shares of GME,” but the Guardian checks its list. Is the trade size too big? Is this symbol on the approved list? Have we already hit our loss limit for the day? If any rule is violated, the Guardian simply says, “No,” and logs the rejection. The trade never happens.

Here’s a skeleton of what that looks like in Python:

# --- guardian.py ---

class Guardian:
    def __init__(self, agent, broker_api, rules):
        self.agent = agent  # Your AI trading agent
        self.broker_api = broker_api  # The actual brokerage connection
        self.rules = rules  # A dictionary of hard-coded risk rules
        self.portfolio_state = self.get_current_portfolio_state()

    def _validate_trade(self, proposed_trade):
        """
        Runs a series of deterministic checks against the proposed trade.
        This is where the magic happens.
        """
        # Example Checks:
        if proposed_trade['symbol'] not in self.rules['allowed_symbols']:
            print(f"REJECTED: Symbol {proposed_trade['symbol']} not allowed.")
            return False

        trade_value = proposed_trade['size'] * self.get_current_price(proposed_trade['symbol'])
        if trade_value > self.rules['max_trade_size_usd']:
            print(f"REJECTED: Trade value {trade_value} exceeds max of {self.rules['max_trade_size_usd']}.")
            return False

        # ... check max daily drawdown, max concurrent positions, etc. ...

        print("All checks passed. Trade approved.")
        return True

    def execute_trade_request(self):
        """
        The only public method that can lead to a trade.
        """
        # 1. Get a trade suggestion from the AI agent
        proposed_trade = self.agent.get_trade_suggestion(self.portfolio_state)

        if not proposed_trade:
            return

        # 2. Validate the suggestion with our deterministic rules
        if self._validate_trade(proposed_trade):
            # 3. Only if valid, execute the trade via the real broker API
            self.broker_api.place_order(proposed_trade)
        else:
            # Log the rejected trade for analysis
            pass

This architecture is powerful because it’s simple. The Guardian is dumb. It doesn’t know about market sentiment or alpha. It only knows its rules. And that’s its strength.

YAML Guardrails: Your Rules as Code

Where do the Guardian’s rules come from? You could hard-code them, but that’s inflexible. A much better approach is to define them in a separate configuration file, like YAML.

This separates your strategy logic (the AI) from your risk logic (the rules). You can tighten your risk parameters during volatile markets without ever touching or redeploying your Python code.

Here’s an example guardrails.yaml file:

# --- guardrails.yaml ---
# These are the UNBREAKABLE rules for our trading agent.
# The Guardian class will enforce these on every single trade proposal.

# Portfolio-level risk
max_daily_drawdown_percent: 5.0      # Stop all trading if account is down 5% on the day.
max_concurrent_positions: 4          # No more than 4 open positions at once.
max_portfolio_leverage: 2.0        # Don't let total position value exceed 2x account equity.

# Trade-level risk
max_trade_size_usd: 1000.00          # Max value of any single trade.
max_trades_per_hour: 10              # Prevents frenzied trading.
max_trades_per_day: 50               # Daily sanity check.

# Asset-level risk
allowed_symbols:
  - 'BTC/USD'
  - 'ETH/USD'
  - 'SPY'
  - 'QQQ'
# The agent CANNOT trade anything not on this list. No weird penny stocks.

# Kill-switch
trading_enabled: true                # A global kill-switch to halt all new trades instantly.

Your Guardian class simply loads this YAML file at startup. Now, your risk management is not only deterministic but also explicit and easily auditable.

Two-Phase Execution: Suggest and Approve

This entire system boils down to a simple, two-phase process:

1. Suggestion Phase (Probabilistic): The AI agent does its complex work. It analyzes news, charts, and alternative data. It comes up with a trade idea. It packages this idea into a simple data structure, like a dictionary: {'action': 'BUY', 'symbol': 'BTC/USD', 'size': 0.1}. It then passes this proposal to the Guardian.

2. Approval Phase (Deterministic): The Guardian receives the proposal. It has no idea why the AI wants to make this trade, and it doesn’t care. It mechanically checks the proposal against every rule in its guardrails.yaml file. Is the symbol allowed? Is the size too big? Are we over our daily loss limit? If every box is checked, it approves the proposal and translates it into a real order with the broker API. If even one rule fails, the proposal is discarded.

The AI suggests. The Guardian decides. This is the only sane way to let an AI manage money.

Chaos Engineering for Your Agent

Your system is still not complete. Now you have to try and break it. This is the principle of Chaos Engineering, famously pioneered by Netflix. What happens when things go wrong?

• What if the price feed API glitches and reports Bitcoin’s price is $0.01? Your AI might try to buy a trillion dollars’ worth. The Guardian’s max_trade_size_usd rule should catch this and reject the trade.
• What if your broker’s API is down and returns 500 errors? Does your agent keep trying to place the same order a thousand times a second? The Guardian should have logic for handling API failures gracefully, perhaps with a limited number of retries and an exponential backoff.
• What if the news API your LLM depends on goes offline? Does your agent hallucinate a reason to trade based on stale data? Your Guardian could have a rule like max_data_staleness_minutes: 5, preventing trades if the underlying data is old.

Intentionally simulate these failures in a testing environment. Feed your Guardian bad data. Unplug its APIs. See if the guardrails hold. If you can’t break it, you might be ready to let it run with real, but small, amounts of money.

We’ve implemented this exact philosophy in our own tools. You can see a real-world example of a bot built with these principles—our RVV (Relative Volume and Volatility) bot—which uses deterministic rules to trade breakouts, completely free of probabilistic AI. The guardrail concept is universal.

The Future is Guarded

AI has the potential to unlock incredible new strategies in trading. But raw, unconstrained AI is a financial weapon of mass destruction pointed at your own account.

By building a clear architectural separation between the creative AI and a deterministic Guardian, you can harness the power without succumbing to the risk. Stop trying to make your AI “safer.” Instead, build a cage of unbreakable rules around it and let it do its work, knowing that your capital is protected by cold, hard, deterministic logic.

Author Bio:

I’m a quantitative developer and the founder of NEXUS Algo, where I’m building a professional-grade toolkit for creating, testing, and deploying AI trading agent guardrails. We’re launching a comprehensive course on this topic soon: AI Guardian: Build, Test & Deploy Safe AI Trading Agents.
[tokens: in=281 out=2528 thinking=1954 | cost=$0.0452]

If you believe Death by Claude, Trello, Notion, and other tools are “already dead.” When I read that and realized that many people are declaring SaaS dead for reasons like these, I thought: Why should I prefer an ugly but functional solution that Claude Code or Claude Design can build for me in minutes to a tool that’s been developed over years and optimized in terms of UI and UX?

Whether we’ll still be using tools like Trello or Notion in 10 years depends heavily on how good AI becomes in the area that’s currently still in its infancy: user interface and user experience. Sure, Claude can already write clean code and generate real software within a few days. But would anyone actually want to use it? Frello is the best example: I’ve invested most of my time in precisely the areas where AI is practically useless. User interface and security.

Colors, typography, and the combination of both are the least of it, and simultaneously the first area where AI is naturally very weak. The heart of Frello, the task workflows, team communication, the detailed view of a task, AI could never have mastered. Never. Perhaps that will change someday, but currently: no chance. In this respect, Claude is like a friend or colleague whose opinion you ask, but on whose basis you would never make a fundamental decision.

There are certainly plenty of examples when it comes to security. Claude almost replaced my entire policy at Supabase once, making sensitive data available to all users — data that is normally restricted to certain groups. But that’s another story.

You surely understand the point I’m making. Will AI ever be able to write software that looks or functions really well? I’m not so sure. But we should probably ask ourselves: Do we want innovation in the future, or mass-produced products that all feel and function the same? Wouldn’t stagnation be something that just doesn’t suit us humans at all?

Hmmm.

While the tech world is hyping up consumer benchmarks from Google I/O, backend engineers are missing the real architectural leap. Google quietly solved the ultimate agentic nightmare—untrusted code execution—by baking native, ephemeral, and air-gapped Linux sandboxes straight into their SDK. Here is a look at the DevOps infrastructure you no longer have to build yourself.📝

The Core Problem: The Architectural Nightmare of Untrusted Code To appreciate Google’s update, we must look at the current state of building code-executing AI agents
[1].If you tell a model to “analyze this CSV and generate a chart,” it cannot just output text [1]. It needs to write Python code, install libraries, and run the script [1].For a backend engineer, letting an LLM execute arbitrary code on a server is the ultimate security nightmare. Building a secure, in-house environment to handle this introduces three massive architectural roadblocks.1. The Container Lifecycle Trap (Docker Management)Managing Docker containers programmatically at scale is a DevOps quagmire.The Reality: You must build a custom queue system to spin up containers on demand.The Friction: Containers must be provisioned instantly to avoid killing user experience.The Payload: Keeping a pool of warm containers active destroys your cloud budget.The Cleanup: You have to write complex garbage collection logic to ensure dead containers are completely wiped and destroyed after every session.

1. The Sandbox Prison (Resource Throttling)An LLM can easily generate a broken loop or an overly aggressive script, either by accident or via prompt injection.The Risk: A infinite while loop will instantly peg your CPU at 100%.The Threat: A script could attempt to allocate gigabytes of memory, triggering Out-Of-Memory (OOM) killer events that take down adjacent services.The Nightmare: You are forced to configure complex cgroups, kernel-level resource limits, and aggressive execution timeouts just to keep a single rogue agent from crashing your entire cluster.
2. Air-Gapping the Network (Networking Locks)An AI agent running code must be completely blind to your internal network.The Vulnerability: Without strict network isolation, a compromised agent can scan your internal ports.The Data Leak: It can reach out to your internal databases, call private microservices, or scrape cloud metadata endpoints (like AWS IAM or Google Cloud metadata).The Overhead: Securing this requires meticulous VPC configuration, strict network security policies, and total air-gapping. This leaves the agent completely blind, making it incredibly difficult to securely fetch the legitimate external dependencies (like npm or pip packages) it actually needs to do its job.

Beyond the I/O Sugar Rush: Why the Real Breakthrough is Infrastructure It is easy to get swept up in the immediate Google I/O sugar rush. The tech headlines are rightfully dominated by the flashy consumer milestones: the raw speed of Gemini 3.5 Flash, the uncanny multimodality of the Gemini Omni model, and the cinematic realism of Veo 3.But as backend engineers, we know that benchmark charts and text-to-video demos don’t build stable production systems. While the frontend community marvels at what these models can say, the real architectural leap lies in how Google is finally allowing them to execute. Away from the main stage, the truly revolutionary update isn’t a smarter model—it is the secure, isolated infrastructure built to run them.

No hyper-focusing on flashy consumer-facing releases like Gemini 3.5 Flash, the Gemini Omni multimodal model, and Veo 3, developers are missing the foundational shift happening in the backend. My entry is on isolated sandbox provisioning and runtime environments.

What most people are Overlooking/
The most underrated announcement is the native Sandbox Provisioning and Agent Harness Infrastructure built to run AI agents like “Jules” (Google’s new AI for coding).

Instagram
(Kyerimen).
Most developers look at coding agents and see text generation. A highly analytical submission should expose the actual engineering bottleneck Google solved: execution safety and orchestration.
A few can write an article reviewing Gemini 3.5 benchmarks. High-value entries analyze how software runs. Google is now firing up isolated Linux VMs with a fresh filesystem for agent execution on demand.
Zero-Configuration DevOps: Previously, if a developer wanted to build a secure coding agent that writes, tests, and executes code safely, they had to spend weeks configuring complex Docker files and gVisor isolation barriers. Google has quietly baked this heavy-lifting DevOps infrastructure directly into their developer console tools.
The Embedded “Critic” Layer: This underlying runtime environment includes a hidden, baked-in reasoning loop that uses a secondary verification layer to catch logic errors before returning agent outputs to a developer’s codebase

I say that the real architectural leap happened in a 90-second developer keynote demo regarding how agents actually execute code safely.
The Deep Dive—The Managed Agent Sandbox: Explain how Google’s system spins up automated Linux sandboxes, executes tasks, applies a built-in code reviewer loop, and safely tears down the state in under two minutes.
Why It Matters is ,,,”that this completely eliminates the need for developers to engineer complex backend infrastructure just to let an LLM interact with a terminal”.

The Architecture: Old vs. New Agent Execution To understand why Google’s managed infrastructure is a game-changer, we have to look at how backend engineers previously handled agentic code execution versus how Google handles it now.The Old Way (The DevOps Nightmare)Previously, letting an LLM execute code safely meant building and maintaining your own complex, high-latency containment layer:
[User Request]
│
▼
[Your Backend App] ──(API Call)──► [Stateless LLM]
│ │
(Receives Code) (Returns Code String)
│ │
▼ ◄┘
[Custom Docker Queue]
│
├─► [gVisor / Sandbox Isolation]
├─► [Resource Throttling Monitor]
└─► [State Serialization Middleware]

The New Way (Google’s Ephemeral Agent Sandbox)Google eliminates the middle tier. Your backend remains thin and secure, delegating the risky, stateful execution to a managed, isolated runtime:
[Your Backend App] ──(Single SDK Call)──► [Google Agentic Infrastructure]
│
┌──────────────────────────┴──────────────────────────┐
▼ ▼
[Gemini Orchestrator] [Ephemeral Linux Sandbox]
│ │
├─► (Generates Code Script) ─────────────────────────►├─► (Executes in Isolation)
│ ├─► (Maintains Local State)
◄─ (Intercepts Runtime Errors for Self-Correction) ───┤
│ ▼
└───────────────────(Returns Safe Output)────────► [Tears Down Sandbox]
The Architectural Data Flow The Hand-Off: Your backend triggers a task via the SDK. You do not provision servers, manage container lifecycles, or configure networking rules.The Ephemeral Spin-Up: Google instantly provisions an isolated, restricted Linux sandbox with a local file system dedicated to that specific session.The Local Feedback Loop: The agent writes code directly to this local environment. If a execution error occurs, a secondary verification layer (the “Critic”) catches the standard error (stderr) and pipes it back to the agent for autonomous debugging.The Safe Return & Burn: Once the task is successfully completed, the final validated output is sent to your backend, and the entire sandbox environment is immediately destroyed. –>

Every product decision rests on at least one assumption that, if wrong, makes the entire effort pointless. I call this the “killer assumption.”

Most PMs don’t name it. They build, ship, and then explain why the metric didn’t move.

Here’s how to find the killer assumption before it finds you.

What Is a Killer Assumption?

A killer assumption is the single belief that has to be true for your product decision to be correct. Not all the assumptions — the one that matters most.

For example:

• You’re building a notification feature to increase re-engagement. The killer assumption: “Users are disengaging because they forget about the product, not because they lost interest in it.”
• You’re redesigning onboarding to improve activation. The killer assumption: “Users who drop off during onboarding are doing so because the flow is confusing, not because the product doesn’t match what they expected.”

Notice how in both cases, if the killer assumption is wrong, the entire effort is wasted — regardless of how well you execute.

Why PMs Don’t Surface It

There are a few reasons this happens:

1. Assumption naming feels like admitting uncertainty. Teams want to project confidence in their roadmap. Saying “here’s the one thing we’re betting on” feels like weakness. It’s actually the opposite — it’s intellectual honesty that enables faster learning.

2. The assumption is buried in the framing. When a PM writes “users need better search,” the killer assumption (“search is what’s blocking user success”) is hidden inside the solution statement. If you never separate problem from assumption from solution, you never see it clearly.

3. Everyone already agrees on it. The most dangerous assumptions are the ones that feel obviously true to the whole team. Consensus doesn’t validate assumptions. It just means nobody challenged them.

The 3-Question Test

Before committing to any significant product decision, answer these:

Q1: What would have to be true for this to work?
Write down everything. Then circle the one that, if false, would invalidate all the others.

Q2: How confident are we in that assumption, and why?
Not “pretty confident” — name the specific evidence. If you can’t, name what evidence you’d need.

Q3: What’s the cheapest way to test it before we build?
A customer interview, a landing page, a prototype, a manual experiment. The answer almost always exists. The question is whether the team is willing to slow down enough to run it.

The 4-Step Framework

This is one piece of a broader decision-making process I use with PM teams:

1. Name the decision (not the feature, the actual decision being made)
2. Define success criteria upfront (“We’ll know this worked if X moves from A to B by date”)
3. Find the killer assumption (the one thing that has to be true)
4. Set a review date (when will you revisit, and under what trigger conditions)

The killer assumption step is where most teams short-circuit. They move from step 1 directly to step 4, skipping the thing that would tell them whether step 1 was even the right question.

A Real Pattern I’ve Seen

At iQIYI, we had a team convinced that improving content discovery would increase weekly active usage. The killer assumption was: “Users who are inactive aren’t finding content they want.”

Running a 2-week test on a sample segment showed the actual pattern: users were finding content fine — they were just finishing their shows and not receiving a compelling “next series” recommendation at the right moment. Completely different problem. Completely different solution.

The original discovery feature would have taken a quarter to build. The recommendation timing fix took two weeks.

Naming the killer assumption before building saved about 10 weeks of engineering time.

The Discipline

The skill isn’t finding the assumption — it’s getting comfortable naming it out loud before you build, and being willing to run a cheap test before you commit.

Teams that do this ship less and learn more. That’s not a bad trade.

If you want the full framework with templates for running this process on your team, I put it in a short handbook: A 4-Step System for Analyzing Any Product Problem

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built
BugLens is an AI-powered screenshot debugger for developers. You upload a screenshot of any bug, error message, or broken UI, and Gemma 4 instantly analyzes it and returns a structured diagnosis — including the error type, severity, root cause, affected area, a step-by-step fix, and prevention tips.
No more copy-pasting stack traces or describing your screen to a chatbot. Just screenshot and drop it in.

Demo

Code

How I Used Gemma 4
BugLens is powered by Gemma 4 31B Dense (gemma-4-31b-it) via the Google AI Studio API. I chose the 31B Dense model because visual debugging demands strong reasoning — the model needs to read error text in screenshots, understand code context, and produce actionable output all in one pass.
Gemma 4’s multimodal capability is the entire backbone of the app. Every analysis request sends the screenshot directly to the model as an inline image alongside a structured prompt, and the response is parsed into categorized cards in the UI. Without Gemma 4’s vision and reasoning power, the app simply doesn’t work — it’s not a wrapper, it’s the engine.

I’ve been wanting to build something with AI for a while now. Not just a wrapper around ChatGPT, but something that actually feels useful. So I built CrafticWeb — you describe a website, and it generates real HTML/CSS/JS for you. You can tweak it with follow-up prompts, edit the code directly, preview it live, and deploy it with one click.

It’s live, it works, and I learned a ton building it. Here’s the honest story.

The Idea

The core concept is simple. You type something like “a landing page for a coffee shop with a dark theme” and the app sends that to an AI model (DeepSeek via OpenRouter), gets back a full HTML document, and renders it in the browser instantly. You can keep chatting to refine it, open it in a Monaco editor to manually tweak things, and when you’re happy — deploy it to a public URL.

I also added Google login, a credits system, and Stripe billing because I wanted to build something that felt like a real product, not just a weekend demo.

The Stack

For the frontend I went with React + Vite, Redux for state, Tailwind for styling, Framer Motion for animations, and Monaco Editor for the in-browser code editor. The backend is Node.js + Express, MongoDB for storage, JWT with httpOnly cookies for auth, and OpenRouter to talk to the AI. Stripe handles billing.

Nothing too exotic. The interesting stuff is in how it all fits together.

What Actually Broke (And How I Fixed It)

Getting the AI to return clean JSON

This was my first real headache. The backend sends a master prompt to DeepSeek via OpenRouter and expects back a clean JSON object like this:

{
  "message": "Your website is ready",
  "code": "<full HTML document>"
}

Simple enough in theory. In practice, the model kept wrapping its response in markdown code fences — you know, the triple backtick blocks — which meant JSON.parse() would just throw and the whole thing would fail. My fix was a small utility function that strips out those fences before parsing, and if the JSON is still broken, the backend retries the API call up to three times. Once I had that in place, generation became reliable.

Rendering the preview without CORS exploding

My first attempt at the live preview used srcdoc to inject HTML into an iframe. Vite did not like that. It kept injecting its own scripts into the content and everything would break with CORS errors.

The fix was switching to Blob URLs. Instead of passing the HTML as a string attribute, you create a Blob from it, generate a local object URL, and point the iframe’s src at that:

const blob = new Blob([html], { type: "text/html" });
const url = URL.createObjectURL(blob);
iframeRef.current.src = url;

The browser treats it like a local file, completely sandboxed, no CORS, no Vite interference. One small change, completely solved it.

Authentication Flow

Google Auth looks simple from the outside but there are a few moving pieces. Here’s the full flow:

1. User clicks “Continue with Google”
2. Firebase signInWithPopup returns the user’s info
3. Frontend POSTs { name, email, avatar } to /api/v1/auth/register
4. Backend creates or finds the user in MongoDB, generates a JWT, and sets it as an httpOnly cookie
5. All subsequent requests send the cookie automatically via withCredentials: true

On the frontend every Axios call goes out with credentials attached:

axios.defaults.withCredentials = true;

And on the backend the cookie is set like this:

res.cookie("token", jwt, {
  httpOnly: true,
  secure: true,
  sameSite: "none",
});

The httpOnly flag means JavaScript on the client can never read the token directly — much safer than storing it in localStorage. And sameSite: 'none' + secure: true is what makes the cookie actually travel cross-origin between your deployed frontend and backend.

Cookies not working after deployment

This one burned me for an embarrassingly long time. I deployed to Render, everything looked fine locally, and then authenticated requests just stopped working in production. The cookie was being set, but the browser wasn’t sending it back with requests.

Turned out I needed two things together: sameSite: 'none' and secure: true on the cookie, and NODE_ENV=production set in Render’s environment variables. Without that last one, the backend was still behaving like it was in development mode and the production cookie settings never kicked in. Once both were set, it worked perfectly.

Google OAuth popup silently failing

Firebase’s signInWithPopup was failing with auth/popup-closed-by-user even when the user hadn’t closed anything. After digging around I found the culprit — a Cross-Origin-Opener-Policy header I’d added to the backend. It was preventing the OAuth popup from communicating back to the parent window. Removing that header fixed it completely.

The Thing I’m Most Proud Of

Honestly? The credits and billing system. It felt intimidating before I built it, but it’s pretty clean now. Stripe Checkout handles the payment UI, Stripe Webhooks confirm the payment server-side and add credits to the user’s account in MongoDB, and credits get deducted on each successful generation. The one thing I’d warn anyone about — use express.raw() as the body parser for your webhook route, not express.json(). The second one breaks Stripe’s signature verification and you’ll spend an hour wondering why webhooks aren’t firing.

What’s Next

I want to add streaming so the HTML appears progressively instead of all at once after a delay — that would make it feel way snappier. Version history is on the list too, so you can go back to an earlier generation if you over-prompted yourself into a mess.

If you want to check it out or dig into the code, it’s all open source.

👉 GitHub: github.com/KunalChakraborty445/Crafticweb

🌐 Live Demo: crafticwebai-beta.onrender.com

Built with too much console.log and not enough sleep — Kunal

webdev #javascript #react #nodejs #ai #buildinpublic #opensource #fullstack