We are moving away from high fidelity prototypes to low-fi whiteboard sketches and prototyping in the actual application.
Occasionally we do pixel perfect prototypes with clickable simulated logic and all but we can't maintain it all, and we try to use it only when something is logically complex to reason about without pictures...
It's about as fast to do in the real code with mocked services when you have the application already there.
It requires more collaboration but that can only be a good thing.
I agree going without prototypes or PSD can be a fast way to grow - that's how our company built it's initial MVPs and became profitable in the first place. The PSD's and pixel perfect prototypes come in handy when the non-engineering parts of the company are so intimate with customer's wants, they are very precise about the requirements (especially to fit in an existing market).
Hmm so, it looks to me precise prototypes are good for precise requirements, while vague requirements are better when engineering is also customer development, and customer requirements are not known precisely yet.
In our company we have 1.5 designers and 5 in engineering and we're good with maintaining the prototypes. The designers have to do other non-digital stuff like print media too...Maybe our web applications are mostly CRUD's with permissions so it's easy to maintain?
We have 6 teams with full stack developers and testers, sharing a (too) small group of UX experts. Each group have a product owner focusing on a specific area, but there is a lot of overlap.
But the general idea is to avoid big upfront design and instead try and retry the design.
Occasionally we do pixel perfect prototypes with clickable simulated logic and all but we can't maintain it all, and we try to use it only when something is logically complex to reason about without pictures...
It's about as fast to do in the real code with mocked services when you have the application already there.
It requires more collaboration but that can only be a good thing.