Sure. First off, I should say that as the lead developer I took ownership of these decisions. Design by committee is certain death. I didn't ask for permission; I sought input from various stakeholders (often one-on-one) and made it clear that while the final implementation might differ from their suggested approach, I would be proposing solutions that took everyone's basic concerns into consideration. After gathering feedback, it would be several weeks before a new iteration was put forward for review. Stakeholders could use and interact with it. More feedback would be solicited and then the next iteration would begin, again taking the feedback into consideration but not making any promises. I had managers who were furious with me for not kowtowing to their demands, but I'd produced a very successful prototype (featured at Blackhat 2013 and Mobile World Congress) and they grudgingly had to admit that the results were better than anything the previous design-by-committee approach had produced.

* Design - what is the product supposed to look like?

Good design is not part of the DNA of large enterprises. This makes it low hanging fruit for upstart competitors to come in and impress clients with the usability of their "slick" design. Because purchasing decisions are increasingly being influenced by the people who will actually use the product, this gives them a tremendous competitive advantage. In large software teams, its typical to begin design with the data model, and progress through successive layers of code until the data finally goes splat on the users screen in a great meaningless pile. Smaller companies, especially ones with a legacy in web application design, have figured out the value of designing the User Experience first, and then developing the lower layers. This is not without tradeoffs; a new use case that you never envisioned can force changes to the data model that break compatibility. I found that working from both ends of the stack (prototyping the UX while simultaneously considering the data model and future use cases) was beneficial. Anyway, it's amazing how much software actually gets built without anyone even thinking about what it should actually look like to the end user, until the very end. When managers come from the era of punch cards and PDP-11, well, this is just how it is. You have to fight that mentality by pointing out the contracts they lost because the product looks like crap.

* Testability - how do you intend to test your code?

It amazes me in this day and age that there are still product managers who believe automated testing is a waste of time. I set out a goal of having 100% test coverage, which I maintained for quite a while. Gradually the test coverage declined as new use cases needed to be supported. It simply wasn't possible to cover off every error case or alternative configuration of the product, but I still keep coverage between 80 - 90%, with most of the uncovered code being error handling corner cases that are not supposed to happen in production, or code that exists purely for running in a non-production environment. Incidentally I use Mocha and jscoverage for this, but there are lots of options. The important thing is to choose one. Tests are triggered from npm, which is in turn triggered from make, which is in turn triggered from Jenkins every time code is submitted to our repository.

* Documentation - how will the code, product be documented?

Initially I set out with a goal of having the project be "self documenting". I settled on having an API that roughly follows HATEOAS principles - the idea being that given the root URL, a user could easily discover and navigate their way through the rest of the API with a web browser. I then used tools like RESTClient and POSTman along with Selenium IDE to automate some REST API developer tests. The output of these could be cut and pasted into an OpenOffice document that I submit to our code repo along with a PDF version. This isn't as fully automated as I would like, but I've got an excellent Install Guide, Developers Guide and User's Guide that can be easily updated and are readily available. They were created early in the project, in tandem with development. Tasks were not considered complete until the documentation had also been updated. QA helped ensure this.

* Tooling - what's your preferred dev tool chain?

This is purely a personal preference, but I use Sublime for most of my JS related development. Outside of that, I'm a dedicated vim user. I dislike big IDE's because I feel people and projects become dependent on them and they foster unnecessary bloat and complexity because they don't require a developer to hold the whole design in their head. An ongoing problem is poor quality code getting into the repo and not being flagged until a bug surfaces or a build fails. I wanted to move that feedback much further forward in the development process and make it immediate, to catch problems before they ever got submitted. For that, I wrote a sublime plugin for jslint (Sublime-JSLint) with a lint-on-save capability. Any time a developer saves a file, they get immediate feedback on whether it passes the linter. This gets repeated on the build server, and lint warnings will literally break the build. As a result, all of our JS code is very consistent.

* Code architecture - What's your design philosophy?

In addition to web-first, mobile-first, and API-first approaches, you might have strong ideas about MVC architecture, REST API best practices, abstraction oriented architecture, OO, Functional programming, etc. Being trained first as an artist, my preferences are pragmatic. I want strategies that will get me from concept to product as quickly and easily as possible. I've found an API-first approach with an abstraction-oriented architecture to work well. I began blogging about REST API best practices as a way to gather information on the topic. I also wrote a couple of pretty bad "REST" APIs before I started getting better at it. Now there are frameworks like Sails and LoopBack that will guide your API design.

* Prototyping - straight to product or prototype first?

I do believe in prototyping first, but you should be willing to view the prototype as throw-away work. Prototypes are often thrown together quickly and incur tons of "technical debt" almost intentionally. Trying to productize a prototype can be more difficult that simply starting from scratch. A lot of times managers will wonder what the hell is taking so long... they saw a working prototype and they've already got customers lined up to take it, so where's the product? They don't realize the prototype is all smoke and mirrors running off a flat file and your personal Google API key. You may need to explain that the prototype is not suitable for productization, and why. On the other hand, if you do want to go from prototype into production, you need to be careful when you build the prototype not to incur the technical debt of a quick-n-dirty mockup, and figure out the path for getting from prototype to production. Things like replacing the data access layer with something that talks to a real database, and having a proper configuration file, etc.

* Delegation - how to structure for future delegation?

API first design is helpful because it provides a sort of contract by which various components can interconnect. Although I initially wrote the API, server, mobile app, and web interface to the product, the API allows any of the client applications to be forked off into a standalone project. Eventually we did this with the mobile app. This is where the documentation started to prove its worth. The point is to think about how the project and the team is likely to grow, and which parts could be handed off to another team, and how to define clear boundaries with a clean interface between them.

* Security - how to audit the security of your app?

It's often just assumed that applications will be secure, and then of course they aren't. Session hijacking, SQL injection and cross-site scripting vulnerabilities have been present in most of the web-based user interfaces of projects I've reviewed. Enterprise sw developers tend to be unaware of what these attack vectors are and how they work. There's no substitute for being knowledgeable about web security but there are tools like Nessus and Skipfish and various penetration testing tools that can help. I guarantee they will turn up security issues you never knew existed. If you can automate the process, great. If not, making a security audit part of your QA process is important.