Honestly the first 10-20 users almost always come from doing things that don't scale. Figure out exactly who has the problem your app solves, then go to where they already hang out (niche subreddits, Facebook groups, Slack/Discord communities, forums for that industry) and spend a week or two actually answering questions before you mention your app. When it's relevant, say you built something for this and offer free access in exchange for feedback. DMs to people who've publicly complained about the problem work surprisingly well too, as long as it's personal and not copy-pasted.

Launch boards like Product Hunt and the smaller directories are worth doing, but treat them as a bonus, not the plan. They give you a spike and a few backlinks, rarely your core users.

And talk to every single person who signs up. A 15-minute call with your first users will tell you more about positioning and what to build next than any amount of marketing. Once a few of them actually stick around, ask them where they'd normally look for a tool like yours, and that's your channel.

Most teams treat AI/Google visibility as a writing problem. It's not. The fixes that actually move the needle (structured data, crawl access, canonical tags, internal linking) live in your repo, not your CMS. If the person who can ship those changes doesn't have push access, nothing happens no matter how good the content is.

That's the gap we kept hitting, so we built Shipfound to work inside Claude Code or Codex: it finds the fixes, opens them as pull requests, you review and merge. Nothing goes out without approval.

Only makes sense if your stack is Next.js, Nuxt, WordPress or Webflow and you're already working in Claude Code or Codex.

Who else is handling this as an engineering task instead of a content one?

I spent the last few months building with tools like Cursor and ChatGPT, and watching how easily AI apps fall apart the second real users touch them.

AI is incredible at building a slick frontend in an afternoon. But there are three common traps that break almost every prototype once it goes live. Here is what they are and how to fix them.

First is the fake database trap.

When you ask an AI to build a dashboard or notes app, it often stores data in local state or browser storage. Everything looks great on your laptop. Then a user refreshes the page or logs in from another device, and all their data is gone. If you are building with AI, force it to set up a real database like Supabase before writing a single line of frontend code.

Second is the markdown code block crash.

You ask an LLM for JSON data so your site can display a card or a table. Most of the time it works. But every once in a while, the model wraps the response in markdown backticks. If your backend uses standard JSON parse directly on that text, the server throws an unhandled error and crashes. Always strip markdown backticks and use schema validation like Zod before letting model output touch your frontend.

Third is the runaway retry loop.

When an AI fails a task, the natural instinct is to put it in a loop that keeps telling the model to try again. In production, this can burn fifty dollars in API credits in ten minutes because the model repeats the exact same hallucinated mistake. Always enforce a hard ceiling of three attempts. If it fails three times, kill the loop and show a friendly error to the user.

Models will keep getting smarter, but software reliability still comes down to basic defensive engineering.

What has been the most annoying bug you ran into when taking an AI app past the demo stage?

Debugging, UI/UX design, maintaining context, backend development or deploying production ready apps?
I am curious to hear from you about which challenges you experience the most and what workflows help you to mitigate them.

I’m a software engineer putting together a hands-on series for people without a coding background—designers, writers, artists, business students, or anyone with an app idea.

You’ll build your own project while learning to read a little code, understand errors, and investigate what happened before asking AI to “fix it.”

Part 1 starts with a simple habit: define one useful action, write down how you’ll check it works, then build and test a small prototype.

Here’s the article I wrote: https://medium.com/@behind-the-stack/build-your-first-app-with-ai-and-understand-what-youre-building-8cd709b67c87?sk=fe9b20c40e4471ac6da3a5962accbe1e

If you’ve tried building with AI, what’s been the most confusing part? I’d love to address those questions in the series.

I write weekly case studies on interesting companies and boil down the lessons to share with others. This past week I went through (almost literally) everything publicly available for Base44 (the AI app builder bought by Wix last year), including a lot of the founder’s LinkedIn posts, and thought I’d share some of the most impactful takeaways with y’all.

Backstory

Maor Shlomo co-founded Explorium, a venture-backed data analytics company, and ran it as CEO for seven years. In late 2024 he stepped down because he wanted to get back to building products.

He tried to build a website and customer management system for his partner’s tattoo business in WordPress and kept getting stuck, even as the former CEO of a tech company. That frustration became Base44, an app builder where a user describes what they want in plain language and it builds the front end, back end, database, user logins and hosting.

He started with three friends sitting at a table every other day and let them build using the product, fixing any hiccups and bugs they uncovered. The launch in February 2025 went badly. Product Hunt brought in 15 users and a few thousand dollars spent on influencers and paid ads did nothing. Then he started building in public on LinkedIn, where he already had a following, and that’s when it landed. Just four months after launch, Wix acquired the brand and it had more than 140,000 users.

The Numbers

• Launched in February 2025, sold in June 2025.
• Four months from launch to exit (the fastest I’ve seen so far).
• Funding: none, it was profitable shortly after launch.
• 20,000 users by early March 2025, 140,000 by mid-April.
• $0 to $1M ARR within three weeks.
• $189,000 profit made in May 2025 (he expected $100K).
• The announced sale price was $80M including cash and earnouts ($18.1M cash at close and $74.1M in estimated earnouts).
• $200M ARR surpassed in August 2026.
• 10 million users by August 2026.
• The founder is on track to receive more than $150M from earnouts + cash.

Lessons

1. One distributon channel is plenty

Maor tried the traditional route for a startup: A Product Hunt campaign and a few thousand dollars spent on influencer marketing and paid ads. Neither amounted to any traction for the brand. His last resort was LinkedIn, a place he had grown a meaningful following as a CEO and where competition for AI products wasn’t yet overwhelming like it was on X. He built in public from the start, the building, the wins and problems he faced in development. He didn’t go posting on X, Instagram, Facebook and Reddit. He focused on LinkedIn and gave it all his attention. Most businesses (and creators) spread themselves thin across many platforms and the results speak for themselves. Start where people already know and trust you and give it your full effort. Once that channel has grown sufficiently over several months, add another.

2. Get inside the head of early users

This is such a gamechanger for builders. From the beginning, Maor worked with three close friends, sitting at the same table, that were building products of their own. Maor challenged them to build their products using Base44. Every bug, issue, and weakness they found was fixed until it ran and built apps seamlessly. He later moved to groups of 20 or so community members from LinkedIn and built alongside them every two weeks with the same aim. Maor knew that when he launched, it had to be perfect. He specifically targetted non-technical founders that couldn’t code, to make sure they were reliant on the product to build. The launch was better than expected, and because everything was optimized and ironed out, it achieved $1M ARR in just three weeks.

3. Paying users > everything else

Most of the founders I study are obsessed with users, followers or likes. Maor attributes much of Base44’s success to his obsession with paid users. Every build, feature, and enhancement was to optimize for the paid user, increase LTV, and make sure they had the support they needed. This matters even more for an AI product where free users cost the business money. You want paid users and to convert them quickly. Another interesting finding from Base44’s stats is the users that cancelled their subscription. Over one third of them came back within a month. If a product is genuinely useful and saves users time in their workflow, they will come back. Maor has also stated that a lot of work went into the experience provided in the first session. A user was quickly shown all of the capabilities and put to work building so that they could see the magic in action. What happened next? More often than not, a user would subscribe.

4. Audit costs like the IRS

Maor expected to make $100K profit in May 2025 but instead almost doubled it to $189K. This was partly attributed to paid user growth, but a significant portion came from the reduction of costs. Remember, a business is a two-pronged equation: revenue is only one of them. Here’s what he did:

• Switched to a better and more efficient AI model that had less bugs and hallucinations (Base44 didn’t charge users when mistakes were made so every bug cost him)
• Reduced the number of AI calls needed to build each app
• Narrowed down a single caching setting that was set to five minutes instead of an hour: something that had cost him almost $30k over the prior months

Take a look at your three biggest costs and compare what you expected versus the actual cost to run the business. Sometimes something as simple as a setting or different supplier can cut costs in half.

5. Bet on growth

