[btbuildem]

I've done this a number of times, it seems to work quite well, and I don't think of it as malicious.

A "softer" way of handling this is to assign the prototyping / PoC development to a different team. The tribality / process worship / power dynamics between teams virtually guarantee that no code will be reused between the PoC and prod.

[delecti]

Do you have experience with that second approach actually working? I'm currently stuck maintaining and upgrading multiple microservices that are a total mess because nobody understood how they were built, and we just had to cope with their weird spaghetti.

[btbuildem]

The way I've seen it work is that the PoC defines the features, then the dev team breaks this down and implements it any way they see fit. It's up to the teams to maintain their best practices and interoperability of the different solutions. Whomever built the PoC doesn't face any of these constraints, their focus is to help finalize the functional spec.

[auggierose]

You also lose knowledge gained through building the PoC.

[btbuildem]

I think that depends on why you built the PoC in the first place. Looking through the comments here I get the impression most people are looking at it as "is this technically feasible", while in my experience a PoC / prototype is usually made for business / usability validation ("is this valuable / will people use it").