Adi Leviim | Building SaaS Products

Co-founder @ AI Toolbox - folders, search & export for ChatGPT, Claude, Gemini & Grok. 30,000+ users, $11K MRR. 3.0 hits Product Hunt Aug 23.

[Adi Leviim | Building SaaS Products @adileviim]

30,000+ people use a Chrome extension that two developers build from Israel.

Nobody has heard our story. For the next 3 weeks I am telling all of it - revenue included.

[Adi Leviim | Building SaaS Products @adileviim]

@simplydt absolutely, thanks!

[Adi Leviim | Building SaaS Products @adileviim]

Our third Product Hunt launch is in 14 hours. The night-before checklist we actually use - steal it:

1. Maker's first comment written NOW, not at 00:01. Story, not features. It anchors every reply tomorrow.

2. Gallery re-checked on mobile. Most PH voting happens on phones; a cropped screenshot costs real votes.

3. Everyone who said "tell me when you launch" gets a personal message tonight with the notify link - not a broadcast tomorrow.

4. Tomorrow's only job is answering comments. Every reply within minutes, all day. Comments rank you and become roadmap.

5. Sleep. The launch is won before launch day; nothing you do at 3am helps.

We're two developers, 23 months in. Tomorrow we find out if launch number 3 lands.

[Adi Leviim | Building SaaS Products @adileviim]

@AliceInfoAi I had to reschedule but thanks :)

[Adi Leviim | Building SaaS Products @adileviim]

the best distribution feature we ever built wasn't built for distribution.

we added a yearly usage card, a shareable "wrapped" style summary of someone's chat activity across the year, because a few people asked for a way to see their own usage stats. simple ask, we treated it like any other small feature.

turns out a shareable image with someone's own data on it is a different kind of feature than everything else in the product. folders and search are private, useful, and nobody ever shows them to anyone. a wrapped card is designed to be posted. someone's proud of how many chats they had, or thinks it's funny how many hours they spent arguing with an ai about a bug, and it goes on their own timeline with our logo sitting quietly in the corner.

no ad spend, no affiliate link, no call to action baked into it. just a personal artifact that happens to carry a mark of where it came from, the same reason spotify wrapped works and most in app share buttons don't.

the lesson wasn't "add virality." it was noticing that some features are inherently private, useful but invisible to anyone but the user, and some are inherently personal and public, about the user's own year, own numbers, own bragging rights. the second kind is worth building even if the initial request sounds small, because the sharing isn't a feature you bolt on afterward, it has to be true of the thing itself before anyone will ever post it.

if you're picking what to build next, it's worth asking which category each idea falls into. most of your roadmap should be the private, useful kind. but the rare feature that's actually about the user showing off their own data is worth disproportionate attention, because it's the only kind that markets itself without you doing anything.

[Adi Leviim | Building SaaS Products @adileviim]

@kzzy47 still me. i don't think it scales but so far every reply has surfaced something worth fixing, so i'm not in a rush to hand it off. it's the highest signal hour of my week, more useful than any analytics dashboard.

[Adi Leviim | Building SaaS Products @adileviim]

support tickets are the only marketing channel we have that compounds without spending anything.

here's the loop: someone emails a complaint, usually annoyed, sometimes rude. we read it, and if it's a real bug or a real gap, we fix it that week, not that quarter. we reply to the same person and say it's fixed. a meaningful chunk of those people go back and update their store review, from a 2 star to a 5 star, unprompted, because they didn't expect a fix to actually land.

store rating moves the store's ranking algorithm. ranking moves organic installs. organic installs bring more people who hit the same rough edges, write the same kind of complaint, and the loop runs again.

the part that took a while to internalize: the complaint itself is free market research. someone telling you exactly what's broken, in their own words, with their own workflow attached, is worth more than any roadmap meeting we could have had. we didn't have to guess what to prioritize this week, the inbox already told us.

the trap is treating support as a cost center you want to minimize, answer fast, close the ticket, move on. if you're doing that you're throwing away the input and the credit both. answering slowly or generically gets you a ticket closed. answering by actually shipping the fix gets you a public review that keeps working after you've stopped thinking about it.

it's slower than paid acquisition and it doesn't scale in the way a growth deck wants it to. but it's the only channel where the cost per acquisition goes down over time instead of up, because the fixes stack and the reviews stay.

[ℏεsam @Hesamation]

Open models passed closed models on Vercel’s token usage in August, now they’re at 62%.

AT&T cut 56% of costs by routing to cheaper models, Coinbase saved ~50% .

AND WE’RE STILL SUPER EARLY.

once a few enterprises prove the economics of using open models, this snowballs fast.

[Adi Leviim | Building SaaS Products @adileviim]

@Hi_Mrinal matches what i've seen too. we run mongodb and the one early decision that paid off was indexing by user plus timestamp from day one. saved us a painful migration once search volume grew, way cheaper than fixing it after the fact.

[Robert Youssef @rryssf]

2026 the AGENT Year

AI agents now burn 5x more tokens than humans do.

that number is from OpenRouter, and it is the cleanest summary of the last twelve months I have seen. agents did not arrive as a product you buy. they arrived as a consumption pattern, and it is already reshaping who spends what.

the part worth sitting with is how they spend it.

