JBerlinsky

Yes, developers can request permission to access your inbox "offline" (i.e. at any time, with a long-term access token). The scope is clearly identified in the OAuth authentication process, and the consent screen clearly asks for permission to (IIRC) "read, write, and delete emails." There are a few well-known applications (Earny and Unroll.me come to mind, off the top of my head) that are known to work with consumer research operations with the resulting data.

Google does indeed have an office in Ann Arbor. As far as I remember, it's quite light on engineers, though; I'd be surprised if any seniors are there.

I'm a consultancy owner where our engagement mode slightly resembles a freelancer model. There are a few things you should keep in mind (some of which have already been mentioned in this thread):

1. Don't participate in the race to the bottom on price. The goal with most MVPs, in my experience, is to build something that can feasibly be expanded beyond the MVP point. If you work with someone inexpensive, you're likely to wind up with something that, even if it meets your goals, will be difficult to expand upon beyond the initial scope. Of note, you should bear in mind your growth plan beyond the MVP. For example, do you want this freelancer to stick around long enough to help install an internal team? If so, you almost certainly want someone with management/hiring experience, not necessarily a recent code bootcamp grad.

2. Don't work with someone on a fixed-fee if your business has any possibility of adjustment. There are plenty of shops and freelancers out there who grossly misunderstand what it means to be "agile." Agile software development isn't just about the tools and processes one uses to build software -- it's about alignment with the business at any given point in time, and an engineering team's ability to adjust as your business realities change. For example, as you're building your MVP, if you discover that feature X is critical to a large customer using your product, you're logically going to want to introduce it to your MVP scope and prioritize it accordingly. Working with someone on a fixed fee incentivizes scope-freezes when the work is started, which might have financial advantage for you in the short term, but can greatly hinder your ability to adjust as the world changes around you and your business.

3. Work with people who are aligned with your business. Someone who isn't willing to understand the actual business machinations at play behind your MVP is not going to be understanding of your priorities, and won't be able to make informed technical recommendations. You might not think you're looking for a CTO-like figure or anything of that ilk, but when first building out a MVP that you hope to grow beyond that, this level of insight is extremely valuable.

3a. When working with consultancies in particular, do not try to offset monetary payment with stock/equity. It's a clear red flag for us.

4. Work with people you can trust. If you don't have someone in your network, go out of your way to build that trust.

5. Have an idea of what you want, but be willing to listen. Some of us have done user research a million times and know what people don't want to see in a product, and the good ones are going to bring such things to your attention. You know your business better than outside people/organizations, but they might know something you don't.

I'm happy to have a conversation about this with anyone interested. Email in profile.

It's all about your network and supply/demand. Be picky with your projects, and leverage them into your next contract.

On that note, if you happen to have immediate-ish availability, shoot me a message (email in profile).

My pleasure! At the end of the day, whatever works best for your workflow is ideal, of course.