How much say should technical co-founder have in deciding features/look of half-technical product?

Ideally, there should be no lines. If you can't even get 3 people (the co-founders) to discuss issues and find a consensus, you are doomed from the start. Your developer should be open-minded enough to listen to the recommendations of the MBA, and the MBA should be flexible enough to understand that the developer may have legitimate issues.

Don't pull rank. Strive for a collaborative, trusting culture.

This is a great question! I'll draw on my own experience and that of fellow entrepreneurs. I see two main dynamics at work here:

1. Developing the best website possible.

At this early of a stage it isn't about who is responsible for what, but it's about learning what your customers want. This will only happen if your team gets the site in front of customers and starts collecting feedback. This also requires your team to be able to make decisions quickly. Odds are that the marketer (and the developer) will be wrong about many of the assumptions regarding what should go into the website, so there's little value in internally talking about it at length. Most first-time entrepreneurs I know (including myself) make the mistake of waiting to collect customer feedback until the website is nearly complete, only to realize that it doesn't actually meet the customers' needs or fit the customers' mental model. This is wasted development time often 6 months to 1 year. Your team should think of each feature as a hypothesis and think of ways to test that hypothesis as quickly as possible. For instance, we used Balsamiq (a wireframing tool) and Powerpoint to create a mock website. And then we sat with friends and had them use the mock site (ie. usability tests - I suggest reading Don't Make Me Think, for both the marketer and the developer). At this point, the look and feel did not factor in but we were making sure the website made sense to users. We realized that many of our hypotheses were wrong based on watching 3-5 people use the site. We then took the common themes, adjusted the mock website and tried again. We iterated on the process until we built a site that made sense to our users. At which point we built out the actual site and functionality. It was much easier for us to create a mock website than a real one (but that's not always the case.)

And even after the product was built, we focused on the simplest feature set, usability tested, and then expanded. This is not to say that you should follow the same exact path, but just that the team should constantly be talking with outsiders to collect feedback to help inform the feature development.

Following this process creates buy-in from the entire team because it's no longer about 1 person's opinion but it's actually about the customers. A good exercise it to list out all the hypotheses on a whiteboard and figure out how to test them with outsiders/customers.

2. What if the marketer doesn't believe in this process?

This is certainly a very real challenge. At this point the developer should go out and do his own usability tests with customers. Screencast them if possible along with audio. Or pay for a service like Usertesting.com. The developer can then take these usability tests back to the marketer and show him what the "customers" are saying. Remember, that it's not about who is right or wrong but it's about finding the best solution. So the developer should also highlight instances where he had a hypothesis that was wrong to put the marketer at ease. It'll be hard for the marketer to argue with customer feedback.

At this early of a stage, everyone should be learning about the customer as it will make each of you better at your respective jobs.

Is the marketing guy overstepping his role?

Yes, and no. Mostly no. Here's why. I've seen both business types and devs make academic arguments from non-data as to why a certain product should be X, Y or Z, but ultimately the MBA types are looking at the same issue as the devs with more of a bird's eye view. I would even go so far as to say that it's a conflict of interest for developers to be to involved in the marketing of their own work. They're simply too close to it.

Or is the development guy overstepping his role?

Yes and no but mostly yes. The MBA types interface more often with the types who land big accounts and give the company momentum and critical, high-level feedback. This is an opportunity for the developer to practice letting go, something I've watched very successful founders do throughout a company's growth. Not always pleasant but a side effect of growth.

Can the marketing guy more easily make his case since the company/product in not purely a technical one?

Based on my experience, I would say that in this instance, the considerations of the individual in the marketing role trump those of the dev's.

Everyone on a team has to have a stake, a personal sense of ownership of their domain, otherwise morale plummets and they start watching the clock.

The dev already owns the technology side, the "how." They interface with the engineers and the systems.

The marketing/business types interface with the customer base and the accounts themselves, they have their finger on a different pulse but it's one that directly affects the bottom line. It's a bigger picture view.

Another note - push-back from one party on features, design etc. is OK as long as it isn't interminable. Ultimately someone needs to concede, and someone needs to lead.

Someone should have the last word on these decisions, and in the absence of pragmatism or some compromise, it's up to a third party to step in and set the course. In my opinion, it is that wherewithal for "dirty work" that separates executives from everyone else. They should see the big picture, resolve these things decisively, and everyone else should follow the leader.