Wow! Lots going on in this query - let's unpack a few:

1) Ries intimates in his book that ideas are plentiful, it's the execution that is difficult, and that's why he suggests to relax about people stealing them.

2) If you hire an outside agency, you'll enter into an IP agreement which either has you owning or sharing the rights to the solutions that are developed. You can/should specify the ideas as being proprietary in these agreements. Consult a lawyer.

3) To test an MVP, you don't necessarily need to create a working app - you could validate the assumptions you're making using other mediums. I've seen MVPs for solutions/services that were first enacted using people, cell phones, clip boards and paper. You want to validate the IDEA to see if it has a customer.

4) Consider learning how to code yourself. Since you'll be building an MVP, you just need to learn enough to demonstrate the core idea(s) and get them in front of customers and maybe even investors or crowd-funders.

5) Consider attending Lean Startup Machine, Hackathon and Lean Coffee events and user groups in your area to meet and network with potential candidates to help you build your MVP and maybe even join your nascent team.

6) Start using the words "yes, and..." more and "yes, but.." less when thinking about what you can do. It helps to unlock latent ideas and strategies.

Good luck!

What troubles me about this question is that I don't have insight into your definition of "slow" and direct observations of the developer themselves. While I do appreciate time and budget constraints, often expectations of what software development entails are at odds with these things.

In general, if progress feels slow it is likely because the development cycle is too big. Consider using an agile framework like Scrum or Kanban to manage how much work is taken on and when it will be reviewed (eg. every week or every two weeks). Also consider "sizing" the work items so that they can be completed (ie. coded, tested, deployed into production) every 1-2d. This provides a benefit of lightening the load while improving progress through a backlog and providing much more rapid feedback on whether you're building the right things.

Finally, set your expectations accordingly: Software development is all about wrestling with wicked problems using a tractable medium. You likely won't get everything you want for a certain date, but you can control getting the most valuable things done for the time and money invested.

Good luck!

In brief: "Not very."

It's much more important to demonstrate a rough, working product that has customers willing to use it rather than a shiny prototype that has no customers.

By the time you're seeking VCs or angel funders you should be able to speak in terms of how many people are using the product and what your real expectations of a customer base are based on real-world feedback.

The question you need to be asking potential customers is less "would you use this?" and more "how would you use this?", "what would make this perfect for you?", and "how would this change the way you do things now?".

To this end, get a minimum viable product in front of customers and run through the build-measure-learn feedback loop. Accelerate the application of your learnings into the product, get some passionate early adopters and build a community of support that you can then take to investors as validation of the ideas.

Of course, you could also learn from this exercise that your product isn't that interesting to customers. Better to learn that cheaply rather than after sinking a lot of money, blood, sweat & tears into a polished/pretty prototype.

Good luck!

I suspect the problem isn't so much the lack of hours in the day, but the ability to "see" your work and know what you're capable of handling so that you can actively make decisions about what to take on and what to defer.

In agile/lean circles we call this "limiting WIP" or work-in-progress. As human beings we have a finite WIP capacity, and we benefit from keeping it low so that we complete what we start (which has a powerful psychological effect). One way of doing this is to set up a personal kanban board so that you can visualize your work and control how much gets into your WIP queue, worked on and then completed.

A fantastic, easy-to-read resource for this is Jim Benson and Tonianne DeMaria Barry's book, Personal Kanban: Mapping Work, Navigating Life[1]. It quickly explains the theory behind the technique (adapted from lean manufacturing techniques) and how it can be readily applied in a variety of contexts.

Nearly all customers I've coached to adopt this technique have benefited from it as it leads to a deeper understanding of the work they do and how they do it.

Good luck!

[1] http://www.amazon.ca/Personal-Kanban-Mapping-Work-Navigating/dp/1453802266

First, realize that change isn't an overnight process - it can take time to make the case for trying something new to your superiors. Second, try to understand (if possible) what motivations your team lead could have for being "stuck in their ways" - this can provide clues on the types of strategies you can use to help persuade them of your perspective.

Instigating a change often requires understanding the context or situation you're in, which is likely beyond the scope of this question. However, a good place to start is by reading Mary Lynn Manns and Linda Rising's book, Fearless Change: Patterns for Introducing New Ideas[1]. It provides a series of change event patterns that you can adopt/adapt for your purposes depending on the situation you find yourself within.

A key takeaway from the book is to keep your skeptics engaged - don't distance them from what you're doing, but also don't let them dissuade you from trying to bring about positive changes. Another is that when you start this process, be prepared for the long haul. It's a lot of two steps forward, three back.

Good luck!

[1] http://www.amazon.ca/Fearless-Change-Patterns-Introducing-Ideas/dp/0201741571