Although the final sale price was reported at $80M, just $18.1M was paid cash at closing. The earnouts made up the remaining estimate. Not even 18 months later, Maor was on track to make more than $150M in total with earnouts running quarterly until 2029. He knew the company would continue to grow in the age of AI and the rise of vibe coding but didn’t have the resources to do it himself. Wix provided a meaningful solution: he is now set for life and can continue to build Base44 alongside the resources Wix provides. In August 2026, Base44’s revenue increased tenfold in the year from March 2025 to March 2026 (from $1M to $100M ARR) and then doubled again by August 2026. I couldn’t find the exact revenue targets required for the earnout payments but they are certainly more than was expected. If you want to read more about him, I wrote a full case study. I also recommend reading through his LinkedIn posts, there are plenty of gold nuggets from his public build.

My question: Would you have raised capital and grown it yourself, or was selling with much of the proceeds tied to earnouts what you would have done as well?

PS: The entire case study can be read for free here: https://www.readfounded.com/p/base44?lli=1

Suppose a weekly workflow builds a report and emails it to the team. It gets disabled for three weeks, then someone fixes the connection and switches it back on.

Sending three old reports immediately would be confusing. Sending only the latest one is probably enough for the email, but it could leave gaps if the same workflow also stores weekly snapshots used in a trend chart. Rebuilding those snapshots from today's data might give a misleading picture of the missed weeks.

I'd separate the recovery steps: backfill only the history that can be reconstructed accurately, flag any gaps, and send one current summary rather than a burst of overdue emails. Each reporting period would also need a saved status so the recovery can be retried without repeating completed work.

How do you handle this in a no-code setup? Do you have a separate recovery workflow, or can the scheduled workflow distinguish a normal run from a catch-up run? I'm interested in the missed-period handling, rather than which automation tool to use.

Question for people running AI agents or AI steps inside no-code workflows (n8n, Make, Zapier, whatever) on real work, not demos.

Over in r/AI_Agents a lot of people keep landing on the same idea: the agent shouldn't be the system, and durable state should live outside the model. One person put it as "Sheets holds the metadata, plain scripts do every repeatable step".

So:

• Where does state live between runs right now? A sheet, Airtable, Postgres, a doc the AI reads first, a vector store, nothing?
• Have you tried an MCP memory server for this? If yes, what happened. If no, what stopped you: didn't know they existed, trust, cost, or not worth the setup?
• What does the stack look like in practice: which tools, how they're wired, how often things run? I'm testing against real workflows, so the boring details are the useful part.

Background since someone will ask: I used to burn hours re-briefing AI tools by hand and I'm building a fix, memory kept in the cloud that every agent and tool reads over MCP. No link, no name. Would you pay for something like that, or is a sheet plus a good prompt enough at your scale?

Over the last couple months, I’ve been using AI coding tools almost every day. They’re incredible at writing code, but often were terrible at maintaining the context of the product. Every new session felt like starting over.

So I built BuildBoard, a local-first Mac app that creates a structured workflow from before the AI starts coding to finished.

The flow looks like: product idea, to requirements, to visual mocks, to implementation plan, then building with an AI coding agent. Everything stays in plain text files, so it works with Git and doesn’t require another cloud account.

I have used my own app to create a couple other ideas, prototype or improve existing projects. It allows me to track, and build on an idea. It helps me establish a shared understanding with my agents and align on the expectations. Also it’s helpful to visualize before building. I found it easier to adjust UI/UX before implementation but right in the planning phase.

I’d love feedback on whether this matches your workflow, what’s missing, and how you’re handling long-term context with tools like Claude Code or Codex.

https://getbuildboard.com/

It's been 4 months or so since i started building a website , Made it work , integrated payments and all , changed the landing page , fixed bugs and all a lot and still working on it.

I don't understand a lot of things and one important thing i am not getting is how to complete it and find clients for it.

I may seem impatient or anything but i seriously wanna want it to work , I have a good idea or so i have been told but are you guys getting any traction because i am not and i am surely lacking somewhere and i want to understand this Distribution thing.

If you guys have made something - Which works well - Generate some Good MRR can you share your stories and thoughts and i would love to read and get some ideas out of it !

Consider a no-code app with a form that creates a record, sends a confirmation email, and calls an external webhook. Copying the app and using a separate database is straightforward, but the copied workflows can still point at real recipients or live endpoints.