more than 85% of agentic token burn is CACHED prompt. you and I do prompt, response, done. an agent pre-fills the goal, the policies, the code guidelines, then reads and writes incrementally toward a result, growing that cache the whole way.

so the workload is not the reasoning. the workload is the context the agent is dragging behind it.

that single fact explains most of the market right now. it is why memory is the bottleneck everyone is suddenly bidding on. it is why cached pricing decides whether your agent is viable. it is why your context design matters more than your model choice.

here's the rest of the year in numbers 👇

→ agent token usage up ~14x since February
→ legal, of all fields, grew Codex adoption 108x since February
→ top-decile tech firms now output 32.5x the tokens they did a year ago, while the median firm merely doubled
→ n8n, Zapier and Make are all down double digits on trailing 12-week traffic

that last one is the tell. the gap is not between firms with AI and firms without. it is between firms running agents and firms still running workflows.

[Adi Leviim | Building SaaS Products @adileviim]

@lambdabetaeta what's the setup, groq or cerebras hardware? that's a big jump from typical local inference speeds.

[Adi Leviim | Building SaaS Products @adileviim]

chrome web store review rejected a release once for "broad host permissions" on a version that hadn't changed a single permission from the one approved two weeks earlier. no diff, no explanation beyond the boilerplate policy link. appeal form, three paragraphs justifying why we need access to https://t.co/AQ5BD3Y71v and https://t.co/qELKLdQhQa, submit, wait.

five days later it just got approved with no message. no acknowledgment of the appeal, no note on what changed. we never found out if a human actually read it or if it re-ran through the same automated check and passed the second time by chance.

that's the actual operating reality of shipping through someone else's store. you're not deploying, you're submitting and waiting, and the feedback loop you'd normally use to debug a rejection doesn't exist. no logs, no reviewer notes, no way to ask a clarifying question.

what we changed after: never ship a fix and a feature in the same release. if a bug is actively breaking something for users, that goes out alone, minimal diff, so if it gets flagged you're not also holding a fix hostage behind an unrelated feature review. features queue up and go out in their own release on a slower cadence, because a feature can wait five more days, a broken export for a customer who emailed you can't.

if you're building any kind of browser extension, budget review time as if it's a dependency you don't control, because it is one. it can take hours, it can take a week, and there is no dashboard telling you which one you're getting.

[SGLang @sgl_project]

Restarting a 1T model used to take 8.8 minutes, now it takes 32 seconds.

Huge thanks to the @AntLingAGI and Alibaba for the collab! Read the full write-up on how the Weight Cache Daemon works: https://t.co/B2dejhW7SJ

[Adi Leviim | Building SaaS Products @adileviim]

spent a chunk of a weekend chasing a bug where exports over a certain size would just stop, no error, partway through zipping files. turned out to be manifest v3's service worker idle timeout. chrome kills the background service worker after about 30 seconds of no activity, and a bulk export with a lot of conversations can easily run longer than that between meaningful events.

the fix isn't obvious from the docs. you can't just extend the timeout, it's not configurable. what works is keeping a port open from the content script to the service worker with chrome.runtime.connect, and having the content script send a heartbeat across it periodically. every message across that port resets chrome's idle clock, so as long as the connection stays active and something is flowing through it, the worker stays alive for as long as the job actually takes.

the part that made it hard to diagnose is that it fails silently. no thrown error, no rejected promise, the worker just gets torn down mid task and whatever it was doing stops existing. if you're building anything in mv3 that runs longer than a few seconds in the background, and it seems to randomly stop working on bigger jobs but never on small ones, check for this before anything else. it's almost always the idle timeout, not your logic.

[Adi Leviim | Building SaaS Products @adileviim]

makes sense to me. relying on someone else's closed model feels like relying on someone else's UI, it can change under you with no warning. we've been burned by that on the product side more than once.

[Guillermo Rauch @rauchg]

Today's a record day for open weight share of tokens on Vercel AI Gateway.

Aug 22 (today)
🟦 Open: 62%
🟨 Closed: 38%

Jun 24 (~2 months ago)
🟦 Open: 28.4%
🟨 Closed: 71.6%

This is very likely just the start, because enterprise adoption is still early, and harnesses, CLIs, IDEs, SDKs, etc need to be adapted to be model agnostic.

[Adi Leviim | Building SaaS Products @adileviim]

@opencode @Cloudflare curious what the actual bottleneck turned out to be, cold starts or just raw compute contention. inference workloads seem to punish autoscaling assumptions that work fine for normal web traffic.

[dax @thdxr]

we try not to have too many opinions in how agents should work

every model is intensely trained to use certain tools and workflows so we try to match that environment perfectly

you can think you came up with something better but it will just underperform

[Adi Leviim | Building SaaS Products @adileviim]

@mattpocockuk curious what you're moving to. cloud dev env, or just running everything in containers now?

[Adi Leviim | Building SaaS Products @adileviim]

@aaronrubin what surfaced that was worth the spend? curious if it caught stuff a cheaper scanner would've missed or if the cost was mostly compute time.

[Adi Leviim | Building SaaS Products @adileviim]

@agazdecki Absolutely! No time to waste

[Adi Leviim | Building SaaS Products @adileviim]

@EllaTech0 Haha trying to stay cool 😁

[Adi Leviim | Building SaaS Products @adileviim]

@acquiredotcom Very nice!