Project Proposal Guidelines

The Project

We will spend the second half of the semester working on large-scale web applications in teams of 5-8 students (3-4 projects total). The primary requirements for the project are technical (see the list below). There a relatively few constraints on the goal/content/purpose of the application. Think broadly!

Project technical requirements:

  • Your project should have non-trivial front-end functionality with database back-end
  • The project should be based on Next.js
  • The project should make good use of React components
  • The project should consist of at least two separate pages
  • Your application must store some data in a database.

The scope is always hard to estimate. However, with 5-8 students over 6 weeks, your team’s total capacity should be over 300 person-hours. Scope your project with that capacity in mind. You can build a substantial application in 300+ hours (though we should acknowledge that the math is not a simple as adding up the number of hours each developer can contribute…)!

The Proposal

At this stage, I am looking for a collection of proposals. Consider this optional assignment a Request-for-Proposals (RFP). You are encouraged, but not required, to submit a proposal. I will vet the proposals for suitability and scope before sending them out to the class.

If you wish to propose a project, please fill out a project proposal form. You proposal should contain the following information:

  1. The title of the project
  2. The names of the proposer(s) (can be multiple people)
  3. The target users and other stakeholders
  4. The main functionality of the application. Specifically, you should describe the major “epics”, i.e. the big coarse-grained user stories. We want to know what this project will do and why anyone would want to use it. This component should make up the bulk of your proposal.
  5. What kind of data will be stored and how it will be used
  6. What, if any, external resources, such as APIs, do you plan to incorporate

Incorporating an external API is not discouraged, as long as it is “self-serve”. For example, you can automatically obtain a Google Maps API key and the API has a free quota that is more than sufficient for a class project. In contrast, any API that requires “manual” approval by the provider will likely be a problem. You only have 6 weeks to complete the project, and so waiting 3 weeks for API approval is not practical. (We have had projects fail because they were counting on API access that came far too late in the process)

Submission

All proposals must be submitted via the project proposal form. You are welcome to submit multiple proposals.

FAQ

Is the project “bound” by the proposal?

The proposal is not a contract. We expect the projects to evolve (often substantially - I have seen several projects that had only a passing relationship between the proposal and final form). That said, your proposal needs to be specific enough (and “thought through” enough) that you and we can estimate the scope (and your classmates have a good idea of that they would be signing up to do). A great proposal will provide a clear starting point for your first development iteration (“sprint”).

Do I have to work on the project I proposed if it is picked to go forward?

No. If you rate another project more highly there is certainly a possibility that “your” project can move forward without you. This has happened before. We have also had a project so popular we had two groups working on different versions.

Am I automatically the Product Owner if I am working on a project I proposed?

No. You are a logical choice to be the voice of the “customer” since it was your idea, but you can certainly cede that role to someone else (again, you wouldn’t be the first). I just ask that you don’t become a “shadow” Product Owner, taking no responsibility but still expecting to have the last word about what moves forward.

What kinds of projects are not a good fit?

  • A mostly “static” website, or a site that could be managed with an off-the-shelf Content Management System (CMS), e.g. WordPress or Drupal.
  • Native mobile applications.
  • Applications that rely on commercial frameworks or APIs, e.g. Salesforce.
  • Applications that handle sensitive data (e.g. health data protected by HIPAA or FERPA-protected student data).
  • Applications you plan on turning into a company in the future. The ownership of the code (and or IP) could be tricky.
  • Applications that rely on technologies/algorithms not covered in the class (this is not the moment to learn machine learning or GIS, and even if you do know the technology or algorithm, it will be important that some of the rest of the group does as well). I won’t completely discourage these (they can make for really interesting applications!), but check with me first.

What kind of projects have been successful in the past?

There is no one phenotype for a successful project, your teamwork and development process is more important to the success of your project than the topic. React is most useful in highly interactive applications (think Google Maps or Mail) and so projects with more interactive UIs will take better advantage of its capabilities.

Some of the more successful projects have included:

  • A real-time, multi-player strategy game
  • A scheduler for club sports
  • A tool for real-time, in-class feedback about understanding level
  • An online meal ordering system
  • A tool for glitching images for research
  • A site for creating and sharing coding tutorials
  • A site for evaluating news stories for bias
  • An IMDB style site for Middlebury films

Are there potential pitfalls I should watch out for?

One thing that has tripped up many groups is the need for complex data models. Social media sites and schedulers tend to require a large number of different models that are all interrelated (e.g., users, groups, posts, likes, friends, etc…) We don’t spend an awful lot of time talking about how to manage the database, and it is easy to get bogged down with the mechanics of getting information in and out of the database.

Another potential pitfall is the all-or-nothing project. As befits our iterative/incremental approach, it is better if you can see a path that includes building new features onto a core so that you can at least finish up with a minimal viable product instead of an ambitious but non-functional mess.