When implementing new product features it’s important to consider future manual labor and support burdens. Often, there are several different options available with vastly different on-going implications. Personally, I can think of at least two features where we took the easier product engineering route and had north of 5x the manual labor to deal with due to the decision before we finally got back to upgrading the feature and did it the better way.
Ask yourself this: does spending an extra 50 or 100 engineering hours result in saving 250+ hours in the future? It might seem painful to allocate the software development time to the feature now, especially if there’s some quick and dirty solution, but future productivity could be mortgaged. Even though I’m an advocate of keeping things simple and getting the minimum viable functionality out the door, sometimes it’s important to consider the minimum viable and sustainable functionality.
What else? Do you consider future manual labor when adding new features?
David Cummings on Startups 
In the early days of my frist startup, we classified some processes as “MRM.” Or as we dubbed it “Monkeys Running at Midnight.” It was processing that we hadn’t automated or written into the product yet but could accomplish with people doing it manually. It gave the perception to the customers that our scope was bigger than we really had but also gave us time to figure out if customers we’re actually using that feature before we invested in the engineering hours.