When I audit apps, I am almost always telling founders to simplify, not to ship more. Simpler copy. Cleaner onboarding. Less competing on the dashboard. Most of my notes are about cutting the noise around the product, not the product itself.
This chapter covers why restraint is the actual strategy once building gets cheap: how feature creep works in an AI build, what each shipped feature actually costs you, why useful beats impressive, and what to say no to without losing momentum.
AI is really good at making founders feel productive fast. You ask for one feature. The AI model suggests three more. Suddenly your basic app idea has dashboards, notifications, AI agents, roles and permissions, integrations, advanced analytics, settings pages for settings pages, and somehow an enterprise roadmap already.
Because the UI looks polished immediately, it feels right. It usually isn't. Every added feature, line of text, or extra onboarding step you ship before the core product feels solid either delays launch or makes the product harder to understand once you do.
The friction that used to stop founders from adding too much isn't really there anymore.
When building gets easy, products drift
For most of software history, constraints were automatic. Limited engineering time, limited budget, slower execution, and usually at least one developer pushing back:
"Yeah we are absolutely not building all of that."
AI removed most of that friction. Which is great, but it also means founders can keep expanding the product without hitting many natural stopping points. So products drift.
More workflows. More settings. More customization. More flexibility. More "platform" functionality. Meanwhile the value prop gets blurrier and the generated UI keeps looking finished, which makes founders confuse volume with progress.
Feature creep has a permanent cost
Feature creep isn't new. What changed is how easy it feels.
You ask the AI for "a simple onboarding flow" and get an enterprise software suite. Admin panels. Permission systems. Team workspaces. Reporting dashboards. Notification centers. API abstractions. Probably a Slack integration nobody asked for yet.
You technically can build all of this now. The cost shows up later, and it's permanent.
Every feature you ship is a commitment. To support, edge cases, failure modes, documentation, user questions, maintenance, weird bugs, and expectations. The feature is never just the feature.
| Add-it mindset | Restraint mindset |
|---|---|
| "Would this be cool to add?" | "What does this commit us to maintaining?" |
| Focused on shipping | Focused on sustaining |
| Says yes by default | Asks what it costs |
| Thinks about the happy path | Thinks about edge cases |
| Prioritizes output | Prioritizes reliability |
| Optimizes for launch | Optimizes for retention |
The goal isn't shipping nothing. It's shipping deliberately, knowing what each addition costs. Otherwise you wake up on week two maintaining a product you didn't decide to build.
Half these apps look enterprise-ready before the main workflow even works properly.
Useful beats impressive
A lot of founders optimize for impressive because impressive demos well. Big dashboards demo well. Giant feature lists demo well. AI-generated workflows are basically built for demos.
Useful products are usually much simpler than founders expect.
| Looks impressive | Actually helps users |
|---|---|
| Huge dashboards | Clear next steps |
| Endless customization | Strong defaults |
| Lots of AI features | Faster outcomes |
| Complex workflows | Lower effort |
| More pages | Better focus |
| "Platform" positioning | One thing done well |
Founders optimize for the left side because it screenshots better. Users care about the right side because it's easier to trust and easier to use. Especially users who aren't spending their evening admiring your information architecture recreationally.
Constraints win early
A lot of great products started by doing one thing unusually well. The constraint was the strategy.
Smaller scope forces clearer positioning. Fewer features force better defaults. Fewer paths force better onboarding. When there are fewer ways to use the product, people reach value faster because the experience feels obvious.
Obvious is underrated right now. Every AI product is trying to become:
- a workspace
- a platform
- an ecosystem
- "the operating system for modern productivity"
- some other sentence that sounds important in a funding deck
Meanwhile people are mostly trying to complete a task and get back to their actual job.
The pull toward "platform" gets worse with AI because the generated UI already looks the part. You generate one dashboard and suddenly the app feels like it should support multiple workspaces, advanced permissions, enterprise collaboration, international scaling, and maybe blockchain for emotional support. The actual product still needs simplification.
Focused products are easier to explain, easier to support, easier to onboard, and easier to improve. All of which matter more early on than looking like a platform.
Simplicity takes restraint
Complexity feels productive because there's more to point at. Simplicity is mostly saying no, repeatedly, even when you technically could build it.
- no, not yet
- no, this isn't core
- no, this makes onboarding worse
- no, users don't care about this as much as we do
- no, we're not becoming "the everything platform for modern workflows"
Products don't get confusing all at once. It happens gradually. One more feature. One more workflow. One more settings page. Then one day the product takes ten minutes to explain instead of ten seconds.