How to split work when building a large system?

When working on building a relatively large software system (such as an HR or enterprise system), what is the best approach to structuring the work?

  • Is it better to start with a high-level general plan and then continue development across separate chats for each part?

  • Or is it preferable to create a detailed plan upfront before starting implementation?

From an AI model perspective:

  • Is using a large-context model like Sonnet 4.5 more effective?

  • Or does using a more focused model with a smaller context like Opus 4.5, combined with proper task splitting, lead to better results?

What best practices would you recommend to avoid loss of accuracy or inconsistent decisions when working across multiple chats?

Thanks in advance.

1 Like

Based on my experience working with enterprise-level monorepos, workflows tend to vary by person. From my perspective, I build strictly based on requests from the Product team.

Because of this, it is better to maintain two distinct types of documentation rather than mixing them:

  1. PRD (Product Related): Covers user stories, acceptance criteria, and the general roadmap.

  2. RFC / TRD (Tech Related): Covers technical design, frontend, backend, and database schema.

The Workflow:

  1. Define the Scope: Start with the PRD.

    • Example: Create an HR System MVP.

    • Goal: User onboarding and ability to clock in/out.

  2. Technical Design: Create the RFC/TRD based on that PRD.

  3. Breakdown: Split into milestones (MVP, V2, etc.) with specific features and timelines.

  4. Execution: Convert the RFC/TRD into a task list or GitHub Issues. This becomes the concrete starting point for development.

You can check a sample plan here: https://github.com/naufaldi/excalidraw-clone/blob/main/docs/todo/plan.md

1 Like