To answer your questions:

"This will load up my grunt server automatically based on the latest push to github"

Almost - we'll serve the build directory that your gruntfile creates. We are thinking about running your grunt or gulp tasks for you, so that you don't have to commit your builds to git. I'd love to hear more about your setup and see what we can do to make it work.

"I can then annotate that HTML/CSS front-end to my designer for feedback changes."

Yes.

"No more screenshotting for me?!? This would be amazing."

Yup, that's the idea :)

"Any chance you can integrate to Bitbucket? :)"

We want to. Signup or email me at brendan@awesomebox.co and let's talk.

1) Clients, managers and other "non-developers" usually don't have Github accounts. When we tried making them use Github Issues, most of the time they'd use it for a week and then go back to emailing us or just stop giving feedback.

2) When new code is pushed to Github, how do you show non-developers? Usually this requires maintaining staging servers. What if you want to show different things to three different people? Three servers to maintain. With Awesomebox, you don't have to worry about this - we could even send them notifications to check out new versions, so that you don't have to bug them.

3) It's hard to keep screenshots and their associated conversations organized - it requires a lot of discipline, and when building things I've found that I tend to lose track of UI/UX feedback overtime, even if it's within an issue tracker.

4) Not all feedback is an "issue" or a bug. Github Issues are great, but are designed to track problems, not to help people discuss ideas or provide positive feedback.

I hope that helps answer your question - just a few of the reasons that Matt and I started working on Awesomebox. I'd love to hear more about how you work with people who aren't developers, and if our product doesn't fit your needs, tell us what we could do better. Feel free to reach out - brendan@awesomebox.co

Our goal is to integrate with your source control, no matter where it's hosted. Anything that can send us a webhook should work just fine - just a matter of timing for us to build the integration. Email me at brendan@awesomebox.co and let's talk.

As far as getting information out of Awesomebox, you're the first person to ask - what type of information would you want? There's a few use cases we've thought of, but I'd love to hear your ideas first.

There are some massive and unsolved engineering challenges to going beyond HTML/CSS/JS, but in an ideal world we'd love to make this work for any app, including native mobile apps.

It's funny that you said that about our landing page, because before this, we were probably the most egregious offender of having landing pages that didn't convey what we did. Takes a lot of work to find the right words and presentation, and we still want to make it better.

We ask for permission to manage your contacts so that you can easily invite co-workers to your project on Awesomebox.

We ask for permission to access your repositories on Github so that, for the repositories you choose, we can automatically update Awesomebox when you push new code.

Unfortunately, Github's permission model is "all-or-nothing" - we wish we could let you grant us access only to a specific repository, but it's not currently possible via Github's API.

If you'd prefer not to connect your Github or Google accounts, you can also signup with an email address and try using Awesomebox on an example project.

Does that help answer your question?

Awesomebox only works with client-side code that runs in a browser - HTML/CSS/JS. If you have a Rails app that serves up a "single-page" app (like Angular, Backbone, Ember, etc.), we can work with you to make Awesomebox work. If this applies to what you're building, email me at brendan@awesomebox.co and we'll do our best to get you running with Awesomebox.

In an ideal world, we'd be able to support literally any application - Rails, Django, even iOS and Android apps. But in order to make your code available without spinning up complex environments and rebuilding parts of Heroku, we're focused on people building client-side javascript apps that send and receive data via APIs. This category of apps is growing incredibly fast, and we think there's a lot we can do to help, as both Matt and I have spent the past year working in Backbone and Angular.

Does that help explain a bit?