Start with where the real product must run
Choose the production destination before choosing a framework. A content focused website, a web application with accounts, a mobile app for both stores, and a desktop product need different foundations.
This prevents the expensive version of experimentation, where a promising prototype later has to be moved into a completely different system before it can launch. You can still change direction, but the first choice should be informed by the intended destination.
Content website
A static first approach such as Astro can be a good fit when speed, content, and search visibility matter more than application state.
Web application or SaaS
A full application framework such as Next.js is useful when accounts, dashboards, server actions, and a growing product surface belong together.
iOS and Android app
Expo with React Native gives one practical codebase for both mobile platforms while preserving a path to store releases.
Game
Choose the engine around the game, target devices, and assets. Unity is a common production path for system heavy 2D and 3D games, while a browser stack can suit a smaller web game.
Write the core flow before the feature list
Describe the shortest useful journey as a sequence a person can complete. For a shared apartment planner, that might be: create a home, invite a roommate, add a task, assign it, and mark it complete.
That sequence is more useful than a list containing notifications, themes, achievements, analytics, and twenty settings. It tells the agent which screens and data relationships must work together first.
Prepare the foundation without building everything
Create the repository, install the framework, record the important project rules, and prepare separate development and production configuration. If the product needs accounts, stored data, payments, or external APIs, decide the backend path now even if only the first connection is implemented.
Preparing does not mean building an imaginary enterprise platform. It means avoiding temporary decisions that are guaranteed to be replaced before launch.
Project rules
Keep durable instructions in an AGENTS.md file so the coding agent sees the architecture, commands, constraints, and verification expectations whenever it works in the project.
Environment boundaries
Keep keys and secrets outside the repository. Use environment variables and separate values for local work and production.
Data ownership
Know which service stores user data, how access is authorized, and how you can back it up before real users depend on it.
Build one complete slice at a time
Ask for inspection and a plan
Let the agent inspect the relevant files and explain the proposed change before implementation when the task touches architecture or several parts of the project.
Implement one visible outcome
Finish a small path that you can open and test. Avoid starting three screens that all depend on unfinished backend work.
Verify proportionally
Run types, linting, focused tests, and a real interaction check. Payment, authentication, and permissions deserve deeper verification than a copy change.
Record the next known step
End with a working state and a short next task. That makes the following session easier to begin and easier for the agent to understand.
Define done in terms a person can observe
A task is not done because code exists. It is done when the intended person can complete the promised action, errors are handled, the important state is saved, and the result still works after the checks run.
This definition keeps the agent focused on the product instead of the amount of code changed. It also gives you a clear point at which to stop polishing and move to the next useful slice.