Skip to main content

Research to Story (RTS): Development Plan

Since a significant amount of learning is happening while I’m building RTS, and since this is not my day job, I’ve come up with a way to focus on a feature based workflow. I didn’t start out this way and the results were as expected: a rubble of unmanageable code base and redundant database schemas.

This document outlines a lightweight, effective development process for the RTS project. Its goal is to provide a structured workflow that enables steady progress on core features while minimizing bugs and the need for major refactors.

The RTS Development Plan

The core philosophy of this plan is to work in "Feature-Based Sprints." I will define, build, and test one discrete piece of functionality from start to finish before moving on to the next. This ensures that the application remains in a stable, working state at all times.

The "Feature-Based Sprint" Workflow​

An image from the static

For every new feature (e.g., "Instructor Dashboard," "Student Enrollment," "Deep Dive Questions"), I will follow these five steps in order:

Step 1: Define the "User Story" & Scope

  • Goal: Before writing any code, clearly state what the feature is and what it should do from a user's perspective.
  • Example: "As an instructor, I want to view a list of all students enrolled in a specific course so that I can see my class roster."
  • Why it's important: This keeps focus on the user's need and prevents "feature creep," where I try to build too much at once.

⠀Step 2: Design the API & Database Contract

  • Goal: I decide what data the feature needs and how the frontend will ask for it. This means answering:

    1. Database: Does this feature need new tables or columns in the schema?
    2. API Endpoint: What will the URL be (e.g., /api/courses/get-roster)?
    3. Request: What information does the frontend need to send (e.g., course_id)?
    4. Response: What data will the backend send back (e.g., an array of student objects)?

  • Why it's important: This "API-first" approach creates a stable contract. Once I agree on it, the backend and frontend can be developed independently without breaking each other.

⠀Step 3: Implement the Backend

  • Goal: Write the server-side code to fulfill the contract from Step 2.
  • Tasks:
    • Create the API handler file (e.g., /pages/api/courses/get-roster.ts).
    • Implement the database query logic inside the handler.
    • Add any necessary Row Level Security (RLS) policies to ensure the data is secure.

⠀Step 4: Implement the Frontend

  • Goal: Build the user interface that uses the now-working API.
  • Tasks:
    • Create or modify the React component (e.g., /pages/instructor/courses/[id].tsx).
    • Write the state management (useState, useEffect) needed for the UI.
    • Create the axios or fetch call to the API endpoint.
    • Render the data returned from the API.

⠀Step 5: Test and Verify

  • Goal: Test the entire feature from end to end, just as a user would.
  • Tasks:
    • Log in as the correct user role.
    • Navigate to the new page.
    • Perform the action (e.g., click the button).
    • Verify that the UI updates correctly and the data is as expected.
    • Check the browser's developer console and the terminal for errors.

#rts/documentation/logs