Just because we focus on a Top Down approach, where the specs and “product” lead the way, does not mean we also don't take a Bottom Up approach--which we do simultaneously. The difference is that before each decision we make for the underlying architecture, we have a precise product goal in mind we’re working to achieve. A lot of developers may jump to modeling database tables and columns, and they’re corresponding PHP classes. They’ll imagine in their head features, and instead of making layouts as a way to embody them, they’ll model their ideas at the architectural level. However, we find that there is too much learn through exploring your products through layouts that this is not the right approach. You may end up with a totally different product, as previously mentioned, if you take the time to imagine it through layouts. Hopefully you will because there are so many options of what to build, and you need to be sure you’re building the right product if you’re going to follow through with it over many months while possibly spending lots of money. There’s so many factors to consider, and the best way to consider them is by looking at what you’re end users and customers will be looking at.

So in this part of our speccing process, we’ll come up with the entire database design. Then we’ll prepare empty code files for all the code we anticipate building. Lastly, we’ll pinpoint potentially problematic areas in the application, and discuss and write a plan for how we will address them when we get to them. This way the entire plan isn’t thrown off track when we find a major challenge deep in the app that changes the way tons of other stuff should have been coded, or even the way other features should have been.

One key thing here is that you don’t say to yourself that the product speccing stage is over and now it’s time for the tech speccing stage. While you should do a ton of the product speccing stage first, there should be a lot of overlap in the middle, and potentially the product speccing stage will go until the tech speccing stage is done and they’ll end at the same time. The idea is that while you’re examining the technical implications of the product you’ve planned you’ll most likely find major pitfalls that will cause major time-sinks in development time. Finding them is crucial if you have any hope of finishing your product. Plan to find out that at least one thing is too technically complex to develop that you have to go back and drastically change your product. This will happen, and if you suck it up and make the product changes, you’ll save yourself a lot of pain that would come later--even if it means you have to go back to the drawing board on layouts you have to craft and have to pay your designer to redesign the new stuff you came up with.