Prototyping · Technical Architecture

Prototyping a Tech Product: What are the best practices from a technical/architectural standpoint?

David Gold

August 8th, 2013

Below are some variables I value when deciding how to create a prototype.  Please add/respond/devalue.  Thanks in advance for your feedback.

Functionality: Not perfect but works as intended
Deployment speed: I would want all the (inexpensive) tools that will make my deployment faster
Legal ramifications:  If I go OSS, will it screw me up past prototype phase?
PAAS:  Do I use one to save time, if so which and why?


Anonymous

August 8th, 2013

Go with what you know.

If you are not technical, I suggest you get someone on your team who is. A non-technical person is not going to make wise decisions on these topics. Further, when a technical person joins you they may not be in agreement on one or all of the decisions that were made before they joined.

If you are working with an outside technical firm, they should have expertise in some tech stack. That expertise allows them to focus on the goals of your product, and not the plumbing.

Mohammad Forouzani CEO at Forecast.net

August 8th, 2013

I agree with Dan - dont try to pick the best X, or the most efficient Y - just use technologies you are most familiar with. The point of a prototype is to prove a concept or a business model, or maybe just assess interest. Dont waste time trying to pick the "best" things, only pick the things you are most familiar with and will get you to prototype launch as soon as possible.

Remember, if all goes well, you can rewrite the whole thing without too much effort, it is after all... just a prototype.

Anonymous

August 8th, 2013

(This may be more relevant to HW then SW, but still worth considering:) Any thought to having a limited rollout? To beta customers that are willing/able to provide substantive feedback?

David Fierbaugh Senior Mechanical Engineer at Microsoft

August 8th, 2013

There's prototyping (roughly same form factor and technology as final product) and then there is doing a proof of concept. A proof of concept does not need to resemble the final product except for trying to show the functionality. It will typically use existing off the shelf components and software to speed development along. The things you learn in a proof of concept can GREATLY ease learning those same lessons after building a prototype. You may discover features that just don't add the value you expected, or are technologically difficult to include in the initial prototype; and you will likely discover features you hadn't thought of which greatly enhance the final product.

Christopher PhD President at Restisense Corporation

August 9th, 2013

This may be obvious, but I would just like to add that even getting a bid to build a prototype is considered public disclosure by US Patent law. Ensure that you get non-disclosure agreements to protect your intellectual property everytime you discuss the prototype with a new entity. 

I agree about the modularity and hiring people who have done similar work before. There is a big difference in the approach to building a prototype than to building a production model. Skunkworks are better for the former. 

Expect several iterations. You learn something each time. I am currently building prototypes for two clients. They are each in their third generation. The good news is that prototypes can be rapidly developed and may not take long between iterations, especially if you have multiple options and start ordering parts for all options from the beginning. 

Luke Szyrmer Forward-Thinking, Creative Software Product Manager and Author

August 9th, 2013

Modularity's pretty important, in my opinion, as it's then easier to add/remove features as you get feedback. So for example in software, paying a lot of attention to interfaces and boundaries in the code makes it easy to swap in/out features.