I appreciate the other thoughts here, but I think there are a couple of things that are missing. First, your goal is an "MVP", so that needs some clarification. Second, the idea of what a "Spec" is has changed.
"MVP" = Minimum Viable Product ="[the] version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" -- Eric Ries.
Couple things to point out here:
1) Where this term has been popularized is in the book "The Lean Startup" by Eric Ries and also by Steve Blank. Lean Startup has become a foundation for innovative product development which, while it has roots in Agile, is more specifically focused on answering the question, "what should we build", via validated learning utilizing the scientific method.
2) The terms "Validated" and "Viable" suggest that you have already answered basic business questions about your product (e.g. who are our customers, what problem are we solving, how much will they pay). In Lean Startup, these questions are typically found on a "Business Model Canvas" or, what I like to use, a "Lean Canvas" which was created by Ash Maurya who is also the author of a great book "Running Lean".
3) Since your goal is to deliver an "MVP", this suggests you may not yet have the validated answers suggested in item #2. If you do have those answers, then you should have those documented (and they'll likely look like specs, which I discuss next).
Note: If your tech guy really understands what an MVP is, then his goal may be to get those answers via his suggested iterative process, which will ultimately result in an MVP. In order to get there, he has to start validating something, so let's assume that he's planning on starting with the ideas/plans that are in his head, which we're going to call a "hypothesis", which brings us to specs.
"Specs" = requirement specifications = documented requirements (functional, technical, etc.) that will satisfy an expected end result.
Couple things to point out here:
1) Traditionally, these are heavily detailed documents that require a lot of work prior to development and have been used as contractual agreements between "the business" and "development". (Don't do this!)
2) Agile contends that you make a lot of assumptions in a traditional development model that don't typically pan out well as far as hitting the mark where customer value is concerned. Assuming that your goal is to provide real value, and that you don't know what features that requires, Agile suggests using an "iterative" approach to building a product where, on a regular "time boxed" basis, you develop working features and then meet with the end user to discover if you hit the value mark or not. Specs in this model are only as good as your assumptions and often change throughout the process, so it isn't very valuable to fix, in a "traditional" way, what it is that you are going to build, rather you need to be accepting of change (hence the name, "Agile").
3) Lean Startup takes Agile's approach one step further and suggests that you don't actually need to code anything to start validating your assumptions (hypotheses). It offers a method that is much "Leaner" than even a typical Agile approach, which will lower your upfront investment until which point you have a validated MVP. Specs really don't come into play early on here since you're not necessarily coding anything. Rather, our hypotheses are quickly invalidated, in which case we "Pivot" to a new hypothesis, or we've "validated" them to an acceptable degree. After we have validated several of the earlier mentioned business questions, we then will likely have something that resembles lean version of a traditional spec, to which we can build! And the set of specs that will come out of this process will ONLY include the Minimal set of requirements that will make the initial Product Viable!
To sum up, look into the Lean Startup and understand what a MVP is. Then, make sure you and your tech team are on the same page as far as how you are approaching the important issue of creating real customer value, including how you validate it, and what a "spec" for you should be. Finally, be prepared to be involved and help during this time, especially if the basic business questions haven't yet been answered. Hope this helps!