I have came here from another thread. I have almost same feelings with Jan Vladimir. We were also working as a software house and while building our mobile apps or customers apps we were starting from creating a no backend app in iOS or Android just for testing the design.

Then if we need a working prototype we were cloning our rest-api backend that we were using on another project and customising it with some shell scripts that we have prepared. This was being very helpful for creating MVP.

After that we want to solve cloning backend issue not only for us and created API Plug for this. We are still improving it but right now you could select your existing MongoDB or MySQL datasource and it automatically generates REST-API source codes in NodeJS or PHP/Laravel in 5 minutes. Also if you want it could output source as Docker containers too. You can try from apiplug.com

I like to prototype an app with pen on paper first. This is the easiest way to get an UI visualized for the team. And on paper i can modify my prototype very quickly. But it's not very comfortable to show workflows.

With the help of Prototyping on Paper i can show my prototype as a "working" app. It's very easy to import pen on paper mockups and create workflows.

I would reformulate the question.

Usually (in my experience), the goal is not exactly to get a prototype asap, but to be sure of what you'd get. So in the lines below I'm answering the question « What's the best way to prototype...»

And the stack itself could only be defined depending of the goals of your product. (And the tips from @JanVladimirMostert are really thoughtful) But ultimately, the difference between your prototype and your MVP is related to scale, reliability, ...

I mean:

• for both, you should set the priorities of your features and your prototype will highlight the main features of your product, which are likely to be the ones you plan to build your MVP for (unless the prototype does make you realize that the killer features are not the one you thought)

• you don't need to build your prototype to scale, whereas this is something important to think about it to set the foundations in your MVP

• you don't need to care about technology debt in your prototype, so if you can use a stack that you know that might cause you issues for the real product (like some IE8/9 incompatibilities, or some legacy stuff you can use to build something quick, even if it's not something you want to use, like building an iOS app with a 32 bits middleware a few months ago, when you knew that 64 bits support was becoming mandatory, ...)

If I wanted to try to summarize it, for the prototype, you'd better choose any technology stack your team is comfortable to build something correct in a reasonable timeframe. But then for your real product (starting with the MVP), some other considerations (risk, perennity, scalability, security,...) might lead you to other choices.

This is a difficult question to answer, I can tell you many ways how not to do it out of projects I've been a member on and then I can tell you how we do it which can still be improved by leaps and bounds. Timeframe is probably also important, our timeframes are usually 3 / 6 / 12 months and project sizes are enormous, so if you're looking for advice to get a small software project in a week, then this advice will probably slow you down.

