Forem: Ofer Shapira

I Built a Dozen Projects Without Writing Code (With Sticklight AI) - Here's What I Learned:

Ofer Shapira — Mon, 09 Mar 2026 20:23:23 +0000

The Problem Every Non-Developer Knows

You have an idea. You get excited. You ask a developer how much it costs.
Then you quietly close your laptop and pretend you never had that idea.

I've been there. Multiple times.

Then I Found Sticklight

Sticklight is an AI-powered builder where you describe what you want in plain English (or any language — it even works in Hebrew), and it builds a fully working website, app, or game for you. In real-time. With hosting, database, the whole stack.

No templates. No drag-and-drop. You just... describe it.

What I've Built So Far

Here are some examples of things I built in minutes:

🎮 A Tetris game
🛒 An e-commerce store
🌍 A 3D solar system visualization
🧰 A developer tools page
📝 Multiple landing pages

I recorded a video walkthrough showing these + a live build:

What Surprised Me

The AI doesn't just generate a static page — it handles the full stack. Things that would normally require:

Hosting setup
Domain configuration
Database
Backend logic

...are all handled automatically.

How to Try It

Free tier: 5 AI credits per day, no credit card needed
Pro plan: ~$14/month (custom domain, 200 credits/month, full code access)
I have a 25% discount code: OFERS25 (valid through March 31)

👉 Try Sticklight

Have you tried AI builders? I'm curious what other tools people are using and how they compare. Drop a comment!

Your AI Agent Can Now See Your Real Browser (And This Post Was Written With It)

Ofer Shapira — Mon, 09 Mar 2026 12:32:41 +0000

Your AI Agent Can Now See Your Real Browser (And This Post Was Written With It)

You ship a fix. Your agent says "done, please verify." You alt-tab to Chrome, navigate to the page, log in, click around. Your agent just wrote the code — it could verify it too. It already has your browser open. It just couldn't see it.

Until now.

Real Browser MCP is an MCP server plus a Chrome extension that gives your AI agent control of your actual browser. Same tabs, same cookies, same logins. No headless browser. No replaying auth every time you want a quick "did the button work?" check.

Why existing tools fall short

Playwright MCP and Chrome DevTools MCP launch a new browser. Fresh profile, no state. For anything behind login — your app, internal tools, social accounts — you're stuck replaying the full flow. That's fine for isolated E2E tests. It's useless when you're iterating with an agent and just want it to look at the page you already have open.

Real Browser MCP is different. The extension runs inside the Chrome you're already using. The MCP server talks to it over a local WebSocket. Your agent can snapshot the page, click, type, scroll, take screenshots — all through the browser you're already using.

What you need

MCP server — one line in Cursor (or Claude Desktop, Windsurf): npx -y real-browser-mcp
Chrome extension — install from the Chrome Web Store

That's it. Green dot in the extension popup = connected. Your agent can now see your browser.

Dog food

I use this every day. And yes — this post was written and published using Real Browser MCP. The agent had the draft, navigated to dev.to/new, filled the form, and hit Publish. Same browser where I'm already logged in.

Real Browser MCP on GitHub · Chrome Web Store · MIT, open source.

The Developer Who Burned $1,500 in One Day on Cursor Without Knowing It

Ofer Shapira — Sun, 08 Mar 2026 16:37:35 +0000

We use Cursor at our company on a shared Enterprise account. One budget, one blanket that every developer pulls in their direction. Staying within budget is a challenge every engineering team is dealing with right now.

What Happened

Engineering costs used to be two things: headcount and cloud infrastructure. You had tools for both. Then AI coding assistants showed up, and suddenly there's a third cost center that nobody has good tooling for.

There's also model inflation -- it's genuinely hard to tell which model is better, cheaper, or more expensive. The names don't help. So one developer, in all innocence, picked a model with "Fast" in the name thinking it was the lighter, cheaper option. Turns out it was 10x more expensive per request than what everyone else was using.

$1,500. One day. Nobody knew.

Cursor's Dashboard Won't Save You

Cursor gives you an admin panel with raw usage numbers. But it won't tell you when something is off. No anomaly detection, no alerts, no spending limits per developer. You find out about cost spikes when the invoice arrives -- weeks after the damage is done.

For a company with 50, 100, 500 developers, this is a serious blind spot.

So We Built Something

