BUILD NOTE
Known limitations are not a weakness when they are written clearly. For a playable prototype, they tell visitors what to expect and help separate a deliberate small build from a broken or abandoned page. They also give the maintainer a checklist for future improvements.
Practical note
A limitation should be concrete. “Still improving” is less useful than saying that mobile spacing, loading comfort, balance, language polish, or lower-power device performance may change. Concrete notes help visitors decide whether a problem is already known or worth reporting.
Limitations also make short games easier to understand. A compact browser prototype may not have dozens of levels or a long onboarding sequence, but it can still be valuable if the page explains the current focus. Netherguard focuses on readable deduction, while Block Smash focuses on quick arcade runs and upgrade feedback.
The best limitation section is paired with a “what may change next” note. That turns the page into a living project record instead of a static launch description. Visitors can see what is playable today and what kind of polish may arrive later.
Checklist
- Check the public route, not only the editor preview.
- Keep project notes aligned with visible game behavior.
- Record meaningful visible changes in the update log.