Javascript Project Planning


This is exciting stuff. Your Javascript project is an excellent chance for you to show off everything you’ve learned about Rails by applying that knowledge to build out your API AND apply what you've learned about JavaScript by creating your first Single Page Application (SPA).

One of the most important processes in building any application is planning — let's take some time to map out our project to save ourselves time and heart/headache later. Unlike labs, projects do not have the guardrails of a README and tests to structure your work. Instead, you need to design and plan your features yourself. These tips should help you plan your project effectively.

Use this document to help you complete this planning form

Tips on all aspects of the project are included here, so make sure to have a look through!

Note: Keep in mind that the Ask a Question team is not permitted to help while you are building your projects. Use the internet and the resources provided in this document if you get stuck!

How to Get Started On a Successful Project Build

  1. Read through the project requirements here carefully before getting started.

  2. Come up with a project idea of your own, and devote some time to a planning session. Think about the following:

    a. Brainstorm the problem that you want your application to solve. It's okay to take inspiration for the features you want to build from other sites or projects you've seen (it's not okay to use their code, though).

    b. Plan what features your app will have. You can write User Stories to help make it clear what you are planning to build.

    c. Model your domain. You need to know what the nouns in your project are

    • the objects in the 'world' of your application. It can be helpful to draw the relationships between your models.

    d. Plan how your features will work. Use this form to jot down your plans and submit them to us so we can see what you are planning! Check out the sections below on User Story and Flow Diagrams for help in filling out the form.

  3. Create a skeleton app and push to a remote repository on Github.

  4. Plan your schedule. Note that it takes most full time (40+ hrs/week) students between 3-7 days to complete, and can take up to 5 business days to schedule your project review after that.

  5. Join the Slack channel #rails-js-section to connect with others who are working on their projects as well. Students often set up a peer review in advance of their project review as a way to practice talking through your code.

We are here to help! Each week, there are Open Office Hour study groups specifically designed to help with your JavaScript project questions. Also, keep an eye out for topic-based JS study groups if you feel shaky on any specific concepts.

Making a User Story

  • Who is your User?
  • What are their pain points?
  • How do they use our solution to overcome this problem?

User Stories are a powerful tool for succinctly describing a set of functionality in terms of what it allows the user to do.

Some examples of user stories:

  • A user is able to view travel locations, add new travel locations, edit travel locations and delete travel locations.
  • A user is able to review a travel location
  • A user is able to edit and delete a review for a travel location

When you have written the user stories for your application, you can turn them into the technical requirements needed to turn those stories into working features.

Choosing your Classes

As you turn your user stories into more clear technical specifications for features, you can start by modeling the data that your application will store and show. Identify the nouns in your stories, their properties, and their relationships.

A description of the domain for the above stories might be:

  • A travel location has a name, a description, a location, and an image URL
  • A review has a comment and a rating
  • A review belongs to one travel location (a travel location has many reviews)
  • A travel location has an average rating that is calculated by its aggregate review ratings

Later on, you will be ready to create the database schema and application models corresponding to this domain.

Making an App Flow Diagram

  • How is data passed around your app?
  • What classes are used? What are their responsibilities?
  • How can I avoid unnecessary duplication of actions?

We recommend using to put together a flow diagram. It doesn’t need to be over-complicated - just a visual idea of your app’s structure.

You don’t have to use software for this - a photo of a (legible) hand-drawn sketch on a napkin also works!

The following GIF shows how to make a shareable link on

make shareable gif

Please make sure the image or file you share with us is accessible.


(Minimum Viable Product, As Soon As Possible)

Building things is hard. It's tough to predict what will be difficult in a project. Sometimes things that appear on the surface to be easy will end up taking hours of debugging.

With that in mind, it's important to build a Minimum Viable Product (MVP) as quickly as possible. Instead of getting stuck on advanced features, start with a basic working version of the application, then steadily add features piece by piece.

Build vertically, not horizontally

It's easy to end up having to do lots of rework and fixing depending on how you order the things you build in your application, particularly if you build 'horizontally.'

You can visualize all the parts you of an app you need to build as a grid, with the features along the x-axis (columns) and the different layers of the stack along the y-axis.

A strong temptation is to build your project row-by-row. It feels easy to start by writing all the migrations for all your models, then all the models, etc...

Do not do this!

If you try to build all your migrations, then all your models, then all your controllers, then all your fetch calls, then all your view logic, you will have a bad time. Inevitably, your view logic will end up requiring changes to the underlying layers, and you will write code that doesn't get used.

Instead, build vertically, column-by-column. Write code for all the vertical layers involved in one feature before moving on to the next feature. That way, you'll minimize rewriting, and end up with working features without waste.

A visual explanation of this suggested development workflow can be found here


The project process should look like:

  • Planning: Write down your ideas (use diagrams!)
  • Start by creating the frontend and backend directories
  • Build the R from CRUD for just one model, vertically! That means one migration, one model, one controller action, one fetch call, and one DOM update. Add seed data and confirm that your code works by testing it visually.
  • Then, build the next CRUD action (maybe Create or Update), again building vertically.
  • Continue building features one by one, (vertically!)
  • Add feature by feature, not model by model or layer by layer.
  • Test each feature, add styles, and create seed data as you go (not all at once at the end)

Handy Resources

Demo Projects

Unlock your future in tech
Learn to code.

Learn about Flatiron School's Mission

With a new take on education that falls somewhere between self-taught prodigy and four-year computer science degree, the Flatiron School promises to turn students with little programming experience into developers.

In the six months since the Manhattan coding school was acquired by WeWork, it has spawned locations in Washington, D.C., Brooklyn, and London. Now, WeWork is opening a fourth Flatiron School location, this time in Houston.

Adam Enbar, Flatiron School's cofounder, believes now is the time to grow. "How the world is changing has impacted working and learning in very similar ways. We think education fundamentally is about one thing: enabling people to pursue a better life."

Learn. Love. Code.
Students come to Flatiron School to change their lives. Join our driven community of career-changers and master the skills you need to become a software engineer or a data scientist.
Find Us