After paying our tuition, I decided to build a monitoring tool that connects to Cursor's Enterprise APIs, runs anomaly detection, and sends Slack alerts when something looks off. When a developer's daily spend spikes to 4x their average, we know within the hour, not next month.

Here's a 90-second demo of how it works:

But monitoring was just the beginning. The dashboard now answers questions we didn't even know we had:

Cost monitoring -- who's spending how much, on which models, and is it reasonable?
Adoption tracking -- is everyone actually using the tool we're paying for? We found "empty chairs" -- developers with active licenses who weren't using Cursor at all.
Model optimization -- which models cost more and which cost less, shown with actual per-request pricing from your own usage data.
Team comparison -- how does each team's usage compare, and where are the optimization opportunities?

Thanks to this tool, we could figure out which models to recommend, which to block, and how to use Cursor more effectively across the entire dev department.

Open Source

I built it open source so any team dealing with the same problem can deploy it themselves. It's a Next.js dashboard backed by PostgreSQL, self-hosted with Docker, takes about 10 minutes to set up.

MIT licensed, free forever: cursor-usage-tracker on GitHub

The Question Every Engineering Leader Should Be Asking

AI coding tools are becoming a real cost center -- right alongside headcount and cloud infrastructure. But unlike AWS or GCP, there's no mature observability tooling for this category yet.

If your team is on Cursor Enterprise, ask yourself: do you know how much each developer is spending? Do you know which models they're using? Would you find out if someone accidentally switched to a model that costs 10x more?

If the answer is no, you might want to check your bill.

8 README mistakes killing your GitHub stars (and how to fix them)

Ofer Shapira — Sat, 07 Mar 2026 17:45:38 +0000

Your code is great. Your README is costing you stars.

I maintain 40+ open source projects on GitHub. After watching which ones get traction and which ones die in silence, the pattern is clear: the README makes or breaks it. Not the code quality, not the test coverage, not the CI badges. The README.

Here are 8 mistakes I see constantly, and what to do instead.

1. Leading with a description instead of a hook

What people do:

MyLib is a utility library for JavaScript.

Nobody cares. That tells me nothing about why I should pick this over the 500 other JS utility libraries.

What works:

Parse, validate, and transform dates in 400 bytes. No Moment, no Luxon, no dependencies.

Lead with the value. What pain does it kill? How small or fast is it? Give me a reason to keep reading in the first line.

2. No visual, no click

People scroll past text. They stop for images.

If your project has any kind of UI, a demo GIF is mandatory. For CLI tools, use asciinema or VHS. For web apps, record a short browser demo. For libraries, show code + output side by side.

Put the visual right after your hook, before the feature list. That's the best spot on the page.

3. Badge spam

I've seen READMEs with 12 badges. "Made with love", "code style: prettier", "contributions welcome", three different CI statuses.

Badges should signal project health at a glance. Stick to 3-5:

npm version - proves it's published
CI status - tests pass
TypeScript - type safety signal
License - MIT/Apache so people know they can use it
Bundle size - only if size is a selling point

Every badge beyond that is noise.

4. Making installation take more than 30 seconds

From landing on your README to running code should take under 30 seconds.

npm install your-package

import { thing } from 'your-package';
const result = thing({ option: true });

Done. No "first make sure you have Node 18+" preamble. No "clone the repo and build from source." The fastest path from zero to working code.

5. Writing for readers instead of scanners

Developers don't read READMEs. They scan them. Long paragraphs get skipped entirely.

What works:

Bold the key terms in the first sentence of each section
Use tables for API options instead of nested lists
Keep paragraphs under 3 sentences
Use code formatting for anything technical
GitHub Alerts (> [!TIP], > [!WARNING]) for callouts

If someone skimming for 10 seconds can figure out what your project does and how to install it, you've won.

6. Ignoring SEO entirely

Your README is indexed by Google, GitHub search, and increasingly by LLMs. Structure matters.

One H1 (project name), H2s for sections, H3s for subsections. Don't skip levels.
Alt text on images that describes what they show, not just "screenshot"
Mention the problem domain in the first paragraph. "React hook for form validation" beats "a utility for validating things"
Add a FAQ section. Both LLMs and Google love Q&A format.

A well-structured README ranks better than a bare repo with just code.

7. The 500-line README

If your README needs a table of contents, most of it should be in /docs. The README is a landing page, not a manual.

Keep the main scroll path lean. Use <details> blocks for verbose content like full API references or advanced config.

