So what does the tech speccing itself look like more precisely? Well, first it’s all about designing your database. To do so, you need to find all the entities in your product, i.e. stores, users, videos, articles, coupons, campaigns, status updates, checkins, the relationship between these entities and each other, and build database tables to store their corresponding data. Then you add columns to these tables to hold that data. Modeling a database for these types of Web 2.0 applications really isn’t that difficult, especially if you’re product is specced out well before hand.

The hard part will be pinpointing special relationships between your main tables, and creating additional tables that don’t have clear names like “store” or “user.” For example, if you want to list all the users that edit an article, you’ll need an “edit” table that associates a user row with an article row and has a column for the date/time of the edit. It’s not a crazy concept to experienced developers by any means, but the point is that there will be harder to pinpoint “junction” tables like this. If you’ve kept your product to a minimum there will be very few of these. One way to know you’re doing too much is if you have too many junction tables. Junction tables fyi typically represent “many to many” relationships, i.e. where an article can have many users that edit it, and each user can edit many articles. For example with SnackSquare, we had junction tables like “CouponStore,” “CustomerMerchant,” “CustomerStore,” etc. There is ways to get around needing these junction tables. The main one is to plan a simpler product that doesn’t need to present every single metric to the end user. Junction tables often embody extra bonus info. Forget that bonus info for your initial launch.  

The final thing you should do is generate a diagram of your database. You can easily generate a diagram of your MySQL tables using MySQL Workbench. Here's an example: