Cut any feature whose absence won't stop a user from completing the core job once. Then attach a concrete trigger to each cut, so "later" has a definition. Use the examples below to challenge scope, then check each against your actual customer requirements.
The goal isn't a worse product. It is a faster answer to your riskiest question. If you haven't defined that yet, start with how to build an MVP.
Features to cut, and the signal to bring them back
| Feature | Why cut | Do this instead | Signal to add it back |
|---|---|---|---|
| Admin dashboard | Costs as much as a product surface, serves only your team | Use the database console, a spreadsheet, or a low-code internal tool such as Retool | Staff spend real time each week on a repeated task, or a non-technical person needs safe access |
| Complex roles and permissions (RBAC) | You don't know your roles yet | One or two fixed roles (user, admin) checked in code | A paying customer needs different people to see or change different things |
| Multi-language | Adds translation, routing, editorial and QA work | Ship in the language of your first segment | A concrete segment is blocked by language, backed by requests or lost deals |
| Native mobile apps | Two more release pipelines and store reviews | A responsive web app, possibly installable as a PWA | Users need device features the web can't give, or usage data shows mobile-heavy repeat use |
| Custom authentication | Security-sensitive and easy to get wrong | A managed provider or a well-maintained library | Compliance or product needs a flow the provider can't do |
| In-house billing | Tax, retries, invoices, refunds | A hosted payment provider's checkout and subscriptions; or invoice by hand | Pricing logic the provider can't express, or provider cost becomes material |
| Notification preferences center | Needs a settled notification set first | A few essential emails, plus an unsubscribe link | Users complain about volume, or you send several distinct notification types |
| Dark mode | Doubles visual QA | Pick one good theme | Support requests or a clear usage pattern (e.g. long evening sessions) |
| Full-text and faceted search | Needs data volume and tuning to be useful | Simple filters, a database ILIKE, or built-in database full-text search | Users can't find items with filters, and search queries show repeated failures |
| Enterprise SSO and provisioning (SAML, SCIM) | Enterprise feature, heavy to support | Email login or social login | A real prospect lists it as a purchase requirement |
| Offline mode | Sync and conflict handling is hard | Handle slow networks gracefully, show clear errors | Users work in places without connectivity, confirmed in conversations |
| Public API | Creates a support and versioning burden | Export to CSV on request | Customers ask to integrate and are willing to pilot it |
| Analytics dashboards for users | Needs data first | Send a weekly summary by hand | Users ask for the same report repeatedly |
Two notes on the table.
First, "signal" means evidence from real users or paying customers, not an internal opinion. One loud request is a lead. Several unprompted ones from your target segment is a signal.
Second, some cuts get more expensive when deferred (for example, data models that assume one language or one tenant). Make the cheap structural choices now (store text in a way that can later be translated, scope data to an account), and skip the feature work.
What a cut looks like in practice
Take an admin dashboard. Early on, your team needs to approve records, fix typos and see who signed up. A restricted internal tool can cover these actions. Direct database access should be limited to trusted technical staff, with the required access checks and audit history. For anything more regular, a hosted internal-tool builder can sit on top of the same database without designing a complete bespoke interface. Check each vendor's pricing page for current plans before you commit.
When the same manual task takes real hours every week, or you need audit trails and role-limited access, build the admin portal properly. Apex built both a public listings site and an admin portal for Offease, illustrating the two interfaces a listings business may need.
What not to cut
Cutting scope is not permission to skip foundations. These are cheap early and costly to retrofit.
- Security basics. HTTPS, hashed passwords or a managed auth provider, parameterised queries, server-side authorisation checks, secrets kept out of the repo. See our authentication guide.
- Backups you've tested. Automated database backups, and one restore rehearsal. An untested backup is a hope.
- Error tracking. You can't fix what you can't see. Configure a basic error monitor, remove sensitive payloads and verify alert delivery.
- Privacy basics. Collect only what you need, say what you collect, offer a way to delete an account on request, get consent where required. This is not legal advice; talk to a qualified adviser about your obligations in each jurisdiction where you operate.
- Accessibility basics. Semantic HTML, labelled form fields, keyboard access, sufficient colour contrast. Plan these requirements in the first layouts and interactions. See semantic HTML and accessibility.
- Analytics on the core event. If you can't measure activation and the core action, you can't learn. See what to track in MVP analytics.
- A deploy process you can repeat. One command or pipeline, plus a way to roll back.
Deciding a borderline feature
Ask these in order:
- Can a user complete the core job without it? If yes, cut.
- Can we do it by hand for the first 20 users? If yes, do that.
- Can we buy it or use a hosted service cheaply? If yes, do that, and read the build vs buy guide.
- Is retrofitting it later much harder than building it now? If yes, build the minimum structural part.
- Still unclear? Cut it, write the signal that would bring it back, and move on.
Keep a "later" list with triggers
Don't throw cut features away. Keep a short list: feature, trigger, owner. Review it at each decision point after launch. Features whose triggers never fire were the right cuts.
References
- Retool pricing (check current plans for internal-tool builders)
- PostHog docs: capturing events
- W3C WAI: Introduction to web accessibility
- MDN: Accessibility
- Sentry (error tracking)