8. Outdated examples

This one is silent killer. Your API changed 3 months ago but the README examples still show the old API. Someone copies the code, it breaks, they close the tab and never come back.

Pin your README examples to real tests when you can. At minimum, try running them after every major change.

The tool I built for this

After writing 40+ READMEs by hand, I got tired of juggling badge URLs, table alignment, and pushing to GitHub just to check rendering. So I built README Builder - a visual drag-and-drop editor.

You drag blocks (headings, badges, code, tables, images, alerts) into place, see exactly how GitHub will render them, and copy the markdown when you're done. Free, open source, no login.

If this post was useful, give it a try: ofershap.github.io/readme-builder

The full best practices guide is also built into the app: README Best Practices Guide

ofershap / readme-builder

Visual drag-and-drop README editor with live GitHub-flavored preview. SEO-optimized templates, 15+ block types, import/export markdown.

readme-builder

Stop writing markdown by hand. Drag blocks, get a README.

Visual editor that turns drag-and-drop blocks into GitHub-flavored markdown.
Live preview, templates, import from GitHub repos, export when you're done

Your README Shouldn't Take Longer Than Your Code

You just built something cool. Now you need a README, and suddenly you're juggling markdown syntax, badge URLs, table alignment, and GitHub-flavored quirks. You know the drill:

Copy-paste badge URLs from shields.io, typo the repo name, debug for 10 minutes
Manually align tables, forget a pipe character, the whole thing breaks
Check how the markdown renders by pushing to GitHub and refreshing

README Builder gives you a visual canvas where you drag blocks (headings, badges, code, tables, images, alerts) into place and see exactly how GitHub will render them. When it looks right, copy the markdown or export the file. Done.

Features

15 block types	Headings, badges, code, tables, lists, images,

…

View on GitHub

I built a visual README builder so you never have to write raw markdown again

Ofer Shapira — Sat, 07 Mar 2026 11:06:00 +0000

The problem

Every developer knows the pain: you build something cool, then spend 30 minutes fighting with markdown. Badge URLs with typos. Tables that break because you forgot a pipe character. Pushing to GitHub just to check if it renders correctly.

The solution

I built README Builder -- a visual drag-and-drop editor that generates GitHub-flavored markdown.

Features

15+ block types -- headings, badges, code, tables, lists, images, alerts, collapsible sections, and more
Live preview -- see exactly how GitHub will render your README
Badge editor -- visual builder with shields.io integration, color picker, logo selector
Import -- paste markdown, upload a file, or fetch any GitHub repo's README
SEO-optimized templates -- proper heading hierarchy, descriptive alt text, FAQ sections
Undo/Redo -- full history with Cmd+Z
Dark/Light preview -- toggle to match GitHub's theme

Tech stack

React 19, TypeScript (strict), Tailwind CSS 4, Vite 7, Zustand + zundo, CodeMirror 6, @dnd-kit, react-markdown + remark-gfm

Try it

It's fully client-side, no backend, no login, no tracking.

Live: ofershap.github.io/readme-builder
Source: github.com/ofershap/readme-builder

Would love to hear what block types or templates you'd want added.

I Built a Cursor Plugin to Track My Team's AI Spend From the IDE

Ofer Shapira — Thu, 19 Feb 2026 22:17:46 +0000

I manage a Cursor Enterprise team with 50+ developers. AI spend has become the new cloud cost problem, except there's no Datadog for it. You find out about cost spikes when the invoice lands, weeks after the damage is done.

Cursor has an admin dashboard, but it shows raw numbers. It doesn't answer questions like "why did our spend jump 40% last Tuesday?" or "who switched to Opus and tripled their daily cost?"

So I built a Cursor plugin that wraps the Cursor Enterprise API as MCP tools, so my AI agent can answer those questions for me, right in the IDE.

A Cursor MCP server for enterprise usage and spending data

cursor-usage is a Cursor plugin (also works with Claude Code) that exposes the full Cursor Enterprise Admin and Analytics APIs through the Model Context Protocol (MCP). If you're not familiar with MCP, it's the standard that lets AI agents call external tools. In this case, the "tools" are your team's spending and usage data.

You install the plugin, set your API key, and start asking questions in natural language.

It includes:

