I spent the majority of the day setting up the initial dev environment for Cushion. No matter how many times I’ve done this, it always takes longer than expected. Once everything was up and running, I started building the most basic view—the project table. This will list all of the projects, along with their color, client, and incomes—deposited, pending, and potential. Eventually, it will show other information, like flags, but I’m getting ahead of myself.

While writing the basic outline for the app’s models, I realized that I was straying from the core feature set of the app. Somewhere along the way, I dropped my guard and started including additional features that would be nice eventually, but not necessary for the first version. I widdled everything down and ended up with three core data models—clients, projects, and invoices.

A “client” is simply used to group together projects, with only a name and color besides the relation. A “project” represents any job or piece of work and will be the heaviest model of the entire app—almost everything will focus around the project. An “invoice” is used to make up the various incomes of a given project, based on its status of paid, pending, or potential. I have no plans to include invoicing as a feature of Cushion—I just need each invoice’s amount for calculating income for a project. I do, however, plan to tie closely to other invoicing services, so the process of adding an invoice is not duplicated.