maryam nafees

When I started I was convinced the original idea just needed more time. Every slow month had an explanation and every bit of feedback felt like something I could fix later. At some point though I started wondering if I was actually being persistent or just avoiding the possibility that the idea wasn t working the way I thought it would. How do you tell the difference between giving something enough time and being too attached to your original idea?

Vibe coding a personal project that works on your laptop is one thing.
Building a tool your team opens every morning to manage projects, serve customers, and run the business is another.
Suddenly there s shared data.
Different people need different levels of access.
Your teammates need to understand how the app works so they can change it too.
And the app needs to keep evolving without turning into a black box nobody wants to touch.
At that point, would you be comfortable letting AI change anything it wants?
We ve been thinking about this a lot while building WeWeb MCP (launching on PH tomorrow!)
Agents like Claude, ChatGPT, Cursor, and Gemini can now build apps directly inside WeWeb.
Across the frontend & backend from: UI, data, workflows, integrations, permissions, and more.
But the important part for us was making sure the builder stays in control of both the app and the AI building it.
That s why we built guardrails into the way AI works inside WeWeb:

• Before AI builds: choose what AI can and can t touch: pages, components, workflows, tables, APIs, and more.

• After AI builds: see exactly what changed in the visual editor. Tweak it yourself, keep iterating with AI, and publish when you re ready.

So AI gets room to move fast, without getting free rein over the whole app.
I m curious how you think about this: Would you give an AI agent access to everything?
Or are there parts of your app you d always want to lock down?

Focusing on signup momentum is fun but customer cancellations quickly shift your focus once revenue is involved.

A lot of cancellation reasons boil down to routine integration rather than minor feature requests. Fixing how a product fits into someone's workday is a much tougher challenge than just shipping another update.

Do experienced founders eventually get used to churn or do you just build faster ways to analyze and act on user cancellation reasons?