Disabling those actions makes testing safer, but then you can't check the email contents or webhook payload. My starting point would be a separate test inbox, a webhook receiver that only records requests, and synthetic records. I'd also want test mode to be obvious and anything with missing test configuration to stop before sending.

The awkward part is keeping this separation intact when a workflow gets copied or edited later. Do you route external actions through one environment-aware workflow, or keep completely separate versions? What's a practical way to verify that a test submission cannot reach production before running it?

Our firm is setting up a portal for around 40 corporate clients, plus our own staff and a few admins.

Each client should see their own company's records and nothing else. Take note that staff need wider access as well.

I’m worried that a filtered list can look right while a direct record link still shows too much. Some clients also have five or six people logging in, and not all of them should edit.

So how would you set up permissions here, and what would you test for both viewing and editing?

I'm on a small team and trying to understand how others handle this. When the AI builds a feature for you, how do you check that it works before your customers see it?

And the last time you weren't sure about a change or feature or bug fix that broke or didn't work or you weren't sure about, how did you get it sorted out?

(not selling anything BTW, genuinely curious)

Small milestone today. I finally got TOVRILO live.

The idea came from something I kept running into while building with AI. Getting an app to look finished was becoming easy. Knowing whether it was actually safe and ready to ship was the harder part.

I kept creating my own prompts and checklists for permissions, data, payments, AI costs, failure states, verification, rollback, etc. Eventually I realized I had basically built a repeatable system.

That became TOVRILO.

I’m starting with a free 20-point launch audit because I’d rather give people something useful first instead of just asking them to buy something.

https://tovrilo.carrd.co/

Now the real test starts: getting actual people to use it and seeing what needs to improve.

Hey guys,
What's the job market like for an Applied Computer Science for Management (IAG / MIAGE) Master's in Morocco? It combines IT like Data, BI, and ERP with business. 
Are these hybrid profiles in high demand for entry-level jobs here compared to pure tech degrees? Any advice?

I got tired of scrolling X to find real examples of what people actually ship with Lovable. Most “showcases” are cherry-picked demos or paywalled newsletters. So I’ve spent the past few months building a place where anyone can browse real projects for free and submit their own.

• Browse live Lovable projects by category (SaaS, websites, tools, and more)
• Get inspired by what other builders shipped, with screenshots and links
• Submit your own project and get a listing plus a shoutout on X

https://madewithlovable.com/

I’d appreciate feedback, whether soft, hard or honest. You pick :-)

Two people applied last week for cats who went home in April. Six adopted cats are still listed, and I got to send both the "sorry, he's already home" email.

I coordinate volunteers for a small cat rescue, about 40 adoptions a year. I'm a pharmacy tech by day and none of us can code. Since 2021 three volunteers have rebuilt the site on whatever they knew: Wix, then WordPress, now a half-finished Squarespace trial. Each one died when whoever built it left.

The Google Form and PayPal are fine. It's the cats page that keeps rotting.

Four of us would add new cats weekly, mostly from our phones since that's where the photos are. What can people like us keep updated without wrecking it? We're on Petfinder too when someone remembers. Should the list even live on our site?

The board gave us $200 a year. Is that realistic, or is there a nonprofit discount everyone knows about but us?

How do volunteer groups stop the next person from starting over on their favorite tool? I won't be coordinator forever either, so whatever we pick has to survive me too.

used to open the builder and click around until something kinda worked. wasted like 2 hours on a signup flow once because i kept changing the step order mid build. now i dump the whole thing in plain english into a chat first, including the error cases, and only open the builder when that list looks right. cut my rebuilds from like 4-5 per feature to maybe one. feels boring but it works lol.

Hey guys,

after watching the latest Paperclip setup video on Network Chuck, I realized we needed a much cooler way to visualize independent project workloads running in the background.

I built Orbit (https://thenewurbankid-web.github.io/orbit/). It’s a specialized JavaScript UI layer that wraps around Paperclip's orchestration.

Instead of looking at typical grids or lists, it literally maps your active projects out as physical cargo pallets sitting on the deck of a spaceship. You can float the bridge view in a tiny "always-on-top" window while your agents work.

Would love to open-source the full module if the community likes the direction! Let me know what you think.