You’ve come a long way, and it's time to show it. This will be your most advanced project to date, and if you put creativity into it, it'll hopefully be the thing you want to show off most prominently in your portfolio.

You get to call the shots and invent your own idea, choosing a framework and tools that are appropriate for what you want to build. Pull from everything you've learned so far, and tackle something that'll push you a little outside of your comfort zone.

Make sure you review your project proposal with your instructor so you can make sure it's something you can accomplish in the limited time we have, and make sure it's something that'll be impressive visually. Sometimes people do judge a book by its cover – or an app by its design.

Your app must:

• Build a full-stack application by making your own backend and your own front-end
• Have an API of your design
• Any data that can be updated or deleted must be user owned and protected or controlled by an ACL (An ACL is a stretch goal).
• Have an interactive front-end, preferably using a modern front-end framework
• Be a complete product, which most likely means multiple relationships and CRUD functionality for at least a couple models
• Use a database, whether that's one we've covered in class or one you want to learn
• Implement thoughtful user stories that are significant enough to help you know which features to build and which to scrap
• Have a visually impressive design to kick your portfolio up a notch and have something to wow future clients and employers
• Be deployed online so it's publicly accessible
• Not have any obvious user facing errors.

On the first day of project worktime, you must commit:

• A client README with user stories and wireframes
• An api README with an ERD

• You must have at least one commit on either your client or api repo for each day of project worktime.

• A working API, hosted somewhere on the internet

• A working client app, hosted somewhere on the internet that consumes your API

• A link to your hosted working app in the URL section of your Github repo

• A git repository hosted on Github, with a link to your hosted project, and frequent commits dating back to the very beginning of the project

• Two README.md files with:

  Client:

  • An embedded screenshot of the app
  • Explanations of the technologies used
  • A couple paragraphs about the general approach you took
  • Installation instructions for any dependencies
  • Link to your user stories – who are your users, what do they want, and why?
  • Link to your wireframes – sketches of major views / interfaces in your application
  • Link to your pitch deck – documentation of your wireframes, user stories, and proposed architecture
  • Descriptions of any unsolved problems or major hurdles you had to overcome

  API:

  • Links to your client-side application, deployed client app, and deployed api.
  • An ERD
  • A list of your API routes
  • Installation instructions for any dependencies
  • Explanations of the technologies used
  • A couple paragraphs about the general approach you took
  • Descriptions of any unsolved problems or major hurdles you had to overcome
  • Both client and api repositories must be pinned on your GitHub page

IMPORTANT If you do not meet the planning or daily requirements, you cannot meet expectations for this project. The final submission that you must be the project you presented to the cohort.

Your consultants will give you a total score on your project as an aggregate across all feedback categories:

This will serve as a helpful overall gauge of whether you met the project goals. But more important than your overall score is your feedback, particularly in individual categories - this will help you identify where to focus your efforts for future projects.

• Don’t get too caught up in too many awesome features – simple is always better. Build something impressive that does one thing well.
• Design first. Planning with user stories and wireframes before writing code means you won't get distracted changing your mind – you'll know what to build, and you can spend your time wisely by just building it.
• Don’t hesitate to write throwaway code to solve short term problems.
• Read the docs for whatever technologies / frameworks / APIs you use.
• Write your code DRY and build your APIs RESTful.
• Commit early, commit often. Don’t be afraid to break something because you can always go back in time to a previous version.
• Keep user stories small and well-defined, and remember – user stories focus on what a user needs, not what development tasks need accomplishing.
• Write code another developer wouldn't have to ask you about. Do your naming conventions make sense? Would another developer be able to look at your app and understand what everything is?
• Make it all well-formatted. Are you indenting, consistently? Can we find the start and end of every div, curly brace, etc?
• Comment your code. Will someone understand what is going on in each block or function? Even if it's obvious, explaining the what and why means someone else can pick it up and get it.
• Write pseudocode before you write actual code. Thinking through the logic of something helps.

You may choose to redo project two for your capstone project. Please remember that redoing a project means that you have one less thing to put in your final portfolio. There are special requirements for redoing project two:

• In order to meet requirements, your new full-stack app must have a new feature that was completed during capstone project week.
• The client must be in Ember. Ember is not required if you do not re-do your second project.
• A re-used API must have one new resource and one new relationship.

Think of how helpful sites like Quora and StackOverflow are. Maybe there's some other niche, or some surprising twist you can add to the question-and-answer game.

Keep up with your vehicle as you commute every day to your final weeks of WDI save things like mileage, last inspect, oil changes, and maybe even receipts and important document you need to have backed up.

Imagine a realtime messaging client, but with private messages, an inbox, unread messages, and who knows what else. This is your chance to re-invent email as we know it.

• HackDesign
• Visual Design Hacking
• Web Design For Non-designers

1. All content is licensed under a CC­BY­NC­SA 4.0 license.
2. All software code is licensed under GNU GPLv3. For commercial use or alternative licensing, please contact [email protected].