I think deciding whether to build or not to build reflects the larger paradox of programmers saying over and over again that we shouldn't re-invent the wheel...but then doing it anyway, out of a desire to get a perfect/"right" solution. Or maybe just out of an urge to understand the system fully (this is why I myself re-invent wheels all the time, because I want to understand the deep logic behind the "right" way). And yes, if you have all the time in the world, you can probably make a beautiful perfect thing. But we don't, ever.
Anyway, here are some examples from our own org where hindsight is 20/20, and where the decision was "code the thing fully, or not?"
- Our contact form. Originally built as its own app within Django, probably out of a desire to do things the "right" way, i.e. the Django way, i.e. to have the url map to a named view of an isolated app. However, this meant that it had to be configured with Mandrill, that it stored every communication in the database, and that it required tech's intervention to modify - i.e. a lot of work, from the outset, and gauranteed to be a maintenance issue. In addition, the mail got sent - UNFORMATTED and in a single thread - to the poor person in charge of dealing w/ inquiries, making their life miserable for years.
New solution: the 'wrong' way. Hard code the contact links with a mailto: address, or better yet, to a /contact/ url that is a flat page (Django's equivalent of WP pages that users create, populate, and make urls themselves). That page, in turn, houses a Google Form. Yes, you have to code a bit to get the Google form set up, but it's much easier for non-tech folks to modify the page and the form, and storage is Google's problem (for better or worse...)
- Our mail, in general. The original goal was probably to send alerts and notifications from the CMS. Mandrill again, + Django's own system. Okay, fine, worked for us.
Suddenly, though, we're using it for non-alert stuff like marketing emails to members. And marketing wants to A/B test templates, make their own templates, keep a database of opens and geography and whatever, all that good stuff. And membership (its own dept.) too. Mailchimp is the far more obvious solution for this, albeit paid one - but one of our big realizations was that if you can pay for a product that is built to do exactly what you need to do, it's far better than trying to build it yourself.
- Our events. We originally build our own RSVP system, and it was clunky as hell (let's just say that Django does not make it easy to make interfaces sing) and entangled with the email system described above, and yet unable to integrate in the right ways with the other depts.' needs without a lot more code on our side. And the events dept. started wanting ways to include calendar links etc. -- well, guess what, Eventbrite already does a lot of that. So again, there's a free product out there that does exactly what's being asked. So why are we trying to build it, or in this case, clinging to an old system that no longer serves its purpose)?
(Michieviously, I might extend this to publishing in general: as I've said, I think Wordpress got the model -- in the OOP sense-- down first: headline, author, body, summary, seo url, category, tag -- why do keep rebuilding this? But yet we do, eh?)
So, for us, it came down to a paradigm shift in recognizing that the departments had needs that couldn't and shouldn't be fulfilled by a single monolithic app or interface. It turns out that there's already integration between Salesforce, Mailchimp, and Eventbrite - more things we won't have to code. And so we can turn our resources full force on the question of how we're building stories. Or at least that's the plan.
And in general, the lesson learned is: have a laser-sharp clarity about what, exactly, the feature you're contemplating is supposed to do. Write it down somewhere. And when someone suggests extending it for another thing, then it's time to regroup and rethink.