This chapter utilizes the case study from the previous chapter to build a full fledge Micro Distributed Application within the WordPress framework. This distributed JavaScript application will facilitate the reservation of a table at a given restaurant. This solution parallels an offering that is currently available as a WordPress plugin for OpenTable with one major caveat and this being that the solution defined here is a Micro Distributed Application whereby the framework of WordPress is simply implemented as the housing structure for the MDA. This structural configuration of the system created facilitates the creation of the application by leveraging those components of each given domain so that they may fulfill their given intent and thus alleviate the development effort from cross pollinating each domain with excess that they need not be burdened with. Each language construct presents a direct benefit from its implementation and as such it becomes a necessity to be able to enable the construct to function under its primary intended role because to fit the paradigm to anything other than simply implies a farce and the burden of debt that has no place in the discussion. The process outlined here is especially susceptible to this form of egregious act since there is an interaction between two distinct languages, PHP and JavaScript and therefore it becomes a simple act to cross that boundary constraint of functionality where one of the constructs are used in a manner for which a better fit would have been the other. It is this alignment that will allow for the creation of the MDA that will become portable to other landscapes and help diminish that technical debt that is inherently incurred from the onset of any development effort. While the decision for the housing of the MDA was determined to have been WordPress there is no reason why it could not have been an alternative such as Joomla (www.joonla.org) and as such it becomes a matter of scalability to be able to create that boundary constraint for delegation. It becomes imperative to be able to sanction work so that the pivot and shift that is often required by business from technology may be hedged. This hedging will only occur if teams are able to segregate along these fixed lines where the domain in question becomes regulated to a prescribed role and where that role could be replaced if needed by another actor, much like a cast member in a play can have a substitute if needed so too must development teams look at the technological endeavor. Development teams often do not resort to this mode of operandi because of the tax burden that it places on them. Software developers want to dictate and they want to force upon the domain their will at times which diverges from the philosophical outlook that is needed for solutions to remain resilient. Taleb (2014) makes the argument in his book ‘Antifragile: Things That Gain from Disorder’ that it is those systems that are exposed to flux that become antifragile as opposed to those systems that retain an equilibrium point because of no flux since such systems tend to tumble when the conditions change. This can be see in the world in abundance such as in the stock market with quantitative easing for example, so if teams are to build the best possible software system then they must ensure from the onset that resilience is built into the fabric of the solution. To meet this goal it means that development teams need to place upon their head the hat of the computer scientist where it forces them to think in generics and strip away the triviality. For software systems to have resilience teams need to not only solve the general problem frame, but they must also work within the confines of the doctrine. Development teams must be willing to put aside the shortcut and adhere to that best practice doctrine to infuse that degree of resilience inherently into the systems that they build.