[{"data":1,"prerenderedAt":122},["ShallowReactive",2],{"writing:\u002Fwriting\u002Fthe-cheapest-architecture-decision":3,"writing:extras:\u002Fwriting\u002Fthe-cheapest-architecture-decision":101},{"id":4,"title":5,"author":6,"body":7,"canonical":85,"coauthors":86,"date":87,"description":88,"draft":89,"extension":90,"featured":89,"meta":91,"navigation":92,"ogImage":85,"path":93,"readingMinutes":81,"revisions":94,"seo":95,"stem":96,"tags":97,"updated":85,"__hash__":100},"writing\u002Fwriting\u002Fthe-cheapest-architecture-decision.md","The cheapest architecture decision","trevor",{"type":8,"value":9,"toc":76},"minimark",[10,14,19,27,34,38,41,44,50,54,57,69,73],[11,12,13],"p",{},"The easist thing to measure in business is how much something costs. This\ncan be aggregated to true subscription or tooling costs or the hours put\ninto implementation. What's harder to measure is everything that comes after.",[15,16,18],"h2",{"id":17},"it-is-more-than-what-you-see","It is more than what you see",[11,20,21,22,26],{},"When building products or tools, the approach I see most often used is \"how do\nwe get this ",[23,24,25],"em",{},"thing"," right now\". I'm not saying that this is never the right answer,\nbut in my experience it almost always leads to problems down the road.",[28,29,31],"callout",{"label":30},"The thing that sticks with me",[11,32,33],{},"The cost of a tool is not its price. It is its price plus the cost of maintenance\nplus the cost of the users exerpience, internal or external.",[15,35,37],{"id":36},"immediate-gratification-vs-longevity","Immediate gratification vs. longevity",[11,39,40],{},"When looking to build a new product or feature, there is a tough balance between\ngetting that thing out as soon as possible versus getting it out in a state that\nis going to last. Often I will observe the prioritized objective to be to get it\nout as fast as possible. This could be to beat a competitor into the space or to\nmeet an objective of n-number of new users. The latter is my least favorite reason\nto do something.",[11,42,43],{},"When I see these used as the driving force behind the effort, it usually comes\nalong with taking shortcuts or making decisions that suit the immediate need but not\nsomething that will scale when needed.",[45,46,47],"blockquote",{},[11,48,49],{},"I'm not saying that products and features can't be built quickly and I'm not saying\nthat quickly made things can't scale. What I am saying is that pressure for delivery\ncan have a direct impact on the products future success.",[15,51,53],{"id":52},"what-is-the-true-cost","What is the true cost",[11,55,56],{},"Beyond the obviously identifiable hours worked and tool pricing, there is a cognitive\ncost to the end users and the team that supports them. There isn't a formula for figuring\nout a number for this and this isn't something that can usually be listed as a cost in a\ndevelopment plan. This doesn't, however, mean that these things shouldn't be taken into\nconsideration. These invisible costs can often be the highest impact to the end product.",[28,58,60,63,66],{"label":59},"The eternal conflict",[11,61,62],{},"The debate I hear most often between a designer and a developer is this:",[11,64,65],{},"Designer: The product doesn't matter if it isn't clear how to use it.\nDeveloper: The product doesn't matter if it isn't functional.",[11,67,68],{},"They're both 100% right. Your product could be the most performant system in the world,\nbut if the user can't figure out how to use it all of that performance is lost.",[15,70,72],{"id":71},"what-i-would-tell-someone-making-a-plan","What I would tell someone making a plan",[11,74,75],{},"There will always be a give and take when balancing delivery speed and solution\nrobust-ness. For me, speed for the sake of speed is the worst decision influencer.",{"title":77,"searchDepth":78,"depth":78,"links":79},"",3,[80,82,83,84],{"id":17,"depth":81,"text":18},2,{"id":36,"depth":81,"text":37},{"id":52,"depth":81,"text":53},{"id":71,"depth":81,"text":72},null,[],"2026-08-07","Often we target profit margins; the lowest cost tool or the quickest to development. More often than not, however, these decisions don't end up being the cheapest.",false,"md",{},true,"\u002Fwriting\u002Fthe-cheapest-architecture-decision",[],{"title":5,"description":88},"writing\u002Fthe-cheapest-architecture-decision",[98,99],"Product","Research","KiNH5F2_QiFi_564sHlaacwL6IqOUOmjUCjJx7uNaJQ",{"record":102,"byAuthor":121,"newer":85,"older":85},{"id":103,"title":104,"bio":105,"colorToken":106,"extension":107,"links":108,"meta":110,"name":111,"now":112,"order":81,"slug":6,"stack":113,"stem":117,"tagline":118,"yearsExperience":119,"__hash__":120},"authors\u002Fauthors\u002Ftrevor.yml","Product Manager","I build products to solve real problems with the lowest barrier of entry. My number one goal is to make something better, not to make a profit.","author-a","yml",{"email":109},"trevor.wood@loweryandwoodconsulting.com",{},"Trevor Wood","Food On The Streets (Food Truck tracking), Puckup (drop-in hockey organization), Corporate Needs",[114,115,116],"Discovery","SQL","Vue","authors\u002Ftrevor","Five years in product, attempting to solve real world problems.",5,"Up3xIjrID3xk7GVWxHJIi-1X6kI4NgQybAakhbS-_7s",1,1786257317914]