An MCP server with 15 tools covering team members, spending, daily usage, billing groups, per-request events, DAU, model adoption, agent edits, tabs, MCP usage, and more
Two skills that teach the agent how to interpret Cursor Enterprise data correctly and how to optimize AI costs
Commands for quick access: /usage-report, /spend-check, /model-audit
Composite tools like get_team_overview and get_user_deep_dive that combine multiple API calls into a single useful answer

Install is one line:

/add-plugin cursor-usage

Or if you prefer manual MCP server setup, it's just an npx command in your config:

{
  "mcpServers": {
    "cursor-usage": {
      "command": "npx",
      "args": ["-y", "cursor-usage-mcp"],
      "env": {
        "CURSOR_API_KEY": "your-api-key-here"
      }
    }
  }
}

Understanding the Cursor Enterprise API gotchas

Anyone can call REST endpoints. The real work was figuring out what the numbers actually mean, because the Cursor API data is misleading without context. Here are some of the gotchas I ran into:

totalLinesAdded is not an AI productivity metric. It includes manual edits, tab completions, and agent-generated code all lumped together. If you want to know how much code AI actually contributed, you need acceptedLinesAdded. And even that's incomplete because agent mode auto-applies changes, so those lines don't show up in the acceptance count.

spendCents includes the subscription amount. A user showing $50 in spendCents with $40 in includedSpendCents only has $10 in actual overage. I've seen people freak out about a user "spending $200" when most of it was covered by the plan.

A single user switching from Sonnet to Opus can 10x their daily spend. Premium models like Opus and GPT-5 cost roughly 10-50x more per request than standard models like Sonnet or GPT-4o. One developer experimenting with Opus for a day can look like a cost anomaly.

Spend limits don't mean what you think. Setting a hard limit of $0 means "no overage allowed," not "no usage allowed." The user can still use their included allocation.

The acceptance rate formula is wrong if you use the obvious one. acceptedLinesAdded / totalLinesAdded is misleading because the denominator includes manual edits. The real AI acceptance rate is totalAccepts / totalApplies.

These gotchas are now encoded in the plugin's skills, so the agent knows about them before it even looks at your data. When someone asks "are we getting value from AI?", the agent knows to check acceptance rates (healthy teams see 40-70%) and cross-reference with model costs, not just report raw line counts.

Architecture: why a local MCP server, not a hosted service

A few choices I made and why:

stdio MCP, not HTTP. The server runs locally on the user's machine. No hosted service, no data leaving your network. You provide your own API key. This was important because the data includes individual developer spending and usage patterns. Unlike hosted solutions like Vantage, your data never touches a third-party server.

Zod validation on all inputs. Every tool validates its arguments with Zod schemas. Dates must be ISO format, emails must be valid, page sizes have bounds. The agent can't accidentally send garbage to the API.

Composite tools for common queries. Instead of making the agent figure out that "give me a team overview" requires calling 4 different endpoints, get_team_overview does it in one call. Same for get_user_deep_dive. These save tokens and reduce the chance of the agent getting confused mid-chain.

Cross-platform from day one. The plugin works as a Cursor marketplace plugin, a Claude Code plugin, or standalone via npx. The MCP server is the same regardless of which client runs it.

From quick questions to a full AI cost management dashboard

The plugin is great for quick questions, but it has limits. The Cursor API only goes back 30 days for analytics. You can't do anomaly detection in a chat window. You can't set up automated alerts.

That's where cursor-usage-tracker comes in. It's the full open-source dashboard I built for the same problem: automated data collection, three-layer anomaly detection (thresholds, z-score, and trend analysis), Slack and email alerts, incident lifecycle tracking with MTTD/MTTI/MTTR, and a web UI with charts.

The plugin is the quick entry point for Cursor Enterprise cost tracking. When you hit its limits, the dashboard is there. They work together or separately.

Getting started with cursor-usage

Install: /add-plugin cursor-usage (or manual MCP setup above)
Set your Cursor Enterprise Admin API key
Ask questions: "How much did my team spend this week?", "Who's using the most expensive models?", "Run a model audit"

The skills and commands are included automatically with the plugin install.

What's next

Submitted to the Cursor marketplace
Planning to submit the analysis skill to anthropics/skills
Adding more composite tools based on feedback
Exploring the newer per-user analytics endpoints

If you're managing a Cursor Enterprise team and want to try it out, I'd love to hear what queries you find most useful.

Links:

Plugin: github.com/ofershap/cursor-usage
npm: cursor-usage-mcp
Dashboard: github.com/ofershap/cursor-usage-tracker