1. One way to completely miss your deadline by several years (I'm not joking) and sometimes not even make it to the market at all is to hire developers who've never worked with a framework / language, then try to teach them the language and expect them to do magic with the tools they were given and still meet the deadline you've given them.

   • One project I was part of a team of 3 developers and one business analyst, we were brought into the company to build a piece of software that would become a new startup in this company, the business analyst chose the stack, chose the deadlines, chose the budget with no input from our side and without knowing our skill levels. Each developer had to learn one part of the stack, then after three months, it was your job to teach the other developers. What happened was that nobody became an expert on any of the tech, six months later we were still sitting with docs open spending large amounts of time trying to figure out how to do simple things. At the end of the year, only 25% of what needed to be done was done, and the project wasn't usable at all. All the developers left the company and I believe the project was eventually scrapped.

2. Reinventing the wheel - One company where I was part of a team of 20 developers, we were not allowed to use any frameworks. The end results was that developers of different skill levels built an abomination of a framework that was buggy, had over two million lines of code, struggled to scale unless throwing 100 times the hardware at it than what was really necessary, was difficult to debug and did exactly what what we could have gotten with a quarter of the team in 6 months instead of two years had we used a single reliable framework that docs existed for. If you start layering code on top of buggy code on top of more buggy code on top of more buggy code, you can understand the mess you have.

3. Overcomplicated frameworks - one should have a balance between what the framework takes care of and what you can override without the framework getting in your way. Certain frameworks force you to work in a certain way and that way might be great initially, but if that's not what business wants and you can't do it differently, you're kinda stuffed.

   • I'm going to name some of these frameworks with which I've been burned, JSF and JSF2, building that first hello world app is awesome, wait till you have to start doing stuff that the framework doesn't do out of the box, I wasted 3 weeks trying to get something simple working which I could have done in under an hour in JSP or even straight javascript. ExtJS or now Sencha, awesome framework if you do everything exactly as their examples, need to do something that doesn't follow their flow, and you're wasting two weeks building something stupid that you could have done in under an hour in jQuery. GWT, awesome desktop-like apps in the browser, until you had to retrofit those GWT components to do custom things and everything took 10 times longer than it would have taken doing it in straight JS due to lots of boilerplate. Pylons (in python), can't even remember what my gripe was with it, but at the time it was forcing our team to work in a certain way when all of us were used to working in Django. Vaadin is another example, awesome components, until you need to change an existing component or build your own and hook it into their walled garden process and then you have to read through the Book of Vaadin to figure out how to make something simple work and fit within their process.

   • And there's plenty more frameworks I can point finger at. Currently working through AngularJS and AngularDart examples to see if it's worth using in our next project and the amount of stuff it does for your makes me nervous, but it does look promising.

4. Too much reliance on frameworks - frameworks change all the time, it's especially bad if you start the project at version 1 of a framework, then 3 months later you need to spend a sizeable amount of time upgrading to version 2 of the framework, then by the end of the year, the framework is outdated again and you have to spend more time upgrading frameworks. If you're relying heavily on a framework for certain functionality, be aware of that and design in such a way that you can easily rip out that framework if you need to and easily replace it with something else or your own code.

5. The language and framework you choose is important, I've seen a startup fail due to choosing a certain language and the language made it very difficult to scale. Obviously they had some bad design choices as well, but the team was told from the beginning that they will just throw hardware at it, so when they combined Ruby on Rails with some very bad architectural choices, they eventually couldn't scale that software, had to rebuild large chunks of it and ran out of money.

Here's what I've seen works really well and what we're using as well

1. Build APIs for everything, no frontend should be connecting straight to a DB/backend and manipulate data directly on the database. When you design an API, you automatically make it a lot easier to scale your software later on.

   • You also get to think thoroughly about the data you need, the type of questions you need to ask while designing the app, it separates your UI from your business logic and by the third time you've changed your UI due to partners changing their requirements, your API will probably still be the same, so it's just UI changes. It also means that when you are told to build a native mobile app, you simply plug that mobile app on top of your API and you get to re-use all the business logic.

2. Keep It Simple - I've worked on a project where the project manager went ballistic on security, the team spent three months building a super secure authentication system that could plug into LDAP, had layered roles and permissions, allowed you to authenticate via biometrics, had two-factor authentication, etc. This was for an internal system which 9 people would use and actually all they needed was a username+password type login which we could have built in under a day. So always ask yourself, what is the bare minimum I can get away with while keeping in mind that you want to do more advance stuff later on.

3. Containerisation, LXC or Docker if you prefer - building docker images are saving us a ton of time and saving use from wasting time trying to debug stuff that works in dev but randomly stops working in production.

4. Don't do premature optimisations, your specifications will change and it always does, it's called pivoting in the startup world. We actually avoid NoSQL databases due to their inflexibility, we build with SQL which is a very versatile database and then once we are in production with a bunch of beta testers and recognise places where we would benefit from other databases, we would introduce them if SQL doesn't do a great job for that specific use-case. Since everything is running behind an API in any case, it's very easy to swop out the SQL database for the NoSQL database.

5. We find messaging between applications very useful, instead of building one giant app, we build smaller specialised apps that we hook onto a queue and the smaller specialised apps communicate with each other. This means we can scale easy if we need to, changing one app is easy as it doesn't affect the other apps.

6. Understand what the user needs and not what they want, users usually only knows what they want when they see it, what they tell you they want is usually not what they really want, so understanding user requirements will go a long way to getting your prototype out quickly out.

7. Be an expert on the stack you use, if you use tools that you know very well, you will get a lot more done than having to use new tools you haven't used before. I used to switch to a new programming language every 6 months and a new framework twice during that 6 months, I learned a lot, but at the cost of overworking myself to get projects out due to being slowed down by new frameworks and new languages. Now that I stick to one stack and only occasionally maybe once in a blue moon change something in the stack, I get to churn out more than a small team would have been able to. By knowing the stack, you would also have knowledge on what plugins / libraries to use when, eg need a PDF generated, use this, need to send email, use that, need to connect to a queue, use that, etc.

Tools we use:

• Java + Spring MVC for building APIs, Spring MVC can do pretty much anything you want it to do and when it can't, you can completely take control of the process. We have considered Scala as a Java replacement, but haven't gotten there yet.
• RabbitMQ for passing messages between applications and Spring AMQP which with a few lines of configuration makes sending and receiving messages a breeze. .
• Hibernate we use for modelling the database, we don't handwrite much of it, we us a tool called Spring Roo to generate the models for us, then use IntelliJ's push-in refactoring to clean up the models a bit and get rid of the complex aspectJ that's being generated and we use the built-in DDL in Hibernate to create the tables and columns for us (only once the project is ready for launch do we introduce Liquibase which is like version control for your database which is a little more reliable long-term).
• We use a sharded Memcached to do caching which we hook into Spring Cache which allows us to do caching simply by adding @Cacheable annotations in the code (we've looked at Redis before, but will only consider it if Memcached struggles to keep up which it hasn't until this far for what we use it for).
• Frontend, we build in Dart, HTML5, CSS3 (we use Bootstrap's Less files as it gives us a nice base to start from). Currently we are not using any framework, it's all custom-built stuff which we re-use between projects, but we are considering Angular Dart 2 since it's much better documented than our custom system and will save us a lot of time on new projects.
• We avoid JavaScript and choose Dart over JavaScript due to Dart being much easier to maintain.

I think it really depends on the product you want to test. You could probably prove there is a need by using existing tools without even building a prototype. A few examples:

• If you wanna start an organic baby food company: make a few samples yourself and try to sell them via facebook groups or reddit.

• If you wanna start a t-shirt company with unique designs: print a few t-shirts using something like customink and open a shop on etsy.

• If you wanna start an personal assistant service: build a website on Wix or Squarespace that has a mail address and perform the first tasks manually.

This probably won't apply to every idea, but I think most can be POC'd manually instead of building